Читабельность Rust, C++ и Go

Раньше вообще типа не было, это его потом сбоку приколхозили.

для упрощения конпелятора

Только это не упрощает компилятор, а даже скорее наоборот.
Скорее всего это просто наследие древних языков вроде алгола или фортрана.

в си не было типа? дай пруфлинк

K&R сишка же. Можно было записывать сигнатуры без всяких типов. Канпелятор считал все за int. Вероятно на самом раннем этапе там других типов то и не было.

Раньше вообще типа не было, это его потом сбоку приколхозили.

это когда на перфокартах первобытные люди писали ведроид для охоты на мамонтов?

Читаемость зависит от твоих навыков. Ну, естественно, она разная для разных языков, но нечитаемого кода не бывает. Бывает трудночитаемый.

Go:

func typeList(
  arch *TFile,
  offset uint32,
  parseDecl bool,
  ) []BStr {

go fmt

остальные примеры хз: C++ и Rust не юзаю пока

на GO скорее уж так:

func (arch *TFile) typeList(offset uint32, parseDecl bool) []BStr {
  ...
}

дай пруфлинк

Зачем тебе линк, создаешь новый файл, пишешь туда такое

sum;
printf();

add_numbers(a, b) {
    return a + b;
}

main() {
    sum = add_numbers(10, 20);
    printf("sum: %d\n", sum);
}

и gcc успешно его скомпилирует.

про constexpr ты типо не слышал

Да слышал я про это недоразумение :-) Ничего путного на этом не сделать, как бы там кто не фантазировал :-)

man Boost.Hana

The purpose of Hana is to merge the 3rd and the 4th quadrants of computation.

Т.е. уно-квази-фантазия для работы с виртуальным синхрофазатроном 4-й степени :-) Спасибо, конечно, но это не моё :-) Лол :-)

За исключения нужно сразу увольнять, атата! За голые указатели нужно сразу увольнять, бубубу! И далее 100500 фич, которые есть в цепепе, но юзать низзя.

А как же dynamic_cast? :-) Признак плохого дизайна, надо сразу увольнять :-)

И за использование friend.

func typeList(
  arch *TFile,
  offset uint32,
  parseDecl bool,
  ) []BStr {

капец, форматирование

Так это ж gofmt, стандартный навязываемый стиль форматирования. Безобразно, зато единообразно.

у Rust и правда наркоманский синтаксис. cpp/go вполне читаемы, хз что тебе не нравится

Так это ж gofmt, стандартный навязываемый стиль форматирования.

А если у функции один аргумент, все равно распидорасит?

у Rust и правда наркоманский синтаксис. cpp/go вполне читаемы

По мне так все три языка ужасны, каждый по своему. Но у C++ есть объективные причины почему он такой, а два других просто жертвы тараканов в голове их шизанутых авторов.

А у раста что-ли нету обьективных причин иметь лайфтаймы? Предлагаешь заменить их на сборщик мусора?

раньше тип шел первым в том числе для упрощения конпелятора

А правда ты пишешь компилятор для сбера? Если так, то пора валить оттуда...

Установи и посмотри. Юзкейсы Гоу мне не интересны, поэтому я его не трогал.

Нет объективных причин тянуть такой синтаксис. Вот взять закорючку лайфтаймов, типа она намекает на время. Но для нешизиков это парный разделить, воткнутый в середину строки непойми зачем. Или fn - это только повреждение мозга может нашептать такой кейворд, либо тяжелое детство на телетайпах. Характерно, что и адепты этим заражаются, fd - убиться веником, прям косплей древнего юникса. И это только мелкие штрихи, там полно еще шизы.

Но для нешизиков это парный разделить, воткнутый в середину строки непойми зачем.

I wouldn't be so sure.

Но для нешизиков это парный разделить, воткнутый в середину строки непойми зачем.

Назначение лайфтаймов прекрасно разжевывается в доке языка. Какую форму записи лайфтаймов предложишь ты?

fn - это только повреждение мозга может нашептать такой кейворд,

А шо в нем такого? Вон в Kotlin вообще fun и ниче. Не жалуются.

там полно еще шизы.

Приведи еще примеры. Мне интересно.

Какую форму записи лайфтаймов предложишь ты?

А зачем изобретать велосипед? Сделать нормальные аннотации, и использовать их для лайфтаймов тоже, будет и универсальнее, и мощнее и читабельнее. Например:

@Lifetimes(a, b)
void print_refs(
    @Lifetime(a) x: i32,
    @Lifetime(b) y: i32) 
{
    println!("x is {} and y is {}", x, y);
}

Да и первую аннотацию, возможно, вообще можно выкинуть. Останется:

void print_refs(
    @Lifetime(a) x: &i32,
    @Lifetime(b) y: &i32) 
{
    println!("x is {} and y is {}", x, y);
}

Вполне себе код для человеков.

Тогда уж

procedure print_refs(
    @Lifetime(a) x: reference integer32,
    @Lifetime(b) y: reference integer32)
begin
    ...
end 

Не все же C знают.

Не все же C знают.

А причем тут С? Так сделано, например, в Java и Python. А в C аннотаций вообще нет, есть только аттрибуты в С++:

void print_refs(
    [[lifetime(a)]] int& x,
    [[lifetime(b)]] int& y) 
{
    printf("x is %d and y is %d", x, y);
}

Хотя они явно проигрывают Java в читабельности. И вместо того, чтоб кидаться в крайности, логично выбирать годные решения.

а как же лайфтаймы? без них-то более менее с этим не спорю

Так в коде выше они и не нужны. Необходимость в лайфтаймах появляется там, где в плюсах ты говоришь «данные по указателю/ссылке валидны, мамой клянусь».

но изуродовать так код на Go и на C++ можно только специально

Да ладно? Просто везде уродство своё. На Go достаточно посмотреть на портянки с «обработкой» ошибок, а на плюсах на код пионеров, которые шаблоны освоили и пытаются на них делать всё, что можно.

так раст никогда не взлетит, потому-что поддержка индусов слишком дорого обойдется

Не сцы, индусов уже готовят: http://www.rowdymehul.com/rain-of-rust-how-we-did-it/

что за бред, как расставишь переносы строки, так и оставляет

Если не учитывать C, то непонятно почему значок «&» читабелен и понятен, а значок «'» - что-за-хрень-глаза-вытекают.

Да ты тыкалкой промахнулся

Если не учитывать C

А не учитывать C и C++ в контексте разговора о Rust просто нельзя. Ведь та же Mozilla вложилась в Rust (т.е. позволила Rust-у выжить и с помпой выйти в свет) именно для переписывания на Rust-е C++ной кодовой базы.

По поводу «'» все просто: слишком мелкий значок. Явное несоответствие между важностью его смысла и легкостью не обратить на него внимания.

Это у разработчиков Rust-а какой-то специальный подход к тому, чтобы сделать важные вещи не слишком заметными визуально. Вроде амперсанда для лайфтаймов или "?" как замена try!.

непонятно почему значок «&» читабелен и понятен, а значок «'» - что-за-хрень-глаза-вытекают.

Потому-что важны не значки, а их комбинации и размещение в коде.

$??s:;s:s;;$?::s;;=]=>%-{<-|}
<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see

Нормальные значки же, непонятно, почему кому-то это не нравится.

Ну, разработчики раста видимо посчитали, что аннотации слишком громоздки для такой важной фичи и решили для лайфтаймов придумать свои минималистичные конструкции. Все-таки лайфтаймы как и ссылки это части одного механизма языка. Если все делать на аннотациях. то пришлось бы и для ссылок такую вводить и читать уже такой код на мой взгляд было бы тяжелее. А user-defined аттрибуты таки скоро введут.

Но лайтаймы это не анотация. Это такой же параметр конструктора типов как и, к примеру, T в Vec<T>.

Ну, разработчики раста видимо посчитали, что аннотации слишком громоздки для такой важной фичи

Я думаю, что все банальней. В ранней версии не было нормальной дедукции для лайфтаймов, и их приходилось выписывать крайне часто. А потому наличие краткой записи было необходимостью, и думать над другими вариантами просто не стали.

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

Почему? Мухи отдельно, котлеты отдельно. Лайфтаймы вообще по сути опциональная вещь, компилятор тебя же еще и наругает, если ты их выпишешь лишний раз.

сделать важные вещи не слишком заметными визуально

Если сравнивать с С++, то "?" заменяет невидимый проброс исключения. Если сравнивать с Haskell, то "?" заменяет невидимую операцию «bind» в do-нотации. Так что не всё так однозначно.

А на амперсанд жалуются, что он портит синтаксис, а не на то, что его трудно заметить.

похоже, ты...

Но лайтаймы это не анотация. Это такой же параметр конструктора типов как и, к примеру, T в Vec<T>.

Ну так лайфтайм у каждой переменной есть, соот-но каждая переменная имеет свой тип. Но это же безумие заставлять выписывать это все руками, потому оформить это через аттрибуты - вполне себе вариант. В том же C (его реализациях) тоже можно за счет атрибутов конструировать свои типы, которые стандартными средствами не выписать.

Если сравнивать с С++, то "?" заменяет невидимый проброс исключения.

Аналог «невидимого проброса» в Rust — это паника. А "?" — это неявный return. Так что аналогия не в тему.

А на амперсанд жалуются, что он портит синтаксис, а не на то, что его трудно заметить.

«То, что его трудно заметить» никак не «портит синтаксис», да.

Разве синтаксис не должен отражать семантику?

Аналог «невидимого проброса» в Rust — это паника. А "?" — это неявный return. Так что аналогия не в тему.

Паника - это аналог непрошедшего ассерта, сегфолта и части исключений.

"?" - это рекомендуемый способ обработки ситуаций, которые в C++ обрабатываются исключениями или возвращаемыми значениями.

Прямого соответствия нет, но "?" ближе к обработке исключений, чем к панике.

Ну так лайфтайм у каждой переменной есть

Не у каждой, а только у ссылок.

Не у каждой, а только у ссылок.

У каждой. А ссылка это лишь способ передать владение переменной и тем самым повлиять на время жизни той самой переменной.

"?" - это рекомендуемый способ обработки ситуаций, которые в C++ обрабатываются исключениями или возвращаемыми значениями.

Пусть меня поправят опытные Rust-оманы, но "?" в Rust — это синтаксический сахар для try!, а try! — это всего лишь упрятанный в макрос код для получения кода возврата, его проверки и вызова return, если код возврата не Ok.

Т.е. это прямой аналог работы с кодами возврата в C++. Никакой аналогии с исключениями из C++ тут нет. Т.е. в Rust-е с помощью ? записывают то, что в C++ записывают как-то так:

const auto r = do_something();
if( !r ) return r;

C++ные исключения здесь ни при чем.

Исключение - средство пробросить сведения об ошибке к месту, где они могут быть обработаны.

"?" - средство пробросить сведения об ошибке к месту, где они могут быть обработаны.

Паника - средство для обработки ситуации, не предусмотренной программистом.

По выполняемым функциям "?" ближе к исключениям. По деталям реализации паника ближе к исключениям. Так что отношение вполне себе есть.

"?" - средство пробросить сведения об ошибке к месту, где они могут быть обработаны.
Паника - средство для обработки ситуации, не предусмотренной программистом.

Давайте так: показанный выше С++ код, а именно:

const auto r = do_something();
if( !r ) return r;