Доказана эффективность Rust

Pascal преподают в его кастрированном варианте. Современный Free Pascal ничем не уступает той же Java, а в чем-то сильно вырывается вперед.

В сортах не разбираюсь.

Нет, не сильно. А знаешь почему? Потому что его только при обучении и используют. А на C/C++, помимо hello-world-ов ещё и куча актуального кода есть.

Но через голый unsafe работать можно без проблем.

Вы только что умножили весь Rust на ноль. Ибо если вы в Rust-е обмазаны unsafe и тупыми обертками вокруг сишных либ, которые не формируют безопасный интерфейс, то дешевле брать C++. Тем более, что при этом кроме С-шных либ и древних плюсовых библиотек, написанных в стиле «Си с классами», вы сможете применять и современные C++ные библиотеки с шаблонами на каждом шагу.

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

Смысла тогда от C++. Можно сразу на C лабать, лол. Всё равно все либы на C.

Можно сразу на C лабать, лол.

Сразу видно специалиста, который на Сишечке ничего не лабал.

Вам что-либо кроме Rust-а противопоказано.

Sigh… Можно - не то же самое, что нужно, и уж тем более не то же самое, что удобно или рационально. К тому же у C++ беда с композицией его же частей, даже в рамках одной версии языка и стандартной библиотеки. Даже не надо далеко ходить за примером:

use rayon::prelude::*;

fn main() {
    let numbers = [1, 2, 3, 4, 5, 6];
    let result_a = numbers.iter().map(|x| x * 2).fold(0, |acc, x| acc + x);
    let result_b = numbers.par_iter().map(|x| x * 2).reduce(|| 0, |acc, x| acc + x);
    assert_eq!(result_a, result_b);
}

Как бы вы сделали то же самое с std::transform/reduce/accumulate без создания лишних векторов? С TBB? А если контейнер нестандартный? Понятно что можно слепить монстра Франкенштейна, но чего ради?

Вот только Rust то не преподают

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

это буквально выстрел себе в ногу и удивление от того, что ногу прострелил. Явно написал unsafe, явно преобразовал к указателям, явно затерел лайфтаймы. Явно удивляется, почему лайфтаймы затерлись. Пусть попробует то же самое со ссылками (спойлер: не сработает). Такая семантика.

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

Следи за руками. Что такое unsafe? Это разрешение на преобразование маня-безопасный форм и небезопасные. Что мы хотим, когда просим unsafe? Мы хотим получить те самые небезопасные формы, потому как если они ненужны - зачем нам unsafe?

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

Доказательство показывает ровно то, что сферический safe Rust в вакууме типобезопасен

Нет, это чушь.

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

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

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

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

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

Толку нам с этого? А толку никакого нет. На самом деле смысла верифицировать там ничего нет. Верификация нужна для чего-то сложного.

А там же все выкладки уровня «аксиома - алиасы невозможны. Аксиома вторая - для осуществления гонок нужен конкурентный доступ к одному объекту. Гонки в расте невозможны в связи с тем, что конкурентного доступа нет, ведь он невозможен».

Но т.к. ЦА там настолько слаба, что они ничего не знает - ей впарить можно какую угодно херню. Что мы и наблюдаем.

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

затрагивают C/C++

А разве не указатели затрагивают, используя C/C++ как наиболее распространенные в данное время системные языки?

А противоречие то в чём? Если C/C++ затрагивают ради указателей, то всё равно же затрагивают. Хотя, если на то пошло, то для этого используют и Паскаль.

Ни в чём. При преподавании важны не сами C/C++ по себе, а концепции, которые с их помощью иллюстрируют.

Да, важны. А претензия то в чём?

А претензия то в чём?

В том, что «в отличии от раста» никакой смысловой нагрузки в контексте преподавания не несёт. Где-то используют C/C++, где-то паскаль, где-то раст.

Лол, дельфи еще за это ругали.

Очень качественный наброс, кстати. Рекомендую.

У мсьё странноватый вкус.

У мсьё странноватый вкус.

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

+1 С Растом по большому счёту не знаком, чисто по ощущениям.

Кидать лопатой уголёк доводилось? А мне доводилось. Не скажу, что испытывал особый кайф, но и отвращения тоже не было. Работа как работа. Но после уголька эти ваши расты уже не кажутся каторгой. Да, я в курсе, что большая часть жителей ЛОР’а причисляет себя к илитке и считает что картофан растёт в гиперах.

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

Покидаешь уголёк, полюбишь и его =)

1к комментов, а читать скучно. Лора на них нет.

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

Для меня она познавательна оказалась.

А тобой легко манипулировать. Податливая масса :( Как раз для современного общества.

При чем тут pvs? Что за унылый форс, или это всё что вы слышали о статичной верификации.

Спасибо за вопрос! Некоторое отношение к этой статье PVS-таки имеет.

Податливая масса :( Как раз для современного общества.

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

Вот, хорошо же, что обитающий на ЛОРе вид млекопитающих Anonymous Naturalis манипуляциям не поддается! Интересно, хотя бы Хомского этот вид в своей массе читал? Не говоря уже про Эллюля.

Ничего никому не докажешь, а жизнь свою спустишь в унитаз и здоровье посадишь.

Разверни мысль.

Покажите современные, удобные либы на C++ >= 14 для: разбора cmd, работы с процессами, XML, CSS, SVG, gzip, TrueType. Хотя бы по одной

так вроде c++, как и раст, себя системными языками позиционируют, а не вот это вот все...

Системщина - это не только драйвера. Следующий после ОС слой написан на C/C++.

Так не всегда очевидно, что должен быть именно Vec. Например, при использовании collect

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

На С++ можно написать что угодно. Вот только КАК это написать и КАК оно (код) будет выглядеть это уже совершенно другой вопрос (ужасно).

По этому люди и пишут на всяких там жабках и питонах.

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

Да, и там, где автоматические проверки есть — там большинства проблем нет. Ты ничего адекватного не сможешь сделать с use-after-free, поскольку альтернативной является утечка памяти или относительно тяжелые алгоритмы проверки ссылок для объектов динамического типа, которые в расте тоже пойдут как боксы и unsafe. Ну то есть чтобы бежать, нужно периодически отрывать все ноги от земли, оставаясь полностью без опоры. Чисто алгоритмические же баги раст и вовсе не позволяет избегать.

Смотрю со стороны разработки отзывчивого GUI приложения. Что-то за 5 лет стабильного Rust-а ничего толкового растоманы создать не смогли. В XXI-ом то веке, хотя в начале 1990-х GUI-вые библиотеки росли как грибы после дождя. Часть из них до сих пор живы

Да, GUI оперирует большим кол-вом сложносвязанных объектов разных типов, для которых большинство инструментов обеспечения безопасности кода раста не работает. Например, какая-то банальная кнопка в окне, область видимости которой располагается от момента создания родительского окна и до обеденного перерыва. В итоге раст тупо биндят к GTK/Qt.

Ну за 20-30 лет требования к GUI сильно выросли. Сейчас это почти неподъемная задача. Даже MS всё никак не может осилить новый UI

Единственное требование к GUI, которое я в 2020 вижу — это способность работать на всех платформах и всех разрешениях экрана. Не такая уж это и неподъемная задача. Вот создать кучу готовых решений и убедить сообщество клепать еще больше онных — это реальная проблема.

Надо также в сишку засунуть ccc-analyzer, назвать это новым языком, а потом бегать и говорить всем про то, какой язык безопасный и в нем нельзя выстрелить себе в ногу

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

Обычно крейты, которые делают реально что-то полезное, написаны с unsafe во все поля

Вот.

Это был просто пример. Многие вынуждены писать на C++ только из-за Qt

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

Для этого нужно:

1. Быстрая 2D либа, способная работать на CPU и GPU. Сейчас существует только skia. И она ни разу не тривиальная, если мы говорим о реализации всего стека с нуля.
2. Либа для отрисовки текста. Титаническая задача, до сих пор фактически не решённая. fontconfig + freetype + harfbuzz + text layout, если мы про линь.
3. Конкретно GUI либа, с виджетами, слоями, анимациями, тотальной ассинхроностью и тд. Ближе всего QML, Flutter, SwiftUI.
4. Accessibility.

Да, делать нечего.

1. Живой биндинг ровно один - для питона.
2. Язык не влияет на отзывчивость GUI, ибо всё делается в доп. потоках/процессах.

всё, у вас исчезает 90% сложных багов без повышения трудоемкости написания кода.

Самый умный, да? ЯП нет нормальных только и только ввиду ущербности x86 архитектуры. Никогда ничего быстрее (а значит и лучше) сишки не появится под x86. Меняйте архитектуру, бояре, и будет вам щастье

Вообще не понимаю, какое отношение твое сообщение имеет к моей цитате. Сейчас самая популярная архитектура в мире - это ARM, а никак не x86.

В том же питоне/js есть либа на каждый чих

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

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

Сишное ООП будет помощнее, чем крестовое, как ни странно. Например, «struct» можно считать объектом со множественным наследованием, который наследуется от каждого своего поля. Большие возможности несут с собой больше ответственности и опасности. Тупо дернуть сишные функции на крестах не представляется проблемой. Ты же пишешь о том, чтобы обернуть родные сишные приемы в родные крестовые приемы, что, действительно, весьма проблематично из-за ограниченности крестов.

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

Я даже не знаю, с какой стороны этот бред комментировать. Например, для начала расскажи, как сделать O(1) добавление символа в конце нуль-терминированной строки — именно с такой масштабируемостью работают крестовы и паскалевы строки.

Pascal преподают в его кастрированном варианте. Современный Free Pascal ничем не уступает той же Java, а в чем-то сильно вырывается вперед

В сортах не разбираюсь

Современный Free Pascal по сути является аналогом C++, перенявшим большинство чисто крестовых фич, но при этом не отягощен сишным прошлым, благодяр чему имеет хорошую поддержку целых чисел, родных строк и динамических массивов, передачи значений по ссылками и автоматической оптимизации без strict aliasing/volatile-маразма.

Как бы вы сделали то же самое с std::transform/reduce/accumulate без создания лишних векторов? С TBB? А если контейнер нестандартный? Понятно что можно слепить монстра Франкенштейна, но чего ради?

Самое смешное то, что даже на Си это пишется проще, чем на крестах.

Быстрая 2D либа, способная работать на CPU и GPU. Сейчас существует только skia. И она ни разу не тривиальная, если мы говорим о реализации всего стека с нуля

Вы там совсем охренели? Я в 2010 году на голом 400 МГц ARM процессоре в 3D шутаны катал, а им в 2020, видите ли, подавай аппаратное 2D для гуя. Не жирно ли будет? В то же время, я почему-то не вижу у создателей игр проблем с написанием графических интерфейсов для своих игр.

Либа для отрисовки текста. Титаническая задача, до сих пор фактически не решённая. fontconfig + freetype + harfbuzz + text layout, если мы про линь

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

Конкретно GUI либа, с виджетами, слоями, анимациями, тотальной ассинхроностью и тд. Ближе всего QML, Flutter, SwiftUI

Вот об этом я и писал. Это не так уж и много работы, если убрать необходимость жирных прослоек к другим ЯП и оставить только родные интерфейсы.

Accessibility

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

Живой биндинг ровно один - для питона

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

Язык не влияет на отзывчивость GUI, ибо всё делается в доп. потоках/процессах

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

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

Плохо смотрите. В новом ремастере Warcraft UI вообще на electron: https://twitter.com/colincornaby/status/1223073101312753664

Но в целом, интерфейс в играх обычно треш и к реальному GUI отношения не имеет.

Это не так уж и много работы

Ну так помогите Qt. Они уже лет 10 QML родить не могут. За одно flutter поможете гуглу допилить, а то тоже лет 5 возятся, дурачьё.

Ничего в потоке интерфейса делать не нужно. Вы застряли в 90-х.

Самое смешное то, что даже на Си это пишется проще, чем на крестах.

Небольшая разница с растом.

let numbers = [1, 2, 3, 4, 5, 6];
let result_a = numbers.iter().map(|x| x * 2).fold(0, |acc, x| acc + x);
println!("{}", result_a);

vector numbers = {1, 2, 3, 4, 5, 6};
auto result_a = ranges::accumulate(numbers | ranges::views::transform([](auto x){return x*2;}), 0);
cout << result_a << '\n';

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

Хотелось бы увидеть как это будет выглядить на си.