Посмотрел я этот ваш Rust

Шта?! У C++ нет стабильного, единого ABI. Я посмотрю как вы будете решать эту «проблему», когда у вас либы собраны другим компилятором и как тут могут помочь хедеры.

Достать другой компилятор и пересобрать из исходников, да хоть в виртуалке.

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

Да хотя бы rlib сделали легко-подключаемыми через cargo! Но там все не так просто. На игрушечных примерах может быть и подключается, но если начинаются общие зависимости, то все.

Или ты со стороны клиентов спрашиваешь? Так, это, пусть денежку «плотят».

посмотри лучше этот их nim

https://www.reddit.com/r/rust/comments/2vqy81/author_of_unix_in_rust_abandons_rust_in_favor_of/

https://github.com/ckkashyap/rustix/issues/8

Какая милота! Привет, Лавсан!

Rust в сторонку, если какой язык и похож на C++ больше всего, так это общелисп. Сам посуди:

• Оба языка основаны на древнем язычке путем наклеивания кучи мусора сверху.
• Оба языка утверждаются комитетами в виде стандартов ISO раз в очень много лет (хотя C++ ускорил цикл в последние годы).
• Оба языка имеют крайне много абсолютно ортогональных и несочетаемых друг с другом фич.

С другой стороны, у плюсцов есть хотя бы статическая типизация, хоть и паршивая. В лиспе и её нет [1].

[1]: тому, кто сейчас заявит, что, дескать, в Common Lisp можно сделать статическую проверку типов, я предлагаю сделать это с проектом, использующим CLOS и толпу внешних библиотек.

Речь шла про стабильный ABI, которого у C++ нет. О чём вы пишите - не ясно.

Если что, вам никто не мешает собрать crate_type = "dylib".

Ну так неудобно или нельзя? А то dependency hell в C/C++ никто не отменял.

5 years ago

Очень актуально.

А ты сам пробовал этот dylib? (я - да)

за это время что-то принципиально поменялось?

В голове автора? Будем надеяться.

Или вы пытаетесь экстраполировать единичный hello world на весь язык?

Нет, ибо не нужно.

Или вы пытаетесь экстраполировать единичный hello world на весь язык?

нет, но если бы пришлось выбирать из экзотики с сахаром, скорее выбрал бы nim, чем rust

сравнение в лоб говорит об отсутствии решающих преимуществ одного перед другим, при гораздо более приятном и лаконичном синтаксисе nim. ну и nim просто транспилится в С (++, js), что дает некоторые очевидные преимущества.

Режим «dylib» мало отличается от режима сишной либы «cdylib». Основная разница в том, что в первом случае либа получает в зависимости растовскую стандартную либу. Во втором случае последняя уже вшивается. А так, на свой страх и риск можно использовать растовские типы в обоих случаях, но это не будет безопасно относительно FFI. Нужен именно «#[repr(C)]».

Короче, «dylib» сделан по принципу «на! отвали!». Даже по докам видно.

Хотел понтануться перед дядькой асмом, а дядька, внезапно, знает асм.

(inst mov r 1)
LOOP
(inst test n n)
(inst jmp :z DONE)
(inst imul r n)
(inst dec n)
(inst jmp LOOP)

Это плохой цикл, компиляторы C/C++/Pascal сгенерируют код, который уделает этот раза в два. Это если не считать того, что ты вручную генерируешь асм, но как бы на CL.

Там многие программы для лиспа не оптимизированы и написаны довольно тупо, это давно известно, но лисперам лень править

То что ты называешь оптимизированным кодом, в рамках этого проекта называется «неидиоматический код» и в коммерческом софтостроении порицается, потому что сильно усложняет поддержку, делая код даже сложнее аналогичного кода на Си.

Дело в том что в других языках вообще нельзя расширять компилятор, в отличие от CL. Так что «страшно выглядит»(для не-лиспера) это все же на порядок лучше чем «тупо нету»

Компилятор Си расширяется, внезапно.... при помощи Си. Вот так сюрприз.

SBCL тоже умеет
(declare (optimize (speed 3) (safety 0) (debug 0)))

Опять отвратительный цикл, теперь сделанный самим компилятором:

>; 99: L1:   B902000000       MOV ECX, 2
>; 9E:       EB07             JMP L3
>; A0: L2:   48D1F9           SAR RCX, 1
>; A3:       480FAFC8         IMUL RCX, RAX
>; A7: L3:   840425F8FF1020   TEST AL, [#x2010FFF8]            ; safepoint
>; AE:       4883C002         ADD RAX, 2
>; B2:       488BD3           MOV RDX, RBX
>; B5:       4839D0           CMP RAX, RDX
>; B8:       7FD6             JNLE L0
>; BA:       EBE4             JMP L2

Я вообще не понимаю, какими критериями руководствовался компилятор, чтобы это сгенерить. Он итерирует через два и при этом делит результат на два. Почему нельзя было сгенерировать «CMP RAX, RDX» вместо двух команд «MOV RDX, RBX; CMP RAX, RDX» — мне тоже не ясно.

В итоге, этот код отработает раза в три медленнее аналогичного алгоритма, сгенерированного компилятором Си с оптимизацией.

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

с таким же подходом к языкостроению

Этот наезд не обоснован. Подход цэ2плюса, грубо, «а давайте к сям добавим ещёвотэто». Где у ржавы что-то подобное? Как кто-то из местных ругается, они(пока) даже с собой совместимость не очень лелеют.

все тот же

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

и всеми его «прелестями»

Ну не всеми же. Наследования, вон, нет.

Итого, качество аргументов заставляет сворачиваться.

Естественно, все сидящие в этом треде очень хотят узнать, что же генерирует компилятор на Си. Пожалуйста:

0x000000000040057d <+61>:	mov    $0x1,%esi
0x0000000000400582 <+66>:	cmp    $0x1,%ebx
0x0000000000400585 <+69>:	je     0x4005cf <main+143>
0x0000000000400587 <+71>:	lea    -0x1(%rbx),%esi
0x000000000040058a <+74>:	cmp    $0x2,%ebx
0x000000000040058d <+77>:	je     0x4005df <main+159>
0x000000000040058f <+79>:	imul   %ebx,%esi
0x0000000000400592 <+82>:	lea    -0x2(%rbx),%eax
0x0000000000400595 <+85>:	cmp    $0x3,%ebx
0x0000000000400598 <+88>:	je     0x4005cf <main+143>
0x000000000040059a <+90>:	imul   %eax,%esi
0x000000000040059d <+93>:	lea    -0x3(%rbx),%edx
0x00000000004005a0 <+96>:	cmp    $0x4,%ebx
0x00000000004005a3 <+99>:	je     0x4005cf <main+143>
0x00000000004005a5 <+101>:	imul   %edx,%esi
0x00000000004005a8 <+104>:	lea    -0x4(%rbx),%eax
0x00000000004005ab <+107>:	cmp    $0x5,%ebx
0x00000000004005ae <+110>:	je     0x4005cf <main+143>
0x00000000004005b0 <+112>:	imul   %eax,%esi
0x00000000004005b3 <+115>:	lea    -0x5(%rbx),%edx
0x00000000004005b6 <+118>:	cmp    $0x6,%ebx
0x00000000004005b9 <+121>:	je     0x4005cf <main+143>
0x00000000004005bb <+123>:	imul   %edx,%esi
0x00000000004005be <+126>:	lea    -0x6(%rbx),%eax
0x00000000004005c1 <+129>:	cmp    $0x7,%ebx
0x00000000004005c4 <+132>:	je     0x4005cf <main+143>
0x00000000004005c6 <+134>:	imul   %eax,%esi
0x00000000004005c9 <+137>:	sub    $0x7,%ebx
0x00000000004005cc <+140>:	imul   %ebx,%esi
0x00000000004005cf <+143>:	mov    $0x400a42,%edi
0x00000000004005d4 <+148>:	xor    %eax,%eax
0x00000000004005d6 <+150>:	callq  0x4004f0 <printf@plt>
0x00000000004005db <+155>:	xor    %eax,%eax
0x00000000004005dd <+157>:	pop    %rbx
0x00000000004005de <+158>:	retq   
0x00000000004005df <+159>:	mov    $0x2,%esi
0x00000000004005e4 <+164>:	jmp    0x4005cf <main+143>

Справедливости ради…

А если просто производительности не будет хватать, в том числе там из-за GC, так ведь - что в Java, что в Common Lisp, есть огромное количество возможностей затюнить производительность до нужного уровня, при этом не стреляя себе в ногу.

Здрасьте. А как же NullPointerException? А Lisp же вообще бестиповый, и баг словится только в процессе выполнения кода. Так что при чем тут эти ЯП в контексте «не стреляя себе в ногу»?

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

Lisp нетривиальный??? Основная идея Lisp, eval-apply loop - это одна из самых простых концепций в программировании, за всю историю.

Наконец, ну безопасность чтоли, хваленая? Ну, опять нет. Взять тот же unsafe.

Что «взять unsafe», и при чем тут безопасность? Где-то сказано, что unsafe - это безопасный код? В любой серьезной конторе используется coding style guide, в котором написано, что из фич используемого ЯП использовать запрещено. Например, в некоторых проектах на С++ запрещено использовать исключения. Далее, это правило можно энфорсить, буть то: флагами компиляции, статическим анализом, тупым грепом, ручным ревью кода или любой комбинацией из вышеперечисленного - уже дело техники и организации процесса. Для Rust, возможно, есть какие-то директивы, запрещающие использование unsafe. И если конкретный код должен быть максимально безопасен, то никакого unsafe там не будет.

Если вам нужна прямо таки безопасность-безопасность - берите что-нибудь вроде хаскеля […] или на худой конец, что-нибудь вроде Java, где все безопасно прямо как в дурдоме с мягкими стенами.

Для начала следует проверить на безопасность сам компилятор Haskell. Если он сложнее Rast’овского компилятора, то вовсе не факт, что код на Haskell будет безопаснее кода на Rust, какие бы супер-мега-безопасные с теоретической т.з. концепции ни использовались. Про Java - это LOL, с ее-то NullPointerException, но, может быть, по сравнению с обитателями дурдома, Java действительно безопаснее.

Вобщем, не вижу зачем этот язык нужен, нам и C++ хватает, если надо не ехать, а шашечки(т.е. тупо позадротствовать, да).

А еще плюсы в реальных проектах используются, в которых таки надо именно ехать, а не шашечки.

Ну и справедливости ради отмечу, что все-таки я ошибся с «сишный код быстрее раза в три». Цифра беспруфная пока что, можете сами забенчить - у меня SBCL нету и возиться с ним не планирую. Я предполагаю, что более реалистична разница в полтора-два раза.

Только вот большинство серьёзных либ на расте используют ансейф. И через них ансейф как рак заражает и ваш продукт даже если вы сами его и не используете.

Ансейф - это связь с внешним миром, FFI, и возможно, что еще оптимизация, состоящая в использовании сверхбыстрого UnsafeCell вместо RefCell. Не надо так пугаться!

Слушайте, если вам такая безопасность нужна, то тогда Ada, но кто там обезопасит ваш код от людей и их политиков только?

Какой ещё рантайм? У C++, Rust, D (который betterC) такой же рантайм как и у сишки.

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

Ну так не используйте те фичи языка, которые требуют рантайма. В D есть специальное подмножество языка, которое контролируется компилятором - betterC и это позволяет заменить сишный код на дишный один в один. Можно в одном проекте одновременно и сишный и дишный код иметь и все будет работать без каких-либо доп ограничений. При этом в D будет доступна банально строгая типизация, плюс фишки типа метапрограммирования, CTFE и пр. Очень даже замена сишечки. Сборщика мусора в этом режиме нет.

Только вот большинство серьёзных либ на расте используют ансейф. И через них ансейф как рак заражает и ваш продукт даже если вы сами его и не используете.

Как и исключения С++. И нет никаких способов гарантировать exception safety, по крайней мере, в большом проекте с кучей зависимостей от разных команд. Если в общем случае нет никаких мер, дающих гарантии, что в систему не попадет небезопасный код (кроме целого комплекса - в т.ч. и организационных - мероприятий), то и от Rust странно требовать решения проблемы безопасного кода исключительно техническими способами. А судить логично по относительной безопасности при прочих равных (бюджете проекта, квалифицированности инженеров и проч.)

и со стабильным ABI

Дарю: https://crates.io/crates/abi_stable

Компилятор си тупо делает развертку цикла. Ессно для произвольного N, это как-то бессмысленно.

Он итерирует через два и при этом делит результат на два.

Это не итерирование через 2, это работа с меткой типа(typetag) fixnum.

Почему нельзя было сгенерировать «CMP RAX, RDX» вместо двух команд «MOV RDX, RBX; CMP RAX, RDX» — мне тоже не ясно.

Разница абсолютно neglibile

Компилятор Си расширяется, внезапно…. при помощи Си. Вот так сюрприз.

Никак он не расширяется, на практике. Никто с собой компилятор Си не таскает.

Это плохой цикл, компиляторы C/C++/Pascal сгенерируют код, который уделает этот раза в два.

Ничего подобного.

А Lisp же вообще бестиповый, и баг словится только в процессе выполнения кода.

Кто-то придумал эту глупость, и теперь все как попугаи повторяют.

Это не так. Естественно в лиспе есть типы.

что из фич используемого ЯП использовать запрещено.

Это только для растов и плюсов такие гайдлайны есть, как для языков невероятно кривых.

NullPointerException

Внезапно это куда безопаснее, и встречается куда реже, чем скажем неявные преобразования типов, void* и прочие приколы из плюсов.

Кто-то придумал эту глупость, и теперь все как попугаи повторяют.

Ну хорошо, пусть будет CommonLisp, строгий и динамический.

https://en.wikipedia.org/wiki/Type_safety#Common_Lisp :

In general, Common Lisp is a type-safe language. A Common Lisp compiler is responsible for inserting dynamic checks for operations whose type safety cannot be proven statically. However, a programmer may indicate that a program should be compiled with a lower level of dynamic type-checking.[13] A program compiled in such a mode cannot be considered type-safe.

T.e. есть места, в которые компилятор вставляет run-time проверки, потому что они не могут быть доказаны статически. T.e. и бабахнет в этих местах тоже в run-time, о чем я и написал. А еще эти проверки можно отключить, т.e. ни о какой типо-безопасности речи не идет.

Вот ты там написал, что есть много способов затюнить производительность? А каким образом, если система типов такая, что нужно run-time проверки вставлять? И что, код на Rust в это время будет стоять в сторонке, курить, и всячески препятствовать всем попыткам программиста затюнить их производительность?

Это только для растов и плюсов такие гайдлайны есть, как для языков невероятно кривых.

Для для упомянутых тобой С и Java тоже есть. Значит, они тоже кривые?

Rust и Nim в совершенно разных нишах.

В каком языке нету типов?

NullPointerException

Внезапно это куда безопаснее, и встречается куда реже, чем скажем неявные преобразования типов, void* и прочие приколы из плюсов.

Подожди секундочку, ты Rust отверг, по каким-то непонятным причинам, похвалил априори небезопасный C, а потом Java (в которой NullPointerException и которую надо тюнить каком кверху), и теперь оправдываешь выбор глюкодрома на VM еще большей кривостью С++?

T.e. тема не про Rust, а про то, что «лучше Java, потому что С++ кривой»?

о как интересно. и в каких же?

Ну явно не системщина. С другой стороны, после того как я увидел какие ошибки выплёвывает компилятор - я забил на этот язык.

/usercode/in.nim(10, 15) Error: undeclared field: 'nam2e'

Добро пожаловать в 80-е.

define системщина

Как минимум контроль над тем, где выделяются объекты (стек/куча).

http://zevv.nl/nim-memory/

У C++ нет стабильного, единого ABI.

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

В форте

В любом языке есть узкие моменты, но нигде кроме C++ рекомендации «как делать не надо» не затмевают собой все остальные рекомендации

я вон выше определил в лиспе VOP для fact, но с таким же успехом могу сделать VOP для +, который будет мне такой код генерировать какой я хочу. Для стандартных типов, да, для флоатов. И для того чтобы этот новый ассемблерный код заюзать, мне не надо никаких своих типов объявлять, а надо просто перекомпилировать существующий код.

Это как-то контролируется? Я имею в виду, есть ли механизмы ограничения этих самых VOP? Скажем, их можно объявлять только в одном месте, запретить переопределение каких-то вещей итд. Если нет, то

могу сделать VOP для +, который будет мне такой код генерировать какой я хочу. Для стандартных типов, да, для флоатов.

из преимущества резко превращается в огромную дырку.

из преимущества резко превращается в огромную дырку.

Это не C++, чтобы свобода пользователя превращалась в дырки.

Это не C++, чтобы свобода пользователя превращалась в дырки.

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

И да, отвечу на следующий выпад:

Создаём свой тип fast_float и реализуем операторы с помощью SSE. Какие проблемы?

Как бы менять по всей кодовой базе стандартный float или как он там называется, на какой-то свой my_float, при этом с вероятностью 100% где-то что-то сломав, это нормально вообще?

В этом случае со 100% вероятностью не сломается ничего, потому что тайпчекер не даст проводить операции с разными флоатами. При этом можно поменять float на предложенный fast_float ровно в том узком месте, где это нужно, затем под руководством тайпчекера протащить это до самого верха и быть уверенным, что всё остальное работает так же, как и раньше.

Впрочем, ход мыслей лиспера понятен.

Возможность в любом месте переопределить поведение компилятора - это не свобода, это анархия.

Я эту песню слышу уже который год. От людей которые лисп не видели в глаза, разве что на форумах.

У меня на это ответ один и тот же:

Возможность в любом месте писать функции и процедуры - это не свобода, это анархия.

Ну и так далее:

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

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

этом случае со 100% вероятностью не сломается ничего, потому что тайпчекер не даст проводить операции с разными флоатами.

Под «сломав» я это и имею ввиду, а совсем не то что процессор сгорит или что-то в этом духе.

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

Более того, куда там функции, рекомендую лезть проверять сразу кишки компилятора, а за ним и микрокод процессора, дабы чего не вышло, чтобы уж точно ничего «эдакого» случайно не вызывалось.

Вообще, у C++ программистов, и видимо и любителей раста, который тот же самый C++, как я в исходном посте сказал - подобные навязчивые параноидальные идеи тотального контроля встречаются очень часто. Даром что они понятия не имеют о том, что в их язычках никакого особого контроля ни за чем у них нет.

остальной мир уже лет как пятнадцать назад перешел на единый общепринятый стандарт.

Это поэтому строки из C++03 не совместимы со строками из C++11 в gcc по ABI?

этом случае со 100% вероятностью не сломается ничего, потому что тайпчекер не даст проводить операции с разными флоатами.

Под «сломав» я это и имею ввиду, а совсем не то что процессор сгорит или что-то в этом духе.

А, вот оно что. Я-то думал, что под «сломав» имеется в виду некорректная работа программы, а тут речь про сломанные планы на вечер. Тогда, конечно, любой статический анализатор - враг. И тесты лучше не писать, вдруг баг вылезет, придётся исправлять.

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

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