https://github.com/carbon-language/carbon-lang?tab=readme-ov-file

Обсуждали уже?

// Carbon:
package Geometry api;
import Math;

class Circle {
  var r: f32;
}

fn PrintTotalArea(circles: Slice(Circle)) {
  var area: f32 = 0;
  for (c: Circle in circles) {
    area += Math.Pi * c.r * c.r;
  }
  Print("Total area: {0}", area);
}

fn Main() -> i32 {
  // A dynamically sized array, like `std::vector`.
  var circles: Array(Circle) = ({.r = 1.0}, {.r = 2.0});
  // Implicitly constructs `Slice` from `Array`.
  PrintTotalArea(circles);
  return 0;
}

Язык нацелен на совместную работу с С++ с последующей заменой последнего.

Эстетически весьма приятен. Наконец-то, Array называется Array, а не вектор-шмектор. За одно это можно простить круглые скобки для обобщений.

Очевидно, на данном этапе ни хрена не декларативен. Тут так и напрашивается

fn PrintTotalArea(circles: Slice(Circle))
{
  var area: f32 = circles.Sum(c => Math.Pi * c.r * c.r);
  Print("Total area: {0}", area);
}

Причём, для плюсов есть библиотеки, чтобы так писать, а тут махровая императивщина на титульной странице. Может, в будущем доделают.

Буду ждать и верить.

Здравствуйте, Alekzander, Вы писали:

A>Эстетически весьма приятен.
Ну не знаю. Эти двоеточия в объявлениях к чему они?

A>Наконец-то, Array называется Array, а не вектор-шмектор.
А причем здесь язык?

Здравствуйте, rFLY, Вы писали:

A>>Эстетически весьма приятен.
FLY>Ну не знаю. Эти двоеточия в объявлениях к чему они?

Насколько я понимаю, это сейчас везде так и помогает заменить операторы выражениями. Что даёт много вкусных плюшек, декларативность, главным образом.

A>>Наконец-то, Array называется Array, а не вектор-шмектор.
FLY>А причем здесь язык?

Наверное, это из стандартной библиотеки языка, а не UDT. Вот на что надо будет внимательно посмотреть (на стандартную библиотеку). Но уже по одному сэмплу кажется обнадёживающим.

Здравствуйте, Alekzander, Вы писали:

A>Насколько я понимаю, это сейчас везде так и помогает заменить операторы выражениями. Что даёт много вкусных плюшек, декларативность, главным образом.
Не понимаю, о чем речь? Вот, например, int a = b + c; разве не выражение?

Здравствуйте, Alekzander, Вы писали:

A>Язык нацелен на совместную работу с С++ с последующей заменой последнего.
Ещё одного хоронить...

A>Эстетически весьма приятен.
Да в общем то нет.

A>Наконец-то, Array называется Array, а не вектор-шмектор
Если у тебя самая большая боль это название класса в по сути вспомогательной опциональной библиотеке то это ж исправляется банальным define

Здравствуйте, rFLY, Вы писали:

A>>Эстетически весьма приятен.
FLY>Ну не знаю. Эти двоеточия в объявлениях к чему они?

Во-первых, сейчас это можно и молодежно.

Во-вторых, говорят, что когда декларации делаются в виде var name: type = initial-value, то это очень (и очень-очень) сильно упрощает парсинг исходного кода. А в нынешние времена парсинг нужен не только компилятору, но и IDE, и форматерам, и утилитам для извлечения документации из комментариев, и линтерам/стат.анализаторам. Т.е. грамматика с минимумом неоднозначностей заметно облегчает построение инфраструктуры вокруг языка.

Здравствуйте, Alekzander, Вы писали:

A>Обсуждали уже?
A>Буду ждать и верить.
Я не понимаю что же нового даёт нам этот язык? Вот с go всё понятно — это мощный механизм горутин и утиная типизация, а тут? Они придумали свой нескучный синтаксис, но не придумали какой-то новый механизм?

Здравствуйте, rFLY, Вы писали:

FLY>Ну не знаю. Эти двоеточия в объявлениях к чему они?
Вангую, проще было писать синтаксический разбор и описывать грамматику.

Здравствуйте, Alekzander, Вы писали:

A>Эстетически весьма приятен. Наконец-то, Array называется Array, а не вектор-шмектор.
Так в С++ array тоже называется array Или int[] это теперь не массив?

A>Буду ждать и верить.
От С++ можно отказаться прямо сейчас, если позвонить на горячую линую помощи С++-зависимым. Там предложат анонимность, чай, плед и расскажут, как установить JDK.

Здравствуйте, so5team, Вы писали:

S>Во-вторых, говорят, что когда декларации делаются в виде var name: type = initial-value, то это очень (и очень-очень) сильно упрощает парсинг исходного кода. А в нынешние времена парсинг нужен не только компилятору, но и IDE, и форматерам, и утилитам для извлечения документации из комментариев, и линтерам/стат.анализаторам. Т.е. грамматика с минимумом неоднозначностей заметно облегчает построение инфраструктуры вокруг языка.
Это очевидно, но в чем профит для программиста от var, fn, ":" и стрелочек для объявления типа возвращаемого значения? Они только загромождают код, да и писать их каждый раз. Короче я такой эстетики не понимаю.
Текущие же инструменты как-то справляются без всего этого. Их авторы все равно не станут с нуля разрабатывать парсер, а переделают имеющийся.

Здравствуйте, rFLY, Вы писали:

FLY>Это очевидно, но в чем профит для программиста от var,

Мне лично больше по душе писать что-то вроде:

var variable = ...
const variable = ...

чем то, что сейчас приходится делать в C++.

FLY>fn,

За такое нужно отрывать руки. Как я понимаю, корни в том, что Rust начал делать OCaml-ер (т.е. человек наглухо ударенный функциональщиной). Отсюда и угребищные Rust-овые сокращения вроде fn или mut.

Ну а так как Carbon -- это попытка гуглеров сделать что-то типа C++ но с синтаксисом Rust-а, то отсюда и fn.
Почему они не взяли хотя бы func для меня лично большой вопрос.

FLY>":"

Это вопрос привычки. Принципиальной разницы между f(a: int, b: float) и f(int a, float a) не вижу. А если добавить присутствующие в C++ east const, west const и необходимость в случае с шаблонами местами выписывать typename, то декларировать сперва имя параметра, а потом, через двоеточие его тип, как по мне, так даже удобнее.

FLY>и стрелочек для объявления типа возвращаемого значения? Они только загромождают код, да и писать их каждый раз.

Так ведь и в C++ уже пишут:

auto f() -> some_type {...}

Так что ничего принципиального нового здесь нет.

FLY>Текущие же инструменты как-то справляются без всего этого.

Если мы про C++ (на замену коего и делают Carbon), то как-то херовенько справляются. Мягко говоря.

Здравствуйте, Kernan, Вы писали:

K>Вангую, проще было писать синтаксический разбор и описывать грамматику.
Аргументы от дедушки Вирта.

Здравствуйте, so5team, Вы писали:

S>это очень (и очень-очень) сильно упрощает парсинг исходного кода.
Синтаксис должен быть выразительным в первую очередь для человека.

S>Т.е. грамматика с минимумом неоднозначностей заметно облегчает построение инфраструктуры вокруг языка.
Это строится один раз, а код человеки пишут и читают постоянно.

Здравствуйте, CreatorCray, Вы писали:

S>>это очень (и очень-очень) сильно упрощает парсинг исходного кода.
CC>Синтаксис должен быть выразительным в первую очередь для человека.

И вот тут C++, особенно современный, далеко не лучший пример. Как и Rust, впрочем.
А Carbon, похоже, собирается взять худшее из обоих

S>>Т.е. грамматика с минимумом неоднозначностей заметно облегчает построение инфраструктуры вокруг языка.
CC>Это строится один раз, а код человеки пишут и читают постоянно.

Если делается новый язык, то почему бы сразу не сделать и удобный для пользователей синтаксис, и при этом легкий для парсинга?

Здравствуйте, Alekzander, Вы писали:

A>https://github.com/carbon-language/carbon-lang?tab=readme-ov-file

A>Обсуждали уже?

А как же Rust?

Здравствуйте, so5team, Вы писали:

S>Мне лично больше по душе писать что-то вроде:
S>

S>var variable = ...
S>const variable = ...
S>

Я не об этом. Зачем вообще писать var, кроме как помочь парсеру. Объявил тип, указал имя, если нужно инициализировать — указал значение. Если нужна константа, то перед типом указал const. К чему эти дополнительные сущности, язык должен быть лаконичным.

S>Почему они не взяли хотя бы func для меня лично большой вопрос.
И тут я не вижу причины писать fn или func. Вот чем их не устроило int Main()?

S>Это вопрос привычки. Принципиальной разницы между f(a: int, b: float) и f(int a, float a) не вижу.
В том то и дело, теперь кому-тто придется свои привычки менять. Было бы ради чего. Пока что я вижу, если отбросить сложность парсинга, просто тренд такой.

Здравствуйте, so5team, Вы писали:

S>Если делается новый язык, то почему бы сразу не сделать и удобный для пользователей синтаксис, и при этом легкий для парсинга?
Но это не похоже на удобный. во всяком случае для меня.

Здравствуйте, BlackEric, Вы писали:

A>>https://github.com/carbon-language/carbon-lang?tab=readme-ov-file

A>>Обсуждали уже?

BE>А как же Rust?

Как я понял, у Гугла следующая ситуация:

* туева хуча кода на C++;
* переписать его на Rust нереально;
* сопрягать старый код на C++ с новым кодом на Rust сложно;
* продолжать писать на C++ дорого и рискованно.

Но что-то делать нужно. Вот они и решили сделать новый ЯП, который типа как Rust, но чуть ли не со 100% интероперабильностью с C++. Тем самым можно оставить существующую кодовую базу на C++, а новые куски к ней дописывать на Carbon.

Так что Rust, по мнению Google, здесь не при делах. Вроде бы Rust в Google и так для новых проектов используется.

Здравствуйте, rFLY, Вы писали:

FLY> К чему эти дополнительные сущности, язык должен быть лаконичным.

Не должен он быть лаконичным, он должен обеспечивать хорошую читаемость.

Здравствуйте, rFLY, Вы писали:

FLY>Я не об этом. Зачем вообще писать var

Чтобы можно было отличать переменные от констант.

FLY>Объявил тип

вот тут стоп. В современном коде тип указывается все реже и реже. Вписывать auto или const auto -- это тоже самое, что и вписывать var или let.

FLY>К чему эти дополнительные сущности, язык должен быть лаконичным.

Практика показала, что C++ уже давным-давно не лаконичный.

S>>Почему они не взяли хотя бы func для меня лично большой вопрос.
FLY>И тут я не вижу причины писать fn или func. Вот чем их не устроило int Main()?

Потому что сейчас вместо int f(int) зачастую приходится писать что-то вроде:

template<typename T>
[[nodiscard]] constexpr typename T::value_type
f(T && v) noexcept;

Что выглядит так себе. Особенно в коде тех утырков, которые застряли в "Си с классами" и продолжают лепить имя функции на той же строке, что и тип возвращаемого значения

FLY>В том то и дело, теперь кому-тто придется свои привычки менять.

Ну так все течет, все изменяется. Не менялось бы, мы бы на старославянском бы сейчас общались.