Multicore OCaml таки вмержат в апстрим

Хз, тебе видней наверное..

Запорожец /как и вэб/ каким боком не поверни всегда остается ЗАПОРОЖЦЕМ …

Как ПМ решит, так и будет.

Модель работы с памятью, вынесенная на уровень системы типов, когда потенциально некорректный/рейсовый код не компилируется

В циклоне было уже в 2002.

Дык я наоборот топлю за WebAssembly.

И что? Где твой циклон?

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

Дык я наоборот топлю за WebAssembly.

В смысле топите?

И правильно.  
Нас на мякине не проведешь ...

В циклоне было уже в 2002.

А не мог бы ты показать, где именно? Там были Non-NULL pointers и вроде как всё. В остальном это тот же C. Про отслеживание владения значением я нигде ничего не вижу.

Для души пишешь, или компания Хаскелль использует?

А все понял тебя.

Второе.

Так они сейчас все не в натив. Это не сишечка твоя благородная.

Rust, Go, OCaml в натив

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

Не говори «хоп»... Будущее раста еще не так очевидно.

А не мог бы ты показать, где именно? Там были Non-NULL pointers и вроде как всё. В остальном это тот же C. Про отслеживание владения значением я нигде ничего не вижу

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

Влажные фантазии борцов против Раста вроде тебя

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

Так это всё и до циклона было. Это всё не то, за что любят Rust.

Reason попердолило

А в чём причина?

скала сильно подкосила позиции окамля

ЛОЛ ЧТО? Они вообще никак не пересекаются.

Влажные фантазии борцов против Раста вроде тебя

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

скала сильно подкосила позиции окамля

ЛОЛ ЧТО? Они вообще никак не пересекаются

Разве что из-за того, что окамль вообще нигде не используют.

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

Я «люблю» руст, потому что это хороший язык в сравнении с C/C++ и конкурирующий с ними примерно в той же нише. В кавычках, потому что любить языки программирования — довольно спорное занятие в принципе. В гугломамазон идти никогда не собирался и не собираюсь. Что со мной не так?

Разве что из-за того, что окамль вообще нигде не используют.

Твой визави прав. Камл протух ещё до того, как шкалка набрала обороты. А то там можно утверждать, что Java убила OCaml. Что, в принципе, не лишено смысла.

это не грамотная архитектура языка

Хорошая попытка. Ты тут уже год распинаешься с голословными утверждениями которые ты выдаешь за какой-то консенсус. «Ну конечно же, всем очевидно что у Раста нету грамотной архитектуры языка». Лол, ну-ну, у твоей мамки нету грамотной архитектуры

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

Полгода. Где-то в апреле я ткнул в него палочкой, и оттуда потекла рекордно медленная компиляция при околонулевой пользе от «безопасности» в обычных офисных софтинах. Я понял, что здесь что-то не чисто. Оказывается, проблема с очень долгой компиляцией была известна еще при внутренней разработке в мозилле, и решали ее при помощи «ну ничего, попилю другую ветку/другой проект те полтора часа, пока у меня компилируется rustc». То есть, с ней не сделали ничего. "Зачем лишать себя работы?". С душой, от SJW, для SJW. «Ваше говно C++ протухло, мы принесли вам свежего говна».

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

К сожалению, в нынешней экономической модели мышление на несколько лет вперед никому не нужно: создал стартап, получил деньги от инвестора, стартап обанкротил или продал — а сам остался с денежками. Люди работой занимаются, а не какой-то дебильной архитектурой парятся. В том числе в мозилле. Ты думаешь, там был хотя бы один человек в мозилле думал «ой, как же вертехуа будет моим языком пользоваться? ему же, наверное, неудобно будет, если я фичанейм в таком виде оставлю»? Грейдон Хор, наверное, да. Всё, больше никто, и в дальнейшей разработке он толком не участвовал.

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

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

Давай я тебе, как функциональщику функциональщику, объясню, почему «ниша C/C++» — это уже давно бессмысленное понятие.

https://datasheet.octopart.com/QD8087-Intel-datasheet-38976620.pdf

NVidia 3090 из 30 млрд транзисторов на частоте 1400 МГц производит 30 триллионов умножений в секунду:
30*10¹² / (30*10⁹/10⁶ * 1,400*10⁹) = 0.7 операций на герц на мегатранзистор.

https://www.researchgate.net/publication/2975317_A_32_X_32-bit_Multiplier_Usi...

Умножитель на 32 бита (самый тяжелый узел, складыватель-вычитатель-делитель требуют сильно меньше транзисторов) на 25 тыс транзисторов, технология 2 мкм, хорошие процессоры имели 16 МГц тактовой частоты в то время, время умножения 60 нс, то есть 16 миллионов умножений в секунду:
16*10⁶ / (25*10³/10⁶ * 16*10⁶) = 40 операций на герц на мегатранзистор. В 50 раз околоидеальный вычислитель быстрее видеокарты!

Процессоры того времени тоже имели где-то 10-20 MIPS, но при этом состояли из сотен тысяч транзисторов (например, 300 тыс в ARM3), таким образом все равно на порядок отставание от идеального вычислителя.

Intel I9-9900K с 2 млрд транзисторов, и, так уж и быть, поставим ему условно частоту тоже 1400 МГц (это все равно не повлияет на порядок результирующего значения) имеет производительность 400 млрд операций в секунду:
0,400*10¹⁵ / (2*10¹²/10⁶ * 1,400*10⁶) = 0,14 операций на герц на мегатранзистор.
Правда, это буквально одна-две инструкции имеют такую производительность из всего набора команд процессора, потому что это подразумевает 90 операций за цикл ядра при частоте 5 ГГц, что, очевидно, есть недостижимая мечта для большинства инструкций. Более реалистичной будет цифра в 40 млрд операций в секунду, учитывая предельную пропускную способность памяти 40 ГБ/с, и тогда мы получаем 0.014 операций на герц на мегатранзистор — в 3000 раз меньше идеального умножителя. Три порядка!

Зачем я всё это пишу? Не существует высокопроизводительных вычислений на ЦП. «Компилятор GCC. в который вложено миллионы человекочасов, дает код на 50% быстрее наивной реализации компилятора TCC, написанного в одно рыло за каникулы» — нужно читать как «GCC, выдает код такой же производительности, как любая другая реализация компилятора Си любого качества». Да, есть векторизация, которая позволяет получить прирост на порядок, а то и два, но это очень узкий спектр задач. Да, даже два раза разницы производительности позволяют обогнать конкурента по рынку в битве за колбасные огрызки, но нужно понимать, что вся эта драка изначально происходит в помойной яме.

Весь трафик фейсбука (порядка 100 млн запросов в секунду) можно обработать на единственном процессоре. Например, самые быстрые хэш-таблички обрабатывают порядка МИЛЛИАРДА запросов к хэш-таблице в секунду. Топовые сервера для ЦП обрабатывают десятки миллионов. Да, будут проблемы с накопителями для хранения жырного статического контента, плюс оперативной памяти под это дело нужно дофига — тот же IBM вполне себе делает z15 с памятью до 40 ТБ. И SAP HANA вполне справляется с миллионами OLTP запросов в секунду на подобных машинах при терабайтных объемах БД.

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

Суть последней проблемы, трудности разработки, заключается в неудобной модели программирования — на обычном ЦП тьюринг-архитектуры очень тяжело писать софт. Классические машины Тьюринга, типичным примером которой является Brainfuck, очевидно крайне тяжелы в применении. Но менее очевидные brainfuck-и, вроде ассемблера, уже не вызывают столько пессимизма. Классический Тьюринг — это архитектура, получившая популярность во времена, когда вычислителей было мало, один и тот же вычислитель переиспользовали по сто раз в одной функции, оперативной памяти тоже было мало, она была дорогая, и каждый байт гоняли в хвост и гриву. Устаревший Quicksort, сортирующий по месту, когда-то был одним из самых эффективных алгоритмов, но это уже давно не так, поскольку чрезмерное применение условного ветвления даже на обычных ЦП сильно бьет по производительности.

Таким образом, если мы пишем «высокопроизводительный» софт, то это либо GPGPU, либо FPGA, либо ASIC. C/C++ для CPU — это глубоко устаревшие языки, по иронии судьбы использующие принципы построения оптимизирующих компиляторов, изначально применявшиеся в фортране. Используют C/C++/Fortran по той же причине, что и питон — потому что есть готовые решения. Не писать софт намного дешевле, чем писать его на самом лучшем языке программирования в мире. Но народ настолько привык хавать одно и то же древнее говно мамонта, что когда народу показывают то же говно мамонта, только в профиль, вроде Rust, то народ видит в этом какую-то инновацию. У меня были идеи аналогичного ЯП, но я даже не пытался их конкретизировать и реализовать, потому что понимаю, что это всё без шансов устарело и никому не нужно: ни Rust, ни его родственники Fortran, Си, и C++, по крайней мере сами по себе, без наследия в виде готовых ОС, библиотек, и компиляторов.

Самая серьезная проблема ближайшего будущего — это как задействовать тысячу ядер из процессора за 15 тысяч рублей в компьютере, который мамка купила «для учёбы». Сейчас единственный массово используемый для этого подход — это SIMD, как на CPU, так и на GPU. А вот потому что тупо нет языков программирования, которые позволяли бы управлять тысячей независимых потоков. И не нужно мне рассказывать, что сделать этого нельзя, потому что обработка инструкций дорогая — ARM2 с 27'000 транзисторов обладал полноценными 32-битными инструкциями, хоть и не умел в один цикл выполнять умножение (использовалось итеративное умножение через сложение по алгоритму Бута). Даже если ядро будет 100 тысяч транзисторов — на чип с 2 млрд транзисторов влезет 20 тысяч таких ядер. И что с ними потом делать? Какой-то браузер умеет работать хотя бы в тысячу потоков? СУБД? В нынешней индустрии 100 потоков — это огогого, целые статьи пишут на эту тему.

А сотня — это, на самом деле, только разминка. Современные массово использумые подходы к разработке на тысяче потоках становятся просто неприменимыми, сколько их не адаптируй. Даже специально разработанные под это дело Erlang и Go вряд ли вывезут тысячи потоков — им, прежде всего, не даст воспользоваться ядрами ОС, которые нынче упираются в потолок как раз на сотнях ядер — тупо алгоритмы работы со структурами ядра начинают люто буксовать. И это современные ядра — старый линь тупил уже на десятках ядер.

Что дает раст в этой нише? Доступ к разделяемой ячейке по мутексам? Как там в 90-х годах живется-то? Хорошо жить в мире со знанием, что рубль не проходил дефолт, с Ельциным на посту президента, и мутексом в роли эффективного способа организации многопоточного кода?

Разве что из-за того, что окамль вообще нигде не используют

Нет, просто Скала это жаба, а жаба это свой закрытый мирок.

Нет, просто Скала это жаба, а жаба это свой закрытый мирок

Внезапно, самый популярный диалект ML, F#, писан под клон JVM. Вообще, Go показал, что GC прекрасно чувствует себя в нативе, а грааль показал, что жаву можно компилировать AoT, и вообще не обязательно именно жаву, так что всё это деление на «жава или не жава» — бессмысленное наследие почившего Sun, от которого пора избавляться. По состоянию на 2010 год ты был бы прав, но сейчас скала уже выполняется на node.js, и даже компилируется в натив с недавних пор.

F#, писан под клон JVM

А для ocaml не написан. Поэтому F# как-то может играть на одном поле со Scala, а ocaml нет.

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

сейчас скала уже выполняется на node.js, и даже компилируется в натив с недавних пор

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

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

Прости, не читал твою простыню, но Rust я использую не из-за функциональщины. ФП в русте убогое как хз что. Я использую Rust, потому что в нём тупо сложнее отстрелить себе ногу, есть нормальный пакетный менеджер (читай, нет геморроя со сборкой) и нет всратого наследия из 70х прямо в языке, которое в 2021 только добавляло страданий в C/C++.

Не надо путать rust и swift.

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

Так он и не для JVM нужен. Это чисто .NET решение. Но по востребованности сравнимо со скалой.

есть нормальный пакетный менеджер (читай, нет геморроя со сборкой)

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

нет всратого наследия из 70х прямо в языке, которое в 2021 только добавляло страданий в C/C++

Какого из? Всратые операции с указателями и волшебное UB есть и в расте, от этого он никуда не делся.

Вообще, Go показал, что GC прекрасно чувствует себя в нативе,

Это показали десятки языков до Go.

Не надо путать rust и swift

Swift поможет мне гарантировано получить работу в гугле и амазоне? Интересные истории.

Как попрут пакеты сорцов в дистрах, так начнется вой «чо это у меня стоит в dpkg либа такой-то версии, а тупорылый cargo мне подхватывает совсем другую?

Не начнется, версионность в cargo из коробки сразу есть.

Вообще, Go показал, что GC прекрасно чувствует себя в нативе,

Это показали десятки языков до Go

Массовый школьник твердо убежден, что GC — это JS, JVM, и CLR. Всё, больши GC не бывает.

Не начнется, версионность в cargo из коробки сразу есть

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

Swift поможет мне гарантировано получить работу в гугле и амазоне? Интересные истории.

Раст точно (особенно гарантировано) не поможет. Без Swift (или его предка ObjectiveC) нереально писать прикладной код под яблочную инфраструктуру, это и есть настоящий корпоративный язык программирования.

Сейчас идет тотальная централизация и SaaS, от «яблочной инфраструктуры» требуется только тонкая морда. В крайнем случае можно нанять индуса за рис. Я что-то не слышал, чтобы в гугле прямо-таки интенсивно писали под маки. В MS — да, есть довольно солидное число яблочников.

Я рад что ты в своей луддитской борьбе с Растом, которую ты совершаешь в поте лица каждый день на этом форуме, ты зажат в угол уже настолько что тебе нужно натягивать сову на глобус утверждая что завтра все компьютеры будут заниматься исключительно вычислениями GPGPU в 10000 потоков и каждый новый ЯП нужно делать по модели CUDA иначе на помойку.

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

Пакетный менеджер для крестов выше упоминали

Ага. Я его и упоминал. Только большая часть программистов ими до сих пор не пользуются, что довольно печально. А в древние проекты запиливать пакетный менеджер – это крайне извращенный вид удовольствия. Особенно, когда все исходники и зависимости и зависимости зависимостей лежат в одном большом мегарепозитарии в SVN. Причём в нескольких копиях. И всё это компилируется только на какой-нибудь специальной древней версии Red Hat со специальными костылями и только в полнолуние. Кажется, я только что описал очень здоровую часть проектов на C++.

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

Что? Я нифига не понимаю, что тут написано. Какие пакеты сорцов в каких дистрах?

Какого из? Всратые операции с указателями и волшебное UB есть и в расте, от этого он никуда не делся.

https://doc.rust-lang.org/reference/behavior-considered-undefined.html

Вообще, делся и очень далеко. Весь список по ссылке выше требует unsafe, что очень сильно облегчает дебаг и усложняет случайный отстрел ног. Для непонятливых, вот простая аллегория: гораздо проще убирать за котом, когда он срёт в лоток, чем когда он равномерно размазывает говно по всему дому. С unsafe примерно так же.

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

Массовый школьник твердо убежден, что GC — это JS, JVM, и CLR. Всё, больши GC не бывает.

Чувак, GC ещё в мать его Алголе был. За 40 лет до голанга. И это даже не относительная эзотерика типа ML, Haskell и прочих лиспов. Все из которых по дефолту компилируются в нативный код.

ты зажат в угол уже настолько что тебе нужно натягивать сову на глобус утверждая что завтра все компьютеры будут заниматься исключительно вычислениями GPGPU в 10000 потоков и каждый новый ЯП нужно делать по модели CUDA иначе на помойку

Ты знаешь смысл слова «луддит»? Это человек, который противостоит внедрению машин. Но я выступаю за внедрение машин, а ты предлагаешь дальше считать на калькуляторах — и кто из нас двоих луддит? Школьный компьютер на 16 потоков — это норма на 2021 год, на 8 потоков только мобильные процессоры делают. И на чем ты собрался эти ядра задействовать?

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

Понять-то поймут, только кому я потом скажу «а я же говорил»? Двум анонимам под псевдонимами? Когда ты приходишь к системщине, к IPC, разделяемой памяти, вводу-выводу, lock-free многозадачности, то выясняется, что там «безопасности» у раста не больше, чем у Си. Логику — да. проще и безопаснее писать, но низкоуровневая логика — это бессмысленая и беспощадная вещь, как правило у тебя либо низкий уровень, либо логика.

Я нифига не понимаю, что тут написано. Какие пакеты сорцов в каких дистрах?

Ну заголовочки *-dev же ж, плюс еще мусор, который я сам рукам поставил в /usr/local.

Весь список по ссылке выше требует unsafe, что очень сильно облегчает дебаг и усложняет случайный отстрел ног. Для непонятливых, вот простая аллегория: гораздо проще убирать за котом, когда он срёт в лоток, чем когда он равномерно размазывает говно по всему дому. С unsafe примерно так же

Согласен. Правда, с C++ то же правило работает — можно точно так же требовать от программистов писать unsafe возле любого небезопасного кода.

Так-то можно сказать, что в любом языке есть UB, потому что в любом языке ты можешь работать с указателями и сделать разыменование NULL, либо вызвать сишную функцию, которая это сделает за тебя

В расте без интенсивного использования unsafe функций ты не сделаешь практически ничего. Даже в консоль hello world не выведешь.

Но я выступаю за внедрение машин, а ты предлагаешь дальше считать на калькуляторах — и кто из нас двоих луддит? Школьный компьютер на 16 потоков — это норма на 2021 год, на 8 потоков только мобильные процессоры делают. И на чем ты собрался эти ядра задействовать?

Нет, тебе срать на ядра. Твоя задача 24 на 7 аттаковать Раст. Я даже не знаю почему. Ты придумал процессоры на 10000 потоков, которые почему-то вдруг вышли из узкой ниши GPGPU и стали CPU (CENTRAL processing unit), придумал что они вдруг прямо сейчас стали реальностью. И все это использовал для своей главное задачи - ежедневного обсирания Раста вместо любых других занятий в жизни.

Школьный компьютер на 16 потоков — это норма на 2021 год

На том же на чем и 2 потока, принципиальной разницы нету.

Когда ты приходишь к системщине, к IPC, разделяемой памяти, вводу-выводу, lock-free многозадачности, то выясняется, что там «безопасности» у раста не больше, чем у Си.

Все бред, обсуждали 100 раз, нету смысла обсуждать на серезных щах. Все примитивы в Расте есть, или инструменты для их безопасного оборачивания в библиотеке в отличии от С. Есть смысл только чморить тебя

Ты придумал процессоры на 10000 потоков, которые почему-то вдруг вышли из узкой ниши GPGPU и стали CPU (CENTRAL processing unit), придумал что они вдруг прямо сейчас стали реальностью

x86 не может масштабироваться на сотни ядер. В принципе вообще никак, поскольку процессор будет только одним кэшем жонглировать по межсоединению 99% времени. ARM-ы на сотни ядер — это вполне реальность:

https://developer.arm.com/tools-and-software/development-boards/neoverse-refe...

Только кто у нас нынче крутит сервера на ARM? Да почти никто. Поставить на поток процессоры на 10 тысяч потоков — это дело одного-двух лет. Но это никому не нужно, потому что индустрия еще 20 лет будет писать сервисы на x86.

Школьный компьютер на 16 потоков — это норма на 2021 год, на 8 потоков только мобильные процессоры делают. И на чем ты собрался эти ядра задействовать?

На том же на чем и 2 потока, принципиальной разницы нету

И что же у нас в 2021 году работает на 16 потоках так же хорошо, как на двух? В хроме у нас 3 потока, которые в самую ясную погоду могут полностью нагрузить два ядра. Компиляция C++? Ну да, оно где-то до 50 потоков масштабируется — но таких задач очень мало. СУБД не масштабируются, весь GUI не масштабируется.

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

Предлагаешь использовать Rust в роли высокопроизводительного аналога питона? Я бы все-таки предпочел Swift.

Ты придумал одну проблему, которой пока нету, и отпугиваешь на форуме новичков от Раста, которые с 99% с такими задачами и железом не столкнутся следующие 10 лет точно. Но не понимая какие выдумки ты про сферический АРМ в вакууме ты пишешь могут принять это за чистую монету от дяди-эксперта

Пойди в Гитхаб Раста, опиши проблему, там тебя не пошлют нахрен, как я здесь, а серьезно выслушаю и сформируют аргументированый ответ. Что, страшно его услышать?

Ну заголовочки *-dev же ж, плюс еще мусор, который я сам рукам поставил в /usr/local.

Ах… ну кто ж виноват, что у тебя мусор в /usr/local и LD_LIBRARY_PATH. Используй Nix и повторяемую сборку. Или собирай в докере проект.

Согласен. Правда, с C++ то же правило работает — можно точно так же требовать от программистов писать unsafe возле любого небезопасного кода.

А если программист не напишет unsafe, а там какая-нибудь лажа со strict aliasing вылезет? Ну ты понял.

В расте без интенсивного использования unsafe функций ты не сделаешь практически ничего.

Хотя нет, ты нифига не понял.

x86 не может масштабироваться на сотни ядер.

https://www.techradar.com/news/amd-zen-4-epyc-cpu-could-be-an-epic-128-core-256-thread-monster

А на двух сокетах 128 ядер ты можешь иметь уже сейчас. Или 256 ядер на четырёх сокетах. Системы с сотнями ядер на x86 – уже давно не новость ни для кого.

Только кто у нас нынче крутит сервера на ARM? Да почти никто.

У меня вот весь тред есть ощущение, что ты в параллельной реальности живёшь. Netflix недавно выкладывал результаты внедрения серверов на ARM у них. На AWS ты можешь уже сейчас ARM арендовать. Только ты про это всё не в теме.

Ты придумал одну проблему, которой пока нету, и отпугиваешь на форуме новичков от Раста, которые с 99% с такими задачами и железом не столкнутся следующие 10 лет точно

А ты про микросервисы и брокеры сообщений не слышал, получается? И кто из нас после этого луддит? Высокая производительность кода в браузере нужна ТОЛЬКО по одной причине — этот код одно-двухпоточен. Он не параллелится, и потому единственная возможность наращивать производительность — выполнять один поток быстрее. Это не «задачи, с которыми не столкнутся следующие 10 лет» — это скорее «задачи, которые почти заморозили развитие софтостроения последних 10 лет». По сути это «развитие» свелось к миниатюаризации десктопа до смартфона. Всё, софт там тот же самый, софт не развивается.

Правда, в каком-то смысле «новички», действительно, с такими задачами не столкнутся — они будут ковырять опердени на PHP и парсинг HTML питоном на нейросетках. Правда, раст им точно так же не нужен. Раст нужен для одно-двух-трехпоточных браузеров. Примитивная десктопная гуевина прекрасно работает и в одном потоке.

Пойди в Гитхаб Раста, опиши проблему, там тебя не пошлют нахрен, как я здесь, а серьезно выслушаю и сформируют аргументированый ответ. Что, страшно его услышать?

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

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

Ах… ну кто ж виноват, что у тебя мусор в /usr/local и LD_LIBRARY_PATH. Используй Nix и повторяемую сборку. Или собирай в докере проект

И ты повторяешь ту же проблему, только в профиль: сотни окружений с дублями библиотек.

А если программист не напишет unsafe, а там какая-нибудь лажа со strict aliasing вылезет? Ну ты понял

Давно понял, потому свой код компилирую только с "-fno-strict-aliasing". Это одна из самых бессмысленных и беспощадных фич GCC.

В расте без интенсивного использования unsafe функций ты не сделаешь практически ничего.

Хотя нет, ты нифига не понял

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