Почему ООП стало более популярным и соответствующие языки и технологии программирования чем то же ФП?

Быстрый, мощный и, при этом надежный? Да ладно. Надежность и скорость, в общем-то, противоречат друг другу.

Да, Rust - все три вещи без компромиссов. Большинство средств защиты вытирается компилятором. Почти весь оставшийся оверхед на безопасность вполне обьясняется что если бы плюсовый код делал бы те же проверки, то стоил бы столько же. Причем проверки отключаются unsafe и другими приемами, если хочется дожать последний 1% производительности. По моему это адекватный подход.

А теперь сравним с языками 90х. О, нужно безопасно! Вкатаем как VM, JIT и сборщик мусора и будем оптимизировать это 20 лет, пока на планете не останется человек 20 понимающих этот код

Сколько человек на планете понимают код LLVM?

Да, Rust - все три вещи без компромиссов.

И тут мы вспоминаем про unsafe.

если хочется дожать последний 1% производительности

Там не процент будет. Там разы на определенных операциях будут (типа перемножения матриц).

А теперь сравним с языками 90х

В 80-х был сделан Eiffel, в котором не было ни VM, ни JIT-а, только сборщик мусора. И сделан он там был как раз для обеспечения надежности.

И тут мы вспоминаем про unsafe.

Выбор каждого, пользоваться или нет. По дефолту не unsafe

Там не процент будет. Там разы на определенных операциях будут (типа перемножения матриц).

Обычно таки процент. А множить матрицы если припечет, то можно на unsafe или в функциональном стиле (вытирается больше проверок)

Выбор каждого, пользоваться или нет.

Да, выбор: быстро или нет.

А множить матрицы если припечет, то можно на unsafe

И опять же приходим к тому, что либо у нас быстро, либо надежно. Просто так и того, и другого не бывает. Ибо надежность она проистекает из контроля за ошибками пользователя. Не все ошибки можно выловить в compile-time (даже когда за это приходится платить усложнением разработки за счет борьбы с компилятором и продумывания лайфтаймов). Следовательно, придется платить за проверки в run-time.

Никаких чудес.

Ну и да, Rust пока еще не доказал свою жизнеспособность в дикой природе. В отличии от Java/C#. Не удивлюсь, если даже на маргинальном Eiffel есть проекты таких масштабов и объемов, которые Rust-оманам пока и не снились.

И опять же приходим к тому, что либо у нас быстро, либо надежно.

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

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

На Rust уже есть проекты глобального масштаба. Firefox, npm registry, Facebook Libra, Google Fuschia, Chrome OS crosvm, Facebook Mononoke. Уже писал тут

Вышел Rust 1.37.0 (комментарий)

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

Смешались в кучу кони, люди. Выходит, что Java или C# — это одновременно и опасные, и негибкие языки.

На Rust уже есть проекты глобального масштаба.

И какой объем кода того же npm registry? Хотя бы миллион строк есть?

Выходит, что Java или C# — это одновременно и опасные, и негибкие языки.

Да. В обеих null, в обеих data races, в обеих мутабельность по дефолту. В Java еще небывалые костыли в стандартной библиотеке, исторически обоснованые. Потом еще default методы туда начали пихать чтобы хоть как-то расширять стандартные интерфейсы

И какой объем кода того же npm registry? Хотя бы миллион строк есть?

Я то откуда знаю.

В Servo - 350 000, в Libra - 135000. Я не очень понимаю зачем гнаться за миллионом, если в Rust экосистема crates развитая. В плюсах тебе насрут миллион быстро очередной реализацией строк, которая как std::string, но немного не такая

Google Fuschia

Ядро на плюсах, nuff said.

Ядро на плюсах, nuff said.

Нет, не nuff said

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

Ну zircon они вроде на чем-то уже готовом основали, а сам реп ОС вот

❯ git clone https://fuchsia.googlesource.com/fuchsia
❯ cd fuchsia
❯ tokei --sort lines
-------------------------------------------------------------------------------
 Language            Files        Lines         Code     Comments       Blanks
-------------------------------------------------------------------------------
 Rust                 5905      1820432      1355617       295681       169134
 C++                  6301      1461621      1090298       137991       233332
 C Header             5970       861858       527097       195273       139488
 C                    2476       820698       491948       200789       127961
 Assembly              250       221164       200386           70        20708
 Markdown             1407       144947       144947            0            0
 Go                    588       108459        85607         9137        13715
 Plain Text            190        89657        89657            0            0
 C++ Header            130        58664        45735         6511         6418
... дальше удалил

Убрал вендоринг, стало пол миллиона, ничего тоже норм. Ну вот короче как хотите так и оценивайте, с crates или без

❯ tokei --sort lines --exclude third_party
-------------------------------------------------------------------------------
 Language            Files        Lines         Code     Comments       Blanks
-------------------------------------------------------------------------------
 C++                  6091      1377061      1031100       123982       221979
 C Header             5015       588458       355527       128357       104574
 Rust                 1499       553309       457061        51199        45049
 C                     498       108981        80543        12583        15855
 Go                    587       108012        85213         9084        13715
 Markdown              969       103776       103776            0            0
 JSON                  162        25459        25459            0            0
...

Я не очень понимаю зачем гнаться за миллионом

Потому что большие и сложные проекты — это как раз проекты в миллионы строк. И то, что сейчас в мейнстриме (по крайней мере из статически типизированных языков) доказало применимость на таких масштабах.

В плюсах тебе насрут миллион быстро очередной реализацией строк, которая как std::string, но немного не такая

Это вам Рабинович напел?

Да. В обеих null, в обеих data races, в обеих мутабельность по дефолту.

Но при этом они дают фору по надежности С и C++.

Дают, полностью согласен. Но С и С++ - нижайший стандарт надежности. Хуже быть не может. Наверное патч Бармина на перле разве что.

Но С и С++ - нижайший стандарт надежности.

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

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

Капец там помойка.

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

Помойка там намного глубже чем кажется. Смотри: больше миллиона строк на расте это third party с помоечных васянских crates. Это совершенно неконтролируемый код совершенно неизвестного качества (читай кишит багами). Удачи такому проэкту, чо.

Грамотные люди

В чём это заключается? Обоснуй.

Я бы ещё понял 3-4 языка, но там-то вообще ад.

Кстати, да. Я, помелькнувший выше, tokei решил заценить, там зависимостей было штук 30, елси не 50. Я в шоке от того, что это вообще работает.

нижайший стандарт надежности. Хуже быть не может. Наверное патч Бармина на перле разве что

А что, у патча Бармина какие-то проблемы с надёжностью?

Быстрый, мощный и, при этом надежный? Да ладно. Надежность и скорость, в общем-то, противоречат друг другу.

Да, Rust - все три вещи без компромиссов

Разрешите возхразить. Во-первых, раст таки несколько замедляет разработку, поскольку требует от кодера точно формулировать свои мысли, так что безопасность здесь - не бесплатное приобретение.

Во-вторых, технологии раста очень хорошо подходили в 80-90х, и должны были бы быть приняты тогда, но уже сейчас встают под сомнение на фоне современныого железа - компилятор не может гарантировать отсутствие race condition или дедлока.

А теперь сравним с языками 90х. О, нужно безопасно! Вкатаем как VM, JIT и сборщик мусора и будем оптимизировать это 20 лет, пока на планете не останется человек 20 понимающих этот код

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

но уже сейчас встают под сомнение на фоне современныого железа - компилятор не может гарантировать отсутствие race condition или дедлока.

data race, он может гарантировать что тебе не порвут указатель на клочья, строку, счетчик из многих потоков

data race, он может гарантировать что тебе не порвут указатель на клочья, строку, счетчик из многих потоков

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

Например?

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

Ну Rust любит понятное дерево ownership, иначе да, unsafe, или что-то третье будет собственником, например circular buffer, slab allocator, arena, что-то на чей lifetime можно сослаться

Ну Rust любит понятное дерево ownership, иначе да, unsafe, или что-то третье будет собственником, например circular buffer, slab allocator, arena, что-то на чей lifetime можно сослаться

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

Ну ничего из этого не будет Send/Sync пока ты не придумаешь как этого добиться. Что это будет - мьютексы, атомарные операции, я не знаю. И естественно если ты прямо компилятор заставишь следить за двусторонней связью то эти связи нужно будет как то хранить вместе и инакпсулировать их одновременное изменение через паттерн внутренней мутабельности. А снаружи например компилятор уже будет защищать пользователя от кривого использования. Сложно что-то тут обсуждать, если круговая связь - задача логики приложения, в другом алгоритме ты бы наоборот захотел разрыв. Компилятор не может в libastral. Главное что он всегда позволяет инакпсулировать все так, чтобы снаружи пользователь твоей либы не накосячил

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

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

А множить матрицы если припечет, то можно на unsafe или в функциональном стиле (вытирается больше проверок)
вытирается больше проверок
вытирается

что имеется в виду?

Но С и С++ - нижайший стандарт надежности. Хуже быть не может.

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

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

Language Files Lines Code Comments Blanks

Что за метрика «Code»?

Строчки с кодом, без комментов и пустых строк