Продемонстрирована возможность разработки частей Linux на Rust

Касаемо сишников ... достаточно организационно-дисциплинарных мер

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

Должны быть выкатаны рабочие продукты на rust'е, крайне желательно - оригинальные.

Проблема в том что оригинальное — это новое, а то что сейчас на находится на, как модно говорить, вершине хайпа в сфере IT не интересно большей части аудитории.
Как пример: Parity, сейчас это самая продвинутая блокчйн-платформа, а не просто очередной клиент для ethercoin, как принято считать, но о ней мало кто слышал, потому что этим не пользуются напрямую большинство людей.
Сейчас слежу за развитием пары новых интересных финтех стартапов на его основе.

Но пока начало жизни у rust'а чрезвычайно болезненное.

Судя по...?

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

В heartbleed'е виноват лидер проекта, который разрешил запилить креативному творцу сомнительную возможность, которая нахрен никому не сдалась, и которой никто не подозревал. И да, креативные творцы нафик никому не нужны, один нормальный инженер стоит дюжину таких.

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

Куда этот Раст только не суют. Он нигде никакой популярности не завоевал, даже в самой какой нибудь мелкой нише. А его всё суют и суют. А давайте ещё куда сунем наше говно, авось приживётся.

В heartbleed'е виноват лидер проекта

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

продукт должен получить некотурую массовость

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

Порочный круг: что-то привычное и имеющее аналоги «не нужно потому что есть X, которому уже куча лет», что-то новое — «да кому оно вообще сдалось, напишут что-то нужное — тогда посмотрим»

Он не сиподобный. Сиподобный мне нравится (а-ля linux kernel или openbsd).

linux kernel и openbsd — это языки с си-подобным синтаксисом? Не знал.

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

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

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

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

Т.е. первоначальная фраза о том, что rust требует прямые руки, была лукавством? rust практикует частое битье по рукам? Вот это - очень неплохо, но нужно посмотреть на реальные результаты.

Опасаться нужно только опытным костылестроителям... Потому что раст не разрешает писать костылей...

Будем посмотреть, но очень сомнительно: окружающий мир нас любит, он сам такой.))

Т.е. первоначальная фраза о том, что rust требует прямые руки, была лукавством?

Первоначальная фраза была о том что рандомный говнокод написанный кривыми руками не скомпилируется. В то время как в C++ он скомпилируется успешно, но будет иногда падать в рантайме.

Так ответь: rust похож на perl или php?

Ни на один из них.

Возможно, я только Мейера знаю

Мэйерс, Мэйерс https://www.youtube.com/watch?v=RT46MpK39rQ

но там дела еще хуже чем у D

С чего бы это?

но в итоге неудочной политики распространения популярен не стал

И Питон не сразу пошёл в народ. Сейчас и ближайшие годы --- как раз удачное время.

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

rust практикует частое битье по рукам? Вот это - очень неплохо

Да, нетакимкаквсе придётся туго.

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

Сказал человек, который пишет ненужно-либу на плюсах с четырёхэтажными шаблонами.

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

это классика жанра. 30 лет назад, такая классика привела к появлению Си. Ибо соблюдение строгих правил там, где слежение лучше поручить тупой железке, не способствует. И скорее приводит к ошибкам (чел. фактор), чем их устраняет.

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

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

Как строгие правила приводят к ошибкам?

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

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

излишнее утомление => ошибки.

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

я же говорю, классика жанра. Это всё уже было, так, или иначе.

Понятно и оправдано в критических областях, но никак не в 100% случаев.

излишнее утомление => ошибки.

В С/С++ программист делает работу компилятора Rust, почему в Rust он будет больше утомляться, если он не думает об этих проблемах?

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

эквивалентно многократному росту времени, отводимому на разработку.

Не вижу тут связи, например я участвовал в одном крупном проекте на C и у нас ушел год на исправление багов и сегфолтов, из них процентов 90 словил бы раст еще на этапе написания кода.

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

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

Что-то тут https://doc.rust-lang.org/book/primitive-types.html я не вижу ничего, кроме usize

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

Я смотрю, что тут все балаболы. А может, ты объяснишь, что ты имеешь в виду?

Правильно ли я понимаю, что мой код на расте превратится в длинное нечитабельное убожество из кучи вызовов wrapping_xxx() ?

Правильно ли я понимаю, что мой код на расте превратится в длинное нечитабельное убожество из кучи вызовов wrapping_xxx() ?

Да, как и на любом другом ЯП.

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

излишнее утомление => ошибки

Утомление будет от поиска сегфолтов в многопоточном приложении на C/C++. Или вы отладку и исправление багов не считаете частью разработки?

Понятно и оправдано в критических областях

Какие ещё критические области? Плазма падает - и всех это бесит. Но WM ни разу не является критической областью.

А почему стандартный оператор + не может работать именно, как wrapping_add()? Почему разрабы языка решили сделать наоборот?

Потому, что wrapping_add медленный.

Честно говоря, мне такой подход напоминает апологетику спиливания перил на лестницах.

А еще твой подход подпадает под Уголовный Кодекс: воображать такую хренотень возможно только под веществами.

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

Честно говоря, мне такой подход напоминает апологетику спиливания перил на лестницах.

Так где этот божественный безглючный продукт, на которой было потрачено 7 лет и безумное количество человеко-часов?

Потому, что wrapping_add медленный.

Неправда

https://godbolt.org/g/3ulBEY

Цитировать и считать научись, умник.

int* lol = (int*) data;

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

Вы кому Америку открыли? Где доказательство, что const можно изменять?

Я думал, что Вы покажите указатель на константное выражение и измените сам указатель или константный указатель на некое выражение. Вы же опустились до cast...

Да, Вы можете так сделать. Именно так и задумано. И это правильно, логично и здорово.

У меня ноль критики к данному поведению С. Это самое правильное поведение из возможных.

На этом принципе построено существование union. Тоже очень нужный иногда необходимый тип данных. В примитиве возьмите тип double и 64 битный int.

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

Это пример хорошего coding style :)

В С/С++ программист делает работу компилятора Rust, почему в Rust он будет больше утомляться, если он не думает об этих проблемах?

В Rust программист будет точно так же думать какие типы данных использовать. Что делать с этим идиотским владением на указатели итд итп.

Доказано многократно, что чем больше сущностей, тем больше шансов совершить ошибку.

Если код можно написать 5-ю возможными вариантами, то будет использован самый медленный и самый ненадежный.

Это универсальное правило работающее в любой области человеческой деятельности.

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

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

Нужна скорость написания и безопасность бери Go. точка.

Тебе напомнить про openssl, в который было мало коммитеров в том числе потому, что его код написан в настолько отвратительном стиле, что многие просто не хотели это читать?

Сколько я видел говнокода и говнокодеров, самая частая проблема - человек сам не знает что он делает что-то неправильно.

Гениально. Проблема только в том, что если человек не умеет грамотно писать и/или не умеет ясно излагать свои мысли, то совершенно бесполезно подбирать ему другой алфавит или другой язык. Это никак не поможет решить проблему. Единственный путь это освоение грамотности.

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

Нет, он ничего не убирает, он изначально не содержит их.

`wrapping_add` это просто одна инструкция процессора

`+` это в debug режиме `add.with.overflow` (медленно, содержит проверки на переполнение)

а в релизе `+` заменяется на `wrapping_add`

Да... openssl содержал heartbleed из-за оформления кода, а не из-за того, что сишка небезопастна.

он изначально не содержит их.

Да, это и имел ввиду.

Что делать с этим идиотским владением на указатели итд итп.

Нет там указателей... Хоть бы доку почитали, прежде чем тупить.

Доказано многократно, что чем больше сущностей, тем больше шансов совершить ошибку.

Кем доказано? Проги на сишке, которая простая как пробка, содержат больше всего ошибок и уязвимостей. Совпадение?

Это универсальное правило работающее в любой области человеческой деятельности.

Клиника.

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

Фанбои в треде. Как там с ручной обработкой кодов возврата и дженериками? Про зависимости вообще молчу.

Нужна скорость написания

Индусы в треде. Все по машинам.

и безопасность бери Go

Какие гарантии безопасности даёт Go, какие не имеет rust? От гонки данных Go уже защищает? Нет? А rust - да.

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

Я и на жаваскрипте пишу, и на говнопитоне писал (точнее, переписывал чужое поделие под новые реалии). Давайте ядро на питоне писать.

Если Rust хочет помочь, то он должен не программиста заставлять что-то писать

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

Нужна скорость написания и безопасность бери Go.

Это в какой-то мере верно только если ты пишешь очередной банальный уэб-сервис и точно уложишься в средства стандартной библиотеки. Если же тебе нужны какие-то небанальные алгоритмы и контейнеры, ты упрёшься в то, что готовых реализаций на дженериках нет, и придётся либо ваять свою реализацию под свои типы, всирая скорость написания, либо погружаться в чужие реализации на interface {} и динамик кастах, всирая типобезопасность.