Автор Wayland композитора Way Cooler переписывает своё детище с Rust на C

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

А чем Actix не угодил? Использовать чужой готовый код же значительно дешевле, чем создавать и сопровождать свой (особенно сопровождать).

Да почти всем.

1. Начнем с того, что это типизированные акторы. Типизированный актор это чисто теоретическая модель, которая ни в одном языке не была воплощена в достаточной мере. Даже в самом лайтбенде, который активно продвигал поначалу данный вариант акторов, согласились что это утопичная идея и они их пилят потому что есть просто кому пилить.
2. Автор фреймворка упорно не понимает что такое кроссакторные взаимодействия через футуры. Выражаясь терминологией акки - пайпинг. Без этой простой вещи, построить читабельную программу просто невозможно. Я уж точно не помню точно в чем там проблема, но полностью сделать это как в акке невозможно. Далее иду просто по списку чего там нет без расписывания подробностей.
3. Нет возможности горячей замены диспетчеров и мейлбоксов.
4. Нет шины вотчинга
5. Нет возможностей прямого супервайзинга
6. Нет ремоутинга
7. Нет селектинга рефов
8. Нет сташинга
9. Нет конечных автоматов
10. Нет тесткита (работать с актороми без TDD вообще редкостное безумие)

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

Только в конкретном участке кода.

Ну вы же сами процитировали оригинал, где четко сказано, что

If all you do is write Safe Rust, you will never have to worry about type-safety or memory-safety.

Видите там слово «all»? Так вот, если у вас хотя бы в конкретном участке кода есть unsafe rust, тогда это уже не «all». Или вы будете спорить? Unsafe же rust по сути уже по безопасности как плюсы. Вам также надо будет там все вручную проверить. И вы такой же код можете написать и на плюсах. Выделяйте память на стеке и у вас не будет use-after-free вообще. Потому что free как такового не будет. А там где нужно именно на куче - проверьте вручную все. И получается ровно тот же самый workflow как в Rust.

И с каких это пор у вас borrow-checker бесплатный то? Он что, не тратит время процессора и память? Волшебный какой-то наверное?

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

Примером того, что в Rust хуже интеграция с сишным кодом чем в D является этот топик. В D нет вообще никаких проблем с интеграцией сишной кодовой базы. Язык изначально на это заточен. Нет никакой верхушки айсберга. Любой сишный код тривиально интегрируется в дишный. Подчеркиваю - любой. Полная совместимость с сишным ABI и минимальные отличия в синтаксисе только там где это улучшает код.

Только потому, что вы сравниваете свой любимый D с каким-то вымышленным Rust. В реальном расте всё по-другому.

Да нет. Ваша фраза прозвучала бредово, потому что вы потеряли опору и начинаете просто отрицать мои утверждения без должной аргументации. Т.е. чтобы я не написал - вы это отрицаете. Без размышления и автоматически. Используя аргументы уровня - «пруфца бы», «пример бы», «ваш любимый D», осталось только на личности перейти. Примеров я вам приводил достаточно. Плюс вы еще передергиваете мои слова - когда я говорю, что в процессе разработки может случиться, что для реализации новой фичи вам потребуется добавить новую зависимость, которую вы добавлять изначально не планировали. Вы приводите какой-то непонятный контраргумент - «То есть при добавлении новой зависимости я в принципе не представляю что она делает?» Как вы умудряетесь путать теплое и мягкое? Или это осознанно, так как аргументов нет других?

Почему вам требуется доказывать очевидные вещи? В Rust есть дополнительная фукнциональность, которая отсутствует в плюсах. Таким образом, компилятор плюсов НЕ ВЫПОЛНЯЕТ ту работу, которую выполняет компилятор Rust, например не запускает borrow checker. Поэтому компилятор плюсов БЫСТРЕЕ чем компилятор Rust при прочих равных. По определению.

П

Спасибо за развернутый ответ!

Если можно, то несколько вопросов для углубления.

Начнем с того, что это типизированные акторы.

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

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

А зачем вообще горячая замена диспетчеров и, особенно, мейлбоксов? Если я правильно понимаю, то «горячая замена» — это когда актор сперва работал на диспетчере D1, а затем его переключили на D2. Но зачем это нужно в принципе?

Нет возможностей прямого супервайзинга

Насколько это актуально для нэйтив кода?

Нет селектинга рефов

А это что?

Выделяйте память на стеке и у вас не будет use-after-free вообще.

Ага, щаз:

std::array<int, 32> & func() {
   std::array<int, 32> data;
   ...
   return data;
}

auto & data = func();
data[0] = 0; // Oops!

Такой бред даже комментировать не буду.

Такой бред даже комментировать не буду.

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

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

Не типизированный актор реализует хендлинг сообщений на основе определения их типа в единственном хендлере программными средствами (if, switch, match и т. д.). Это позволяет закидывать в актор сообщение любого типа и отвечать на него любым другим типом. Типизированные акторы реализуются семантикой самого языка. Под каждую пару тип запроса <-> тип ответа создается собственная реализация. Хендлер типа A <-> B получив на вход А не может ответить типом С. Типизированные акторы в теории должны работать быстрее чем не типизированные, поскольку правила обмена сообщениями определяются на этапе компиляции. На практике это бессмысленно, поскольку в 99 из 100 случаев работа выполняемая обработчиком сообщения в сотни и тысячи раз длиннее, чем пробег по десятку условий для определения типа сообщения.

А зачем вообще горячая замена диспетчеров и, особенно, мейлбоксов? Если я правильно понимаю, то «горячая замена» — это когда актор сперва работал на диспетчере D1, а затем его переключили на D2. Но зачем это нужно в принципе?

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

Нет возможностей прямого супервайзинга
Нет селектинга рефов

Частично, например один из вариантов супервайзинга это ограничение времени жизни подлежащих акторов. Т е вот есть у вас актор А, он породил акторы B, C и D. Если актор А будет остановлен, B, C и D полетят за ним за компанию. На супервайзинг опирается ремоутинг поскольку при супервайзинге, акторы образуют деревья по которым можно производить поиск. Селектинг рефов это операция поиска по этому дереву. И при работе через сеть, это единственный вариант получить реф удаленного актора.

Ага, щаз

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

То есть вы сравниваете языки, в которых ничего не смыслите, но сливаюсь я. Логика / 0.

Спасибо за еще один развернутый ответ!

Хендлер типа A <-> B получив на вход А не может ответить типом С.

Понятно. Но, насколько я знаю, основной бенефит типизации состоит не в повышении быстродействия, сколько в проверке корретности операций над актором (в компайл-тайм или посредством каких-то внешних анализаторов) + возможности контролируемого комбинирования акторов. Грубо говоря, если есть актора A1, получающий m(A) и отвечающий m(B), и есть актор A2, получающий m(B) и отвечающий m(C), то можно создать цепочку A1 -> A2, но нельзя A2 -> A1.

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

Т е вот есть у вас актор А, он породил акторы B, C и D. Если актор А будет остановлен, B, C и D полетят за ним за компанию.

А, понятно о чем речь.

То есть вы сравниваете языки, в которых ничего не смыслите, но сливаюсь я. Логика / 0.

Ну вы перечитайте нашу переписку. Я все-таки стараюсь приводить аргументы, примеры. Часть моих аргументов подтверждается другими участниками, часть ими опровергается. А вы же ограничиваетесь общими фразами, а теперь еще безосновательно меня обвиняете в некомпетентности. В начале обвиняли, что я Rust не знаю - ну тут еще понятно. Но теперь еще и обвинили, что я и D не знаю - хотя вы же выше утверждали что это мой «любимый D». И у вас таких нестыковок хватает. Ну чистой воды слив. Без обид.

Но теперь еще и обвинили, что я и D не знаю

Речь шла про C++. Это вы сюда приплели D.

А вы же ограничиваетесь общими фразами

Только в ответ на ваши пространные вбросы. Я в каждом сообщении просил привести конкретные примеры. Вы же продолжаете шарманку про то, что в D всё ок и вообще зсб, а вот в этом вашем расте всё плохо, не знаю почему, но всё равно плохо.

Понятно. Но, насколько я знаю, основной бенефит типизации состоит не в повышении быстродействия, сколько в проверке корретности операций над актором (в компайл-тайм или посредством каких-то внешних анализаторов) + возможности контролируемого комбинирования акторов. Грубо говоря, если есть актора A1, получающий m(A) и отвечающий m(B), и есть актор A2, получающий m(B) и отвечающий m(C), то можно создать цепочку A1 -> A2, но нельзя A2 -> A1.

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

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

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

Печально, что вместо адекватного взгляда на мир, вы скатываетесь на уровень, когда любая критика раста вами вопринимается в штыки. Причем вы автоматически обвиняете в таком подходе других. Что говорит о том, что раст у вас полуосознанный выбор, ибо разумных аргументов у вас нет. Я уже не раз писал, что раст интересный язык. Хайпа в нем только много. И вы это подтверждаете своим поведением. У меня нет никакой шарманки. Про то, что D лучше Rust я сказал только строго в контексте этого топика - потому что действительно в D нет никаких проблем с использованием сишной кодовой базы от слова совсем в отличие от Rust. В D есть свои проблемы, есть вещи в Rust которых нет в D. Каждый инструмент хорош для своей задачи. А у вас просто шоры на глазах.

Я в каждом сообщении просил привести конкретные примеры.

Ну что поделать, если вам приводят примеры, вы тупите, отмахиватесь аргументами из категории «вкусовщина», а потом жалуетесь, что конкретики то вам и не хватает. Объяснять что-то вам с подробными примерами/объяснениями — это только время тратить.

Понятно, спасибо за пояснения.

Ссылку на пример.

потому что действительно в D нет никаких проблем с использованием сишной кодовой базы от слова совсем в отличие от Rust.

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

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

Вот, для тщачтельного изучения: Автор Wayland композитора Way Cooler переписывает своё детище с Rust на C (комментарий)

ЗЫ. С друзьями как вы Rust-у и врагов не нужно.

К этому сообщению у меня претензий особо и не было, если вы перечитаете мой ответ на него. Меня лишь смутило, что «современный С++» вы сравниваете с Си, а не с Rust. Что странно.

Какое прекрасное признание в том, что вы не читаете, что вам пишут.

То есть цитирую я бездумно. Ну зсб вывод.

У нас тут как бы холивар на тему ЯП идёт, а не рептилоидов с Нибиру. А значит под конкретикой подразумевается код, бенчмарки, тесты и прочая статистика. А не пространные бредни типа «раст медленный из-за борроу-чекера» (с). Откуда это взялось - не ясно. Явно тараканы нашептали, ибо авторы компилятора серьезно обеспокоены временем сборки и четко знают из-за чего проблемы. Спойлер: не из-за борроу-чекара, а из-за мономорфизации и неоптимизированного IR, который сваливают на плечи LLVM. Но это может знать только тот человек, который хоть немного следит за языком.

Меня лишь смутило, что «современный С++» вы сравниваете с Си, а не с Rust.

Вообще-то я «современный C++» сравниваю с несовременным. Не с Си.

Но из-за своей тупости и невнимательности вы этого не замечатее.

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

Но вы и этого не понимаете.

Посему и приходим к неутешительному для вас выводу: «Объяснять что-то вам с подробными примерами/объяснениями — это только время тратить.»

ЗЫ. С друзьями как вы Rust-у и врагов не нужно.

В точку.

Не забываем про царя.

Этот топик называется «Автор Wayland композитора Way Cooler переписывает своё детище с Rust на C (комментарий)». Этот топик посвящен проблемам, которые появляются, когда необходимы Rust биндинги к сишному коду. И тут внезапно на 8 странице выясняется, что в расте нет никаких проблем. Ну вы почему людей за дебилов то считаете? Ну и зачем усугубляете свой слив? Вы хотите получить репутацию неадекватного человека? А к этому все и идет.

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

Не забываем про царя.

Разве забудем?)) У нас нет такого выбора))

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

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

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

У меня пару раз как-то само собой случалось, что начинал писать программу на Си, в итоге она оказывалась на Perl =)

Давайте на примерах, чтобы вам было понятнее, так как с реальными биндингами вы дел не имели. Типичный пример: есть древовидная структура на Си. Каждый узел - это указатель. И есть функция, которая удаляет узел и все его дочерние элементы. Если мы обращается к удалённому элементу - получаем segfault. Теперь у нас есть биндиги на божественном D, который якобы всё делает сам. Мы вызываем функцию удаления элемента и затем обращаемся к его дочернему элементу, который уже был удалён. Что произойдёт в этом случае в D? Я с D не знаком, поэтому не знаю.

Вы хотите получить репутацию неадекватного человека?

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

Вместо конкретики,

Куда уж конкретнее:

«Вообще-то я «современный C++» сравниваю с несовременным. Не с Си.»

вы называете всех дураками

Не всех. В данной теме пока только двоих, если не сбился со счета.

Но он даже близко не подошёл к гарантиям раста.

В очередной раз вынужден сказать очевидную вещь: язык C++ выбирают не из-за гарантий. Соответственно, для кого-то отсутствие Rust-овских гарантий в C++ — это не баг, это фича.

язык C++ выбирают не из-за гарантий

С этого и нужно было начинать. Я обсуждаю ЯП, а не экономическую целесообразность. Если кому-то нужно начать проект, который планируется вести лет так 10, а то и больше, то брать Rust - самоубийство. Конечно вы можете поспорить с тем, что обсуждать ЯП в отрыве от реального мира бессмысленно, но это лор как ни как.

Но по-хорошему, нужно вообще Java брать. Но это уже совсем другой холивар.

Если кому-то нужно начать проект, который планируется вести лет так 10, а то и больше, то брать Rust - самоубийство.

Брать Rust — самоубийство?

Вот это поворот!

А как же. Я об этом уже не раз писал, но не в этой теме. Я же не фанбой, который вы пытаетесь меня изобразить.

Я об этом уже не раз писал

Можно ссылочку на список причин? А то я прям в шоке.

Давайте на примерах, чтобы вам было понятнее, так как с реальными биндингами вы дел не имели. Типичный пример: есть древовидная структура на Си. Каждый узел - это указатель. И есть функция, которая удаляет узел и все его дочерние элементы. Если мы обращается к удалённому элементу - получаем segfault. Теперь у нас есть биндиги на божественном D, который якобы всё делает сам. Мы вызываем функцию удаления элемента и затем обращаемся к его дочернему элементу, который уже был удалён. Что произойдёт в этом случае в D? Я с D не знаком, поэтому не знаю.

Так вы еще и не знаете что такое биндинги. Ну зачем вы так себя выставляете?

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

Если вы хотите добавить функциональность, которой нет в сторонней библиотеке, например, вы хотите делать проверку на корректность, тогда вы пишите дополнительный код на своем языке. И это уже называется враппер - wrapper. Биндинги (bindings) и врапперы (wrapper, они же обертки) это разные вещи. Биндинги это низкоуровневый доступ к сторонней библиотеке и они обязательны для работы с ней. Врапперы это высокоуровневый сахар, они не обязательны, но могут упростить работу с либой.

Вы хотите получить репутацию неадекватного человека?

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

Жесть какая-то. О каком анониме вы ведете речь, почему его мнение должно меня задевать? Что за ерунду вы пишите?

Брать Rust — самоубийство?
Вот это поворот!

Я даже не знаю как это прокомментировать)) Сюжет делает крутой поворот оставляя позади голливудские триллеры)))

Разве это не очевидно? Кровавый интерпрайз не будет вкладываться в язык 4-х лет отроду, ещё и без стандарта и прочих бумажек. А вдруг он завтра загнётся?

Биндинги это просто способ указания языку как вызвать код написанный на другом языке.

Как бы нет. Это FFI. А биндинги, это: https://en.wikipedia.org/wiki/Language_binding

In computing, a binding from a programming language to a library or operating system service is an application programming interface (API) providing glue code to use that library or service in a given programming language.

glue code

... bindings are wrapper libraries that bridge two programming languages.

То есть речь идёт про сахар, который превращает сишку в что-то удобаваримое на нужно нам языке.

Если сама сторонняя либа у вас сегфолтится

При чём тут либа? У нас автомагические биндинги на D, которые «делают всё за нас». И код я вызываю из D. И сегфолт происходит из-за кривых биндингов, а не из-за либы. Либа вообще не знает что её из D вызывают.

Биндинги (bindings) и врапперы (wrapper, они же обертки) это разные вещи.

Кажется вы начинаете что-то понимать. Ну если в этой терминологии рассуждать, то разницы в написании «биндингов» между D и Rust нет. Но вы утверждаете обратное. Хотелось бы увидеть конкретные примеры.

Ну и в завершение: я дал вам конкретную задачу, а вы свели всё к буквоедству. Мол это уже врапперы, а не биндиги. Я так не играю. И прочие типичные манёвры.

Биндинги это просто способ указания языку как вызвать код написанный на другом языке.

RazrFalcon прав, это не биндинги.

Вот, к примеру:

https://www.gtk.org/language-bindings.php

Language Bindings (or 'wrappers') allow GTK to be used from other programming languages, in the style of those languages.

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

При чём тут либа? У нас автомагические биндинги на D, которые «делают всё за нас».

Вот это вообще перл равный тому, что использование Rust это самоубийство. Как это причем либа, к которой вы пишите биндинги? Вы же к ней биндинги пишите, значит эта либа очень даже причем.

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

Я вам написал, что сегфолт в либе == сегфолт в приложении. Вы читаете мои посты вообще? Если вы хотите предотвратить сегфолт, вы можете делать эту обработку во враппере. Проблема Раста в том, что весь стек должен быть написан на Расте. А если вы используете стороннюю либу то процесс может значительно усложниться, потому что Раст слишком многое приносит в жертву. Что в данном случае и произошло. Конкретно автор way cooler написал следующее:

Ultimately, wlroots-rs was too difficult to write. The mental overhead of attempting to wrap complicated C libraries with Rust is too demanding. This complexity often leads to a RiiR mindset, which I am strongly against. So, the compositor is now written in C.

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

RazrFalcon прав, это не биндинги.

Да пусть это будут не биндинги. При чем здесь это? Все, что я утверждаю, это что Раст просит слишком большую цену за свое использование. Этот топик этому подтверждение.

Разве это не очевидно?

Нет.

Кровавый интерпрайз не будет вкладываться в язык 4-х лет отроду, ещё и без стандарта и прочих бумажек. А вдруг он завтра загнётся?

Как хорошо, что кровавый энтерпрайз не задумывался об этом ни при появлении Erlang-а, ни при появлении Go.

Ещё раз, без фантазий типа «весь стек должен быть написан на Расте» и «Раст слишком многое приносит в жертву». Как вы будете решать данную задачу задачу в D и почему её решение в Rust должно быть сложнее? Только с кодом, а не с фантазиями, брызганьем слюной и переходом на личности.

The mental overhead of attempting to wrap complicated C libraries with Rust is too demanding.

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

Все, что я утверждаю, это что Раст просит слишком большую цену за свое использование.

И это ваше субъективное мнение, которое вы безуспешно пытаетесь превратить с объективное.

ни при появлении Erlang

Мне казалось что Erlang писала Ericsson, а не васяны из мозилы.

ни при появлении Go

Разве он уже пролез в кровавый энтерпрайз? Видел пару проектов на нём, не более.

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

Мне казалось что Erlang писала Ericsson, а не васяны из мозилы.

Ericsson в свое время выставил Erlang на мороз. Чуть ли не в буквальном смысле. С уходом автора языка и запретом на использование Erlang в пользу Java (емнип, именно Java).

Разве он уже пролез в кровавый энтерпрайз?

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

Крупные конторы его активно используют.

Они и Rust используют. Но речь шла про долгосрочные проекты. Но вам важнее «делить оппонента на ноль» чем вести конструктивный разговор.

Но речь шла про долгосрочные проекты.

Я вам по секрету скажу, что мало какой проект в самом своем начале имеет перспективы на 10 лет вперед. Большинство проектов стартуют на том, что удобно здесь и сейчас. В 2014-ом году для многих Go оказался тем, что удобно здесь и сейчас (а для кого-то еще и в 2012-ом). Сейчас тоже самое и с Rust-ом происходит.

Вы, например, взяли для своих пет-проектов Rust. И что, вы сделали это с прицелом на то, что года через 3 будете с нуля переписывать на какой-нибудь zig или еще какую-нибудь модную хипстерскую хрень?

Не нужно переходить на личности. Я пристально обращаю ваше внимание на стиль изложения, который вы решили допустить в последних постах. Я ни разу не назвал Раст ужасным и страшным, ни разу не назвал D прекрасным. И вообще, в отличии от вас я не использую ни сравнительные, ни тем более превосходные степени. Я вообще стараюсь эмоции не использовать в обсуждении инженерных вопросов. Хотя перл про то, что использование Раста это самоубийство, признаюсь, вызвал сильные эмоции, знатно повеселили вы меня. Более того, я не использую фантазии, не брызгаю слюной и не перехожу на личности. Использование же вами подобных технологий для принижения значимости ответов оппонента означает лишь то, что сухих фактов и аргументов у вас нет от слова совсем.

Я еще раз попробую описать суть ситуации, хотя я уже вижу, что вы не воспринимаете факты и примеры, но это больше для стороннего зрителя. Итак, автор way cooler четко написал, что модель безопасности Раста слишком сложна, чтобы написать биндинг к нетривиальной библиотеке. Поскольку на D нет такой модели, как в Расте, то и написать биндинги будет также просто как и на плюсах. По степени интеграции с сишным кодом D только немного уступает плюсам.

Сделаю еще заход с другой стороны - у Раста есть повышенные гарантии безопасности, это фишка языка. А у D есть гарантии 100% интеграции с сишным кодом, скажем так. Это тоже фишка языка. И вот в случае с way cooler выяснилось, что фишка Раста усложняет разработку на нем до такой степени, что люди переписали часть кода на си. А фишка языка D в данном случае играет в пользу этого языка. Но это именно в данном случае. В другом случае может быть все по другому. Но вы же это не воспринимаете, к сожалению.

Необходимость следования строгой модели, использование borrow checker - это та плата за гарантии, предоставляемые языком Rust. В отдельных случаях это адекватная цена и тогда Раст на коне, в других случаях это неадекватная цена и тогда Раст уже не подходит для использования. Автор way cooler это наглядно продемонстрировал. Это не говорит о том, что Раст ужасный и страшный и тем более не говорит, что его использование это самоубийство. Это говорит о том, что у всего есть сильные и слабые стороны. Поэтому любой инструмент нужно использовать с умом исходя из конкретной ситуации.

А своим поведением вы только вредите расту, полностью согласен с eao197

И что, вы сделали это с прицелом на то, что года через 3 будете с нуля переписывать на какой-нибудь zig

Я взял язык, который мне больше всего нравится. Что там будет через n лет мне без разницы. Я могу просто забить на проект и всё.

А если я вкладываю кучу денег, например, в банковскую прогу, то я хочу просчитать риски. И поэтому все банки на жирной жабе, где даже специально фиг что сломаешь. Но зато за Java стоит Oracle, а это куча бабоса, сертификаты и прочие бумашки которые важны энтрепрайзу. Ну и «специалистов» на джава столько, что хоть лопатой греби. Go такое даже не снилось. Хотя за ним и гугл.