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

С чего бы JS?

В веб-фронтенд весь мир чтоли уперся, и больше ничем не занимается? А ты точно не фронтендщик, с такой то эрудицией?

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

В расте это в принципе невозможно.

Так тебе шашечки или ехать?

C:

struct foo { int a; int b; };
/*...*/
struct foo my_foo;
my_foo.a = 1;
my_foo.b = 2;

C++/Rust/etc:

https://external-preview.redd.it/6KXBnnAAlbCsV5A-4d23dS-FrxjNxyO5FGVMKIL_SCk.gif?format=mp4&s=94527beeb774bc9c5dfcbfcdfe20a1d33a0bf650

Допустим есть большая кодовая база.

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

Впрочем ход мыслей пользователей Rust понятен.

Вот в этом проблема:

дошли руки

Руки не могут адекватно оценить ничего непривычного – «мышечная» память нарабатывается годами использования, и всё непривычное кажется кривым. На начальных этапах приходится доходить мозгами.

Руки не могут адекватно оценить ничего непривычного – «мышечная» память нарабатывается годами использования, а всё непривычное кажется кривым. На начальных этапах приходится доходить мозгами.

Дак если бы! Суть в том, что это все тот же привычный C++, с таким же подходом к языкостроению, и всеми его «прелестями».

Такого уровня дебилизма даже от вас сложно было ожидать.

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

Зачем руст если есть ninja компилятор , только вот я думаю как его теперь сгибридить что бы он был за место make , но компилил как ninja так же быстрее в десять раз чем unix-makefile

Ты устарел

struct foo my_foo = {.a = 1, .b = 2};

на rust кстати почти так же.

https://gcc.godbolt.org/z/m8Jk_4

Так в C++20 еще компактнее :)

https://gcc.godbolt.org/z/mfKcqL

вы все устарели

struct foo my_foo = {1, 2};

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

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

В Java и .NET проблема решается применением обфускаторов байт-кода. Для C++ проблема решается разбиением на заголовочные и объектные файлы. Для Ады решение проблемы заложено в сам язык.

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

Из команды раст чувствуется некоторый фанатизм по отношению к опенсорсу, и это настораживает.

Что касается рантайма, то в случае раста им можно пренебречь - настолько он мал.

Go лучше всего характеризует умственно-отсталый суслик

суслик, ты Go ни разу не пробовал. какое право ты имеешь открывать на него страницу?

я понял.. тебе в писатели надо, а не в программисты.

джава даже близко не дает тех гарантий что дает safe-код в rust

:facepalm:

За что люблю Растишечку - всех дебилов отсеивает безукоризненно.

Кто есть царь и есть ли у него царевна?

царь - эт я. давайте мне мою царевну!

Аз есмь царь!

ты - самазваниц!

Это же новый C++.

Ну вообще-то да.

Ну вообще-то нет.

новый C++ - это D

новый C - это Go

а rust - я не знаю - ни к селу, ни к городу

а давайте альбатроса забаним?

Такого уровня дебилизма даже от вас сложно было ожидать.

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

Я правильно понимаю, что ты пишешь на виртуальном ассемблере для виртуальной машины?

За шо? Он еще ничего итт не сделал.

Я, в свои 12 лет, тоже странно выражался.

Если бы компилятор Rust не поддерживал SSE/AVX - можно ли было бы их туда добавить? Ответ немного предсказуем.

Открываешь сорцы компилятора и добавляешь.

Что за привычка вырывать гланды через задницу?

Это не виртуальная машина, а нижний уровень компилятора. Ассемблер самый настоящий, транслирует в самые настоящие машкоды.

Через задницу это как раз вот оно. Когда нормальной расширяемости в языке нет, и приходится делать вот как ты сказал.

К тому же я подозреваю, код компилятора там крайне нетривиальный, и добавить целый SSE, это не раз-два, и 100 строчек написать, как на лиспе.

Окей, я понял. Круто, что Лисп дает такую возможность, но ты ведь не станешь писать свои программы на ассемблере, иначе зачем тебе Лисп?
Это как если бы я написал 100500 сишных биндингов к программе на Пайтоне, а потом сказал бы, что Пайтон сравним по производительности с Си.
Короче, речь немного о другом шла.

На крестах даже наколенные поделки на 10000 строк компилируются со скоростью черепахи. i5 не хватает, чтобы просто сделать make && ./myapp, приходится еще и ждать. Индустрия вомгле.

SBCL и так оптимизирует неплохо, там выше пример есть. Узкие места и всякие вычисления можно ускорить с помощью вот этого ассемблера и SSE/AVX и быть по производительности вполне себе на уровне C или C++ с ассемблерными же вставками.

К тому же я подозреваю, код компилятора там крайне нетривиальный, и добавить целый SSE, это не раз-два

А добавить грамотную и полную поддержку SSE как compile-time evaluation — это так легко и просто, можно подумать.

Через задницу это как раз вот оно. Когда нормальной расширяемости в языке нет, и приходится делать вот как ты сказал.

О какой расширяемости речь, если ты фактически предлагаешь реализовать сам компилятор как compile-time expression evaluator. Можно тогда сразу взять m4 и реализовать компилятор как набор макросов, транслирующих исходный текст в текст на асме — расширяемее некуда.

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

100 строчек написать, как на лиспе.

Это если лисп-машина знает, что такое SSE. Или ты сразу в машкод собрался транслировать, минуя байт-код?

Вообще-то байт-кода там нет.

И если SBCL SSE инструкций не знал бы тогда это ну 200 строк.

А это символьное представление чего?

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

compile-time expression evaluator

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

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

Зачем на m4? У любого более-менее вменяемого языка компилятор написан на нем самом.

новый C++ - это D

С этим более-менее можно согласится

новый C - это Go

Паскалевский :=, паскалевское объявление переменных var x Type, сборка мусора и прочий «многопроцессный» мусор.

Как это может быть новым C?

Машкодов, внезапно. Это называется «ассемблер».

Собственно второй столбец слева это они самые, машкоды в 16-ричном представлении.

; disassembly for FACT
; Size: 60 bytes. Origin: #x1003469F80                        ; FACT
; 80:       840425F8FF1020   TEST AL, [#x2010FFF8]            ; safepoint
; 87:       31C0             XOR EAX, EAX
; 89:       31C9             XOR ECX, ECX
; 8B:       4885DB           TEST RBX, RBX
; 8E:       7D09             JNL L1
; 90: L0:   488BD1           MOV RDX, RCX
...

Вообще не понимаю, зачем в 2к20 нужны компилируемые языки. Это устарело. Железо достаточно дешёвое, чтобы экономить на нём. Но нет же, есть пердолики, которые задротят в раст и кресты, пытаясь понять, что лучше. В 2к20 достаточно питона и джавы, которые покрывают 146% потребностей.

Зачем на m4? У любого более-менее вменяемого языка компилятор написан на нем самом.

Ну вот берешь шланг, написанный на C++, и расширяешь как хочешь. Звучит логично? Логично.

для описания расширяемости конпилятора

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

Всё жду, когда станет возможна чисто функциональная реализация компилятора C++ на шаблонах — вот это будет пушка. Мы встроили компилятор в компилятор, чтобы вы могли компилировать ваши сорцы в то время, пока компилируются ваши сорцы.

Машкодов, внезапно. Это называется «ассемблер».

Так это еще и к x86 гвоздями прибито?! Закопать. Кодеров уволить и выслать в Антарктиду стеречь пингвинов.

Ну вот берешь шланг, написанный на C++, и расширяешь как хочешь. Звучит логично? Логично.

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

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

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

Конкретный пример естественно прибит, там x86_64 инструкции, потому как я на x86_64 его запускаю.

Но SBCL, естественно, не только x86_64 поддерживает: http://sbcl.org/platform-table.html

Набор VOP в SBCL вообще и является средством абстракции платформы, в них компилируется первое, машинно-независимое, представление в виде Flow Graph.

во-вторых это довольно нетривиальная задача

Которая простым макросом и инлайном не решается.

Не решается, ессно.

Где это в C++ есть макросы для бинарных операторов?

веб-фронтенд

Ваша информация устарела лет на 10.

Фича сомнительной нужности.

Побежал, клоун, доказывать нужность макросов для бинарных операторов. Время пошло дошколёнок

Для C++ проблема решается разбиением на заголовочные и объектные файлы.

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

Из команды раст чувствуется некоторый фанатизм по отношению к опенсорсу, и это настораживает.

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

Что касается рантайма, то в случае раста им можно пренебречь - настолько он мал.

Напомните где там рантайм?

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

Развитие идет и идёт, а кресты тормозят и тормозят, а прикладной код падает и падает….