Опрос: Три-пять лучших фич C++

нет причин не иметь такие линтеры для крестов — возможно, они есть

Конечно, есть. Например, clang-tidy

Он разве умеет вырезать из языка оптимальное подмножество?

Причем, без усложнения языка

Что ты под этим подразумеваешь? Мне кажется, что их необязательность, иначе чем принципиально отличается «борьба с бороу-чекером» и «борьба с линтером»?

Тем, что «без усложнения языка». Я кратко описываю какую-то хрень, а линтер за меня пытается разобраться в корректности. В остальном — да, то же самое.

Я тебе не верю. Ты вон бороу-чекер неподъёмным бременем считаешь. Если ещё всюду явно аллокатор протаскивать (и так же явно ошибки выделения памяти обрабатывать), то от бизнес-логики вообще мало что останется

Напоминаю, что я предлагал разделить традиционные крестовые объекты на два разных фундаментальных типа: примитивные, безо всяких аллокаторов, и выделяющие ресурсы и высвобождающие их через RAII. И здесь подразумевается, что выделяемые-высвобождаемые объекты не будут копироваться без необходимости, а потом проблема с явным placement copy будет не так уж актуальна. Часто повторяющийся сценарий выделения объекта с RAII можно инкапсулировать в функцию-конструктор — я же не имел в виду, что прямо-таки всё руками на каждый чих прописывать.

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

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

Pascal, Go

Ты сам признавался, что второй толком не щупал. И про дженерики в Go уже почитал?

А я тут при чем? Вопрос был не про «на чем бы ты написал», а «покажи пример». Я показал.

Ну и лично мне этот язык, особенно без дженериков, кажется как раз излишне примитивным

Замечательно, но это не отменяется того факта, что Go — хороший простой язык.

Он ведь слегка жив, почему на нём не пишешь?

Больше трех лет уже на нем не пишу, потому что не нужен он никому. Сеньору-помидору с кучей опыта платят как питоновому мидлу — зачем мне такая радость?

Я писал о том, что в топе в основном динамика.

Я согласен с этим утверждением только если учитывать количество кода. Ну или мы о топ-2 говорим. Иначе что-то не сходится

Речь была про опрос на stackoverflow, там в топ 10 в полтора-два раза больше динамики, если по процентам.

Да, можно, но ЗАЧЕМ?

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

Дальше уже нечитаемую лапшу они организуют без дополнительной помощи.

Ты просто неправильно акценты расставляешь. Речь не о том чтобы вчерашнего студента посадить писать хоть какой-нибудь код, который никто даже смотреть не будет. На любом проекте, где больше двух человек, у людей будет разный уровень. И если ты делаешь что-то важное и хочешь подстраховаться, то попросишь посмотреть именно того чувака, который хорошо соображает (и/или педантично к ревью относится), а не того, кто апрувы не глядя раздаёт. Аналогично с тестами: гнаться за 100% бестолкового покрытия мало смысла, но есть места корректность работы которых важнее. Ансейф - это просто явный маркер. Да, это не единственный критерий (код с супер-важной бизнес-логикой может быть без unsafe), но зато он хорошо формализуется.

Он разве умеет вырезать из языка оптимальное подмножество?

Именно твоим хотелкам он явно не соответствует, а вообще там есть линты из категорий readability, modernize и cppcoreguidelines , что примерно в эту степь.

Тем, что «без усложнения языка». Я кратко описываю какую-то хрень, а линтер за меня пытается разобраться в корректности. В остальном — да, то же самое.

Кажется, ты хочешь магии, а так (всегда) не получится. Если ты «описываешь какую-то хрень», то вариантов два: или говоришь линтеру «я знаю, что тут делаю» (unsafe) или даёшь линтеру больше информации (усложняешь язык).

примитивные, безо всяких аллокаторов

А если я захочу примитивные аллоцировать нестандартно?

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

И зачем же тогда флаг -fwrapv завезли?..

А я тут при чем? Вопрос был не про «на чем бы ты написал», а «покажи пример». Я показал.

При том, что ты показал фигню. Обещал «простой, но не примитивный», а показал Go.

Причём ещё и сам признаешься, что не знаешь язык, то есть и не знаешь хорош он или нет.

Больше трех лет уже на нем не пишу, потому что не нужен он никому. Сеньору-помидору с кучей опыта платят как питоновому мидлу — зачем мне такая радость?

Опять менеджеры тебе поднасрали.

Речь была про опрос на stackoverflow, там в топ 10 в полтора-два раза больше динамики, если по процентам.

Cмотря как считать.. JS плюс питон - 113%, джава, тайп скрипт, шарп и плюсы - 117%. Опять же, я уверен, что питон многие указывали как вспомогательный язык.

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

Мы приходим к настоящей проблеме — проблеме общения языков программирования. А вот по моему впечатлению писание сложной логики на низкоуровневом языке с последующим улётом сроков реализации в космос — это очень распространенная ошибка нубов. Которую сделал в том числе я. Даже в FF часть реализации вынесена в JS.

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

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

Если ты «описываешь какую-то хрень», то вариантов два: или говоришь линтеру «я знаю, что тут делаю» (unsafe) или даёшь линтеру больше информации (усложняешь язык)

...или жертвуешь производительностью.

А если я захочу примитивные аллоцировать нестандартно?

Аолцируй. Им все равно, как аллоцироваться и где находиться — в этом и смысл. В это и смысл: если структуре нужен RAII, то описавай ей RAII.

И зачем же тогда флаг -fwrapv завезли?

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

При том, что ты показал фигню. Обещал «простой, но не примитивный», а показал Go.
Причём ещё и сам признаешься, что не знаешь язык, то есть и не знаешь хорош он или нет

Я на нем почти не писал, но читал доки, сорцы, писал хелло ворлды. Этого впечатления хватило, чтобы сказать, что у ЯП богатая история и его наконец сделали не комитеты и не одиночка за летние каникулы.

Опять менеджеры тебе поднасрали

Да, и не в последнюю очередь борландовские, которые установили на рынке фактическую монополию, чтобы впоследствии анально огродить нишу и поставить турникеты — и ниша тупо вымерла.

JS плюс питон - 113%, джава, тайп скрипт, шарп и плюсы - 117%. Опять же, я уверен, что питон многие указывали как вспомогательный язык

Я понял, тут всё как бы сводится к «чем у нас является TS». Я бы советовал его выкинуть из списка, потому что он является промежуточным — код на JS является корректной TS программой.

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

Нет, не исхожу.

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

Разве я предлагал заменять джаву/C# на раст? На С и С++ пишут весьма большие проекты без сборки мусора.

…или жертвуешь производительностью.

Или так, да. И это тоже можно и на расте.

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

Как будто clang по другому пути идёт. Но вообще ты как раз подтверждаешь мои слова: UB существует не «чисто формально».

Этого впечатления хватило, чтобы сказать, что у ЯП богатая история и его наконец сделали не комитеты

Развитие языка происходит под контролем гугла. Контроль корпорации (не забываем про менеджеров!) - это точно лучше, чем разработка комитетом?..

Разве я предлагал заменять джаву/C# на раст? На С и С++ пишут весьма большие проекты без сборки мусора

Если ты про ядро линя или про оракл, то расту там особо нечего ловить. Например, как ты собрался реализовывать работу с RCU на расте? И то же самое относится к любому lock-free, которого в ядре ОЧЕНЬ много. Раст подходит в качестве «языка скриптинга», как для ОС, так и для БД, то есть, дергать отдельные безопасные функции для кастомизации обработки, вроде драйверов или функций БД. За этими границами ты получаешь просто один сплошной unsafe, а если у тебя хотя бы треть кода является unsafe, то safe-unsafe вообще теряет смысл, ведь ты полностью теряешь возможность отслеживать потенциально опасные участки кода через unsafe и непосредственно связанные с ними, потому что в эту категорию попадает почти весь код, а оставшаяся чисто safe часть ничтожна.

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

Вот я недавно снова писал на крестах, вспоминания про нашу беседу, и вывел более общую закономерность: бинарные safe-unsafe, private-public, nonconst/const НЕ РАБОТАЮТ ДЛЯ СЛОЖНЫХ СЛУЧАЕВ. Как только сложность становится чуть больше нуля, выясняется, что есть сложносплетенные объекты, которые имеют const интерфейс без константности всех внутренних объектов, что private поля нужно менять из других модулей, и, самое главное, что критериев «безопасности» кода сильно больше одного, есть понятия «безопасно, если...» и «некорректный указатель, но это пофиг, потому что мы все равно выбрасываем указатель». Да, Rust вводит еще и многопоточную безопасность передачи объектов, но я дам пример RW-блокировок, где этих бинарных маркеров снова недостаточно.

Можно увидеть, что бинарные маркеры придумали МЕНЕДЖЕРЫ, которые в своей жизни ничего больше тысячи строк не писали (и не читали). Логика менеджера: если нужно что-то исправить — давайте сделаем для этого новую фичу. Хорошо формулизируется, хорошо бюрократизируется — идея как бы правильна, вроде работает для примитивных применений, но она совсем не масштабируется (как я уже говорил, но про один только const). Сравни это с логикой грамотного архитектора: «что нужно выкинуть, чтобы система заработала?».

Недавно ковырял либу, где САМ АВТОР наступил на собственные грабли, будучи вынужденым через анус лезть к приватным полям своих собственных классов из другого модуля. Потому что для простой модели private/public прокатывает, но как только сущности начинают сплавляться друг с другом, то выясняется, что нужны либо прокладки (как принято в Rust), либо прямой доступ к полям. А я просто взял этот код и сделал все члены класса публичными и неконстантными. Сразу операторы заработали и стала возможной беспроблемная передача по ссылке. То есть, опять же «private, если...».

И самое смешное то, что небинарные vector<int>, const vector<int>, vector<const int>, const vector<const int> эту функцию тонкого контроля как раз не выполняют, а только мешаются, как третья нога. Как раз недавно пилил контейнеры, обматерил их не один раз, в очередной раз копипастя nonconst-const методы и прилепливая SFINAE касты контейнеров из nonconst в const — почему-то эти проблемы есть у всех, и даже у Мейерса, но не у тебя. Как я уже писал, либо у тебя очень специфичный код, либо ты их просто НЕ ЗАМЕЧАЕШЬ В УПОР.

Короче говоря, ты никогда не хотел private-public, const, unsafe, ты хотел сделать аккуратные интерфейсы для своих функций, но в используемом тобой ЯП есть только вот эти инструменты для организации интерфейсов. Интерфейсы, которые бы хорошо показывали на ревью, когда пользователь кода пользует штатные интерфейсы, а когда — лезет в кишки, обходя безопасные функции.

Но альтернативные походы есть — это, как ни странно, сишные непрозрачные указатели на структуры. Они убоги, да, но я просто хочу показать, что есть подходы к построению интерфейсов, которые выполняют одновременно функции private-public, nonconst-const, safe-unsafe директив, и при этом в них не используются данные директивы. Директив нет, а инкапсуляция есть — как так? Или паскаль, в котором есть ограниченная реализация RAII через частично непрозрачные структуры данных, полный доступ к которым, однако, при желании можно получить, и даже переписать стандартную реализацию.

Ты прав лишь в том, что при прочих равных я предпочел бы дергать либу, где автор уже налюбился с интерфейсами, где деклараций больше, чем логики внутри, где уже написан клей для взаимодействия со всеми возможными смежными типами, вроде каких-нибудь строк, которые в одном только STL могут быть представлены std::string, std::string_view, std::array, std::vector. Но я ни за что в жизни не полез бы по собственной воле пилить самостоятельно такую либу просто для того, чтобы Махеш или Ананда не завалили проект своим безалаберным говнокодом. А потом ты всё переписываешь с нуля, если требуются особые требования к аллокатору — та же STL часто превращается в тыкву из-за запрета на исключения и/или глобальные аллокации. И если ты много пишешь на крестах, то по-идее должен увидеть обе стороны монеты, но ты почему-то видишь только одну.

И еще один риторический вопрос: какого хера в Rust до сих пор нет RTTI?

…или жертвуешь производительностью.

Или так, да. И это тоже можно и на расте

А можно и совсем без раста.

Как будто clang по другому пути идёт. Но вообще ты как раз подтверждаешь мои слова: UB существует не «чисто формально»

Основная функция стандарта формального ANSI C заключается прежде всего в том, чтобы подтирать им жопу. UB в тексте стандарта не является никаким оправданием для того, чтобы творить несусветную дичь, вроде перехода управления на случайную соседнюю функцию, как это недавно сделали в GCC. У Rust вообще нет стандарта — так что теперь, воруй, убивай, разыменовывай указатели?

Контроль корпорации (не забываем про менеджеров!) - это точно лучше, чем разработка комитетом?

Объективно, гугл нынче — наименьшее зло. Еще в MS были последние грамотные сишники, но скорее всего уже поразбегались. Они не перестали быть сишниками — их просто никто не услышит за воплями вахтеров и манагеров. Возьми тот же прецедент со strict aliasing: 100% грамотных задротов-сишников (например, разрабы ядра и glibc) в один голос твердят, что strict aliasing broken by design, что это абсолютное зло и его сущестованию нет никакого оправдания. А теперь посмотри, сколько фанатов strict aliasing тусит на LOR или habr.

Как раз хотел спросить живой ли ты.

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

Посмотрим.

За этими границами ты получаешь просто один сплошной unsafe

Нет.

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

Почему?

И еще один риторический вопрос: какого хера в Rust до сих пор нет RTTI?

Что именно ты под этим подразумеваешь? Есть Any как плюс-минус аналог dynamic_cast, а полноценной рантайм рефлексии очевидно и не будет.

…или жертвуешь производительностью.

Или так, да. И это тоже можно и на расте

А можно и совсем без раста.

Зачем так жить?

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

Но по факту разработчики С++ компиляторов думают иначе и ломают «рабочий код». Приходится флагами подпирать. Странно спорить с объективной реальностью.

У Rust вообще нет стандарта — так что теперь, воруй, убивай, разыменовывай указатели?

Так ведь дело не в стандарте, а подходе. В safe-расте нет UB.

Ну и, кстати, фиг с ним со стандартом, а вот полноценная спецификация нужна. И тут у раста пока дела не очень хорошо.

А теперь посмотри, сколько фанатов strict aliasing тусит на LOR или habr.

И это всё менеджеры из MS?! Кошмар. (:

Как раз хотел спросить живой ли ты

Ну сейчас поспокойнее как-то стало, а то не до лора было.

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

Посмотрим

Что смотреть? У тебя есть файл. В файл пишет пять потоков. Что ты будешь делать со своим растом? Вешать мутексы на всё подряд? Тогда БД будет бегать медленнее SQLite. Это техника достижения производительности, которую я называю «жонглирование»: оставить байты без опоры, чтобы потом позже в нужно время словить их. В расте нет абсолютно никаких инструментов для организации «свободных» объектов, корректность работы с которыми проверяется именно упомянутыми ранее комментариями и сборщиком мусора. То есть, это именно то самое деление safe-unsafe «с подковыкой», которое полностью проходит мимо штатных растовых инструментов, попадая целиком в unsafe.

За этими границами ты получаешь просто один сплошной unsafe

Нет

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

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

Почему?

Хм-м-м, я сейчас прикинул — в принципе, sync::Arc<sync::RwLock<<T>> чисто формально проблему решает, пусть и очень неэффективно (четыре записи для простого однократного чтения ячейки). Опять же, по сравнению с производительностью RCU и прочих около-lock-free алгоритмов этот подход отстает очень сильно, и даже сборщики мусора могут обскакать счетчики ссылок за счет отсутствия необходимости в этом самом подсчете ссылок.

Что именно ты под этим подразумеваешь? Есть Any как плюс-минус аналог dynamic_cast, а полноценной рантайм рефлексии очевидно и не будет

Высокий уровень, сериализация — вот это всё. В C# уже можно на манер JS обращаться к членам объекта как к ассоциативному массиву. Конечно, разница с шарпом очевидна — это наличие сборщика мусора, который может организовывать динамические и полудинамические объекты, и при этом JIT, который прямо в рантайме эти объекты оптимизирует.

А можно и совсем без раста.

Зачем так жить?

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

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

Всё. Тебе нравится язык? Ради бога. Мне он не нравится. Вот и всё, объективных причин выбирать или не выбирать Rust нет, но сообщество делает вид, будто они есть — вот что меня бесит больше всего. Объективные факторы есть для гугла, и то в отдельных проектах, они есть для мозиллы в отдельных модулях браузера, но 95% проектов на рынке не получат вообще никакой пользы от раста, даже учитывая наличие единого репозитория пакетов.

Это примерно как если бы в интернетах Mozilla начала писать «React — говно, все переходите на Vue, который решает проблемы React». Или «epoll — прошлый век с кучей недостатков, давайте все писать на io_uring». И так далее, берешь любые два схожих решения, созданных в разные годы, где у каждого есть преимущества и недостатки, и дальше говоришь «будем использовать последнее, потому что оно мне больше нравится».

Но по факту разработчики С++ компиляторов думают иначе и ломают «рабочий код»

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

Так ведь дело не в стандарте, а подходе. В safe-расте нет UB

Ну так в safe-крестах тоже нет UB. Просто определение safe своё. И поди разберись, какое из них православное, а какое — еретическое.

А теперь посмотри, сколько фанатов strict aliasing тусит на LOR или habr.

И это всё менеджеры из MS?

Напоминаю, что MSVC является одним из тех компиляторов, в которых strict aliasing никогда не было. Более того, MSVC расширил семантику volatile до atomic, являлся создателем расширения стандарта с безопасными альтернативами функций из стандартной либы. В свое время MSVC был топовым игроком на рынке, который мог просто действовать из принципа «у вас стандарт — а у нас фактическая монопольная реализация», и до сих пор остается солидным игроком, но уже не таким значимым.

Ну сейчас поспокойнее как-то стало, а то не до лора было.

А ты в Киеве сейчас?

Что смотреть?

Посмотрим будет ли реальное распространение раста в эти ниши.

В расте нет абсолютно никаких инструментов для организации «свободных» объектов…

А в С есть? На расте можно сделать точно так же. И не надо опять про ансейф.

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

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

сериализация

Вот с сериализацией у раста как раз всё прекрасно.

Высокий уровень

Что значит высокий уровень? Очевидно, что всякой райнтаймовой срани не будет.

В C# уже можно на манер JS обращаться к членам объекта как к ассоциативному массиву.

Как будто что-то хорошее.

А ты в Киеве сейчас?

Слава богу, нет. Чтобы ты понимал размах: https://upload.wikimedia.org/wikipedia/commons/1/13/Вторжение_России_на_Украи...

А в С есть? На расте можно сделать точно так же. И не надо опять про ансейф

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

И с тем, что при «достаточно большом» количестве ансефа теряется смысла и особенно с тем, что ансейф нельзя минимизировать

Ты делаешь такой вывод только на основании того скромного парках растовых либ, которые были написаны до сих пор. Раст очень неохотно проникает в БД и ОС — это может создавать иллюзию «этих проблем никогда не будет», но они будут, ровно когда программы на расте начнут активно работать с железом, данными, и просто распределенными системами.

Вот с сериализацией у раста как раз всё прекрасно

Учту, не знаком со спецификой раста.

Что значит высокий уровень? Очевидно, что всякой райнтаймовой срани не будет

А рантаймовая срань есть даже в ядре линукса. Даже в браузере FF, по крайней мере той части, которую до сих пор не смогли написать на расте.

Я вот живу без раста и не жалуюсь.

Это ты просто ничего слаще редьки не пробовал.

(Если ты не заметил, то в этой ветке обсуждения я всерьёз уже не отвечаю. Просто потому что всё, что мы могли сказать друг другу, уже сказали несколько раз. Очевидно, друг друга переубедить мы уже не сможем.)

«Разработчики компиляторов» — это всего-лишь GCC.

Clang идет за GCC только потому…

Да какая разница, если альтернатив особо нет?

Ну так в safe-крестах тоже нет UB. Просто определение safe своё.

Ага - «сейф С++ - это там, где нет UB». Прекрасное определение. Жалко только, что оно никак писать не помогает.

Я вот живу без раста и не жалуюсь.

Это ты просто ничего слаще редьки не пробовал

С, С++, Delphi, Haskell, Clojure, Basic, Python, JS — примерно такой список на сегодняшний день.

Да какая разница, если альтернатив особо нет?

А под виндой альтернатив особо нет — ты можешь генерировать бинари только через MSVC, как минимум используя линкер онного. Что, на мой взгляд, довольно странно, если учесть, что тот же Delphi/Builder умеет генерить виндовые бинари сам.

Ага - «сейф С++ - это там, где нет UB». Прекрасное определение. Жалко только, что оно никак писать не помогает

Условно безопасный C++ — это некое подмножество, которые выделено из общего числа фич языка и либ. На самом деле, конечно же, он настолько же небезопасен, как safe Rust, только соблюдать это подмножество намного сложнее в силу исторических причин и убогости готовых решений.

Слава богу, нет. Чтобы ты понимал размах: https://upload.wikimedia.org/wikipedia/commons/1/13/Вторжение_России_на_Украи…

Размах я прекрасно понимаю. Просто мне казалось, что ты в Украине живёшь. Самому мне повезло в этот момент оказаться не в стране, но там родственники, друзья и коллеги.

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

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

Раст очень неохотно проникает в БД и ОС

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

Ну и есть штуки вроде bottlerocket. А в контексте БД знаю о вот этих чуваках которые что-то вокруг постгреса пилят и от бывшего коллеги, который там работает, слышал, что планы у них весьма амбициозные. Ещё вот сюда можешь посмотреть. Не сомневаюсь, что ты найдёшь кучу причин почему это ни о чём не говорит. (:

А рантаймовая срань есть даже в ядре линукса.

Давай всё-таки уточним, что ты под этим подразумеваешь, только без общих слов про «джит оптимизации» и «обращения к объектам как к ассоциативному массиву». Тыкни пальцем на около-системный язык (включая даже совсем новые вроде Nim или Zig) и покажи чего расту не хватает именно в плане RTTI. А то мне кажется, что ты опять хочешь странного сначала рассказывая, что плюсовый механизм RAII и аллокаторов недостаточно гибкий и низкоуровневый, а потом киваешь на C#.

С, С++, Delphi, Haskell, Clojure, Basic, Python, JS — примерно такой список на сегодняшний день.

Ты видимо полностью комментарий не прочитал.

И что хаскель как следует распробовал или осилил монады и убежал в ужасе? Кстати, я вот как раз делаю очередной подход к хаскелю и понимаю насколько там инструментарий отстаёт. Да репл клёвый и hoogle штука удобная, но дальше всё так себе. Language server хоть и есть, но там даже «go to definition» в библиотечный код не (всегда?) работает. Из коробки форматтера кода нет, зато их целая пачка разных. Без плясок с бубном ни один не заработал. В недавней теме monk ещё больше граблей в инфраструктуре описывал. Всё-таки, как для нового языка, раст прекрасно стартовал.

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

О том и речь.

ты часто преподносишь это под слегка другим соусом - не просто «нет значительных преимуществ в некоторых конкретных вопросах», а «ничего не даёт вообще»

Давай сойдемся на «разница между крестами и растом по большей части субъективна». Есть новый язык и ты хочешь им пользоваться? Поздравляю.

Это тоже странное высказывание. Бросаться переписывать давно существующие большие и отлаженные проекты объективно мало смысла

Хорошо, для ОС это еще более менее актуально, потому что ОС новых не пишут и пользуются старыми только ради драйверов. А БД где?

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

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

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

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

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

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

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

О том и речь

не намекаешь ли ты на то, что можно было бы пересоздать C++ с пакетным менеджером, и он будет сравним с растом?

Давай сойдемся на «разница между крестами и растом по большей части субъективна».

Звучит примерно как «разница между С++ и хаскелем по большей части субъективна». Да, в этом случае разница сильно больше, но всё равно можно применить твой аргумент: монады и ленивость в С++ можно изобразить.

Хорошо, для ОС это еще более менее актуально, потому что ОС новых не пишут и пользуются старыми только ради драйверов. А БД где?

И много ты знаешь прям совсем-совсем новых БД? И почему тут не применим аргумент про ОС? Вот есть большой и стабильный постгрес. Переписывать его просто чтобы было?

Не сомневаюсь, что ты найдёшь кучу причин почему это ни о чём не говорит

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

О чём я и говорил. А между прочим, по ссылке не только hello world-ы (например, sled).

eBPF.

Ну есть вот такое: https://github.com/foniod/redbpf

не намекаешь ли ты на то, что можно было бы пересоздать C++ с пакетным менеджером, и он будет сравним с растом?

Смотря какой смысл вкладывать в «пересоздать».

Звучит примерно как «разница между С++ и хаскелем по большей части субъективна». Да, в этом случае разница сильно больше, но всё равно можно применить твой аргумент: монады и ленивость в С++ можно изобразить

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

И много ты знаешь прям совсем-совсем новых БД? И почему тут не применим аргумент про ОС? Вот есть большой и стабильный постгрес. Переписывать его просто чтобы было?

Например:
https://github.com/redpanda-data/redpanda
Это прямо свежак.

А между прочим, по ссылке не только hello world-ы (например, sled)

Ну так и надо давать ссылку на sled — это хороший пример для «переписвать просто чтобы было». У меня аж флешбеки после моего PSO, где мне тоже пришлось заморачиваться с RW-блокировками, подсчетом ссылок, отображением страницов памяти, и высвобождением памяти после lock-free операций. Авторы sled, к слову, таки смогли сделать RwLock<Arc<T>> хитроумным способом с copy-on-write. По сути, вся БД представляется собой LLAMA с тем же Page Cache, Bw-tree и Epoch-Based Reclamation (EBR):

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/llama-vld...

Сразу предупрежу, что я считаю по src — биндинги к другим ЯП я не рассматриваю. 59% всего unsafe (163 штук на 7700 строк) содержится в page cache и EBR, которые вместе составляют примерно 43% строк кода. Писать их можно было бы с таким же успехом на C/C++. node.rs, tree.rs, transaction.rs еще относятся к самому хранилищу (около 15% кода), остальные 45% кода — самая разная обвязка (хэш, собственные блокировки, сериализация, backoff, и прочее). К слову, авторы статьи про LLAMA написали реализацию именно на C++.

Зачем Rust? Чтобы завернуть небезопасные сишные операции и писать условно безопасную обвязку на них? Я уже писал, что это и есть предположительное устройство крестовых проектов, в которых ты участвовал. При таком соотношении числа safe-unsafe кода, как в sled, safe обертки уже не будут создавать проблемы, даже если написаны на Си. Это я тебе пишу как человек, который писал обертки на Си в проекте примерно такого же размера (у меня 13 тыс строк, у sled 18 тыс) и оперативно находил ошибки работы с памятью в этих обертках. Как минимум благодаря тому, что таки создал некий уровень абстракций между обертками и кишками, через который большинство проблем не протекало — никакого Rust, заметь, только прямые руки.

Ну есть вот такое: https://github.com/foniod/redbpf

eBPF грузит и выполняет код В РАНТАЙМЕ. Этот же компилятор тупо выполняет растовые описания на макросах и скармливает их LLVM — в чем здесь заслуга Rust?

Смотря какой смысл вкладывать в «пересоздать»

То есть, повыкидывать наследие и выполнить язык в стиле последних стандартов C++.

Ладно, пока у меня нет настроения продолжать этот спор, может позже.