Почему Discord сменил Go на Rust. Блог разработчика.

идиот

еще и нафигачил тут говнокода с макросами и unwrap, в лучших традициях так сказать.

clang-tidy?

Это же обычный линтер? Совершенно не то, для раста тоже есть clippy, но это инструмент другого уровня. Я даже не буду цепляться к тому, что одно дело когда прям компилятор тебе что-то говорит (и соответственно не даст собраться с ошибками), а другое - запускать внешнюю тулзу, что можно и не делать. Гораздо важнее, что unsafe видно в коде, а значит и на ревью гораздо проще удалять таким фрагментам особое внимание, требовать обоснования, дополнительных тестов и т.д.. Более того, можно повесить deny(unsafe_code) на модуль или даже библиотеку целиком и тогда это точно это не пройдёт незамеченным. Ну и если что-то вдруг пошло не так, то круг поиска сужается.

Если кто-то так помешан на безопасности, то достаточно сделать для проекта:

Не поможет. Например, с тем же unique_ptr компилятор никак не помешает сделать get и сохранить и потом попытаться использовать указатель. Или вернуть ссылку на временный объект. Аналогично со ссылкой на временный объект. Хотя в простых случаях тут компиляторы умеют предупреждение выдавать. Но именно в простых и только предупреждение.

В том и дело, что нельзя «просто грепнуть» и найти все потенциально проблемные места.

Ну и бороу чекер - это не только (и не столько) про отсутствие new/delete.

Не выходит как-то проникнуться.

Отвечал на вопрос об «основных фичах» раста. «Заставлять проникнуться» мне не интересно.

Как будто умные указатели от чего-то спасают:

	auto p = std::make_unique<int>(92);
	auto fn_once = [p = std::move(p)]() mutable {
		std::cout << *p << std::endl;
		p.release();
	};
	fn_once();
	fn_once();

Мда … . Безопасность доведенная до абсурда. А если if неправильный, тоже запретить к херам надо. Безопасные обертки для математиеческих операций add(), mul(), div(), а лучше вообще ничего не писать, ошибок меньше будет. Эра плюшевых программистов, которые как оберегаемые от всего дети от скуки попадут в «синий кит». Я тут вчерашний пример на расте немного поковырял, он меня просто заеб*л своим контролем и запретами, закрыл и вряд ли вернусь к этому скучному занятию вновь.

cmake+conan

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

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

Остальное все чисто чтоб С++ не учить.

В том-то и смысл, необходимость в количестве разработчиков растет быстрее, чем люди учатся писать на C++, поэтому придумывают Go и Rust, чтобы снизить порог вхождения в профессию. А микросервисы в этом плане помогают в разы быстрее переписывать легаси куски больших систем.

Всё верно. C++ сейчас можно сравнить с латынью: знать полезно и круто, но работать лучше всё-таки на более современных языках :)

Явно вызвал деструктор, удивляется выстрелу в ногу.

Всё гораздо приземлённей - своя экосистема с преданной паствой, с корпорацией в центре этого мирка.

Всё гораздо приземлённей - своя экосистема с преданной паствой, с корпорацией в центре этого мирка.

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

атомики, мутексы и rw-lock’и

Атомики из сишной либы и многопоток на pthreads. Чистый раст такой чистый раст.

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

Так что в safe Rust запрещается только несинхронизированное параллельное изменение данных, то есть data races.

В safe Rust запрещается любой мутирующий шаринг данных в многопотоке, что приводит к невозможности data races при корректности unsafe кода, на котором вся эта прелесть работает. Даже если допустить его корректность, это логика уровня «безногий не споткнется».

Не, это логика: потребуем поставить unsafe, чтобы самонадеянные программисты не плодили CVE в любом месте кода.

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

К сожалению программисты стреляют в ноги не себе, а юзерам. И то метафорически.

Не катит. Встроенный менеджер мотивирует юзать и публиковать пакеты. А конан - только для ценителей, которые в курсе. Скорость развития экосистемы не сопоставима.

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

Что значит встроенный? Нужно в стандарте прописать что ли? Достаточно инструкций по сборке к проекту на том же гитхабе:

    Tell Conan to install our dependencies for a Debug build, and build any that need to be built.

$ conan install .. -s build_type=Debug --build missing

    Configure the build using CMake.

$ cmake .. -DCMAKE_BUILD_TYPE=Debug

    Build using CMake.

$ cmake --build . --config Debug

А сценарии для сборки должны создаваться сообществом, а не бежать во всякие расты, ибо модно и больше пакетов. Мы прям сейчас можем пойти и свой вклад сделать (сценарий к чему-нибудь).

В расте можно рассчитывать на внешние пакеты.

Что для rust, что для go, как в подобных экосистемах, опакечивание приложений в дистрибутивах та ещё «содомия». При устранении ошибки или уязвимости в одной из over9999 статически линкуемых зависимостей приходится делать новый «релиз» и пересобирать всё заново. Для переноса исходников на другой комп тоже всю эту кучу приходится вылавливать. Не знаю, как им это удаётся: то что ранее раскидывалось максимум на десяток библиотек разместить в сотне пакетов. Вот уж действительно похоже, что вместо одной нормальной библиотеки есть набор ltrim, rtrim, capitilize и прочее.

Нужно в стандарте прописать что ли?

Надо чтобы шло к комплекте с компилятором, искаропки.

Достаточно инструкций по сборке к проекту на том же гитхабе

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

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

Вот уж действительно похоже, что вместо одной нормальной библиотеки есть набор ltrim, rtrim, capitilize и прочее.

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

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

А сценарии для сборки должны создаваться сообществом, а не бежать во всякие расты, ибо модно и больше пакетов

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

Прикинь, у многих не стоит задача защищать благополучие С++.

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

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

Там есть варианты зафорсить обновление подзависимостей.

Угу, ментейнер патчит список зависимостей, собирает статически и выкатывает новую ревизию.

С переносом на другой комп не понял.

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

Микрозависимости только дятлы устраивают.

Но почему их так много? Нет, некоторые приложения в итоге выглядят круто и полезны, но их список зависимостей вызывает тоску. Например у mercurial (USE=rust). И как только ментейнер решился эту опцию добавить?

CRATES="
adler-0.2.3
aho-corasick-0.7.15
ansi_term-0.11.0
atty-0.2.14
autocfg-1.0.1
bitflags-1.2.1
bitmaps-2.1.0
byteorder-1.3.4
cc-1.0.66
cfg-if-0.1.10
cfg-if-1.0.0
clap-2.33.3
const_fn-0.4.4
cpython-0.4.1
crc32fast-1.2.1
crossbeam-channel-0.4.4
crossbeam-channel-0.5.0
crossbeam-deque-0.8.0
crossbeam-epoch-0.9.1
crossbeam-utils-0.7.2
crossbeam-utils-0.8.1
ctor-0.1.16
difference-2.0.0
either-1.6.1
env_logger-0.7.1
flate2-1.0.19
format-bytes-0.1.3
format-bytes-macros-0.1.2
fuchsia-cprng-0.1.1
gcc-0.3.55
getrandom-0.1.15
glob-0.3.0
hermit-abi-0.1.17
hex-0.4.2
humantime-1.3.0
im-rc-15.0.0
itertools-0.9.0
jobserver-0.1.21
lazy_static-1.4.0
libc-0.2.81
libz-sys-1.1.2
log-0.4.11
maybe-uninit-2.0.0
memchr-2.3.4
memmap-0.7.0
memoffset-0.6.1
micro-timer-0.3.1
micro-timer-macros-0.3.1
miniz_oxide-0.4.3
num-traits-0.2.14
num_cpus-1.13.0
output_vt100-0.1.2
pkg-config-0.3.19
ppv-lite86-0.2.10
pretty_assertions-0.6.1
proc-macro-hack-0.5.19
proc-macro2-1.0.24
python27-sys-0.4.1
python3-sys-0.4.1
quick-error-1.2.3
quote-1.0.7
rand-0.3.23
rand-0.4.6
rand-0.7.3
rand_chacha-0.2.2
rand_core-0.3.1
rand_core-0.4.2
rand_core-0.5.1
rand_distr-0.2.2
rand_hc-0.2.0
rand_pcg-0.2.1
rand_xoshiro-0.4.0
rayon-1.5.0
rayon-core-1.9.0
rdrand-0.4.0
redox_syscall-0.1.57
regex-1.4.2
regex-syntax-0.6.21
remove_dir_all-0.5.3
rust-crypto-0.2.36
rustc-serialize-0.3.24
same-file-1.0.6
scopeguard-1.1.0
sized-chunks-0.6.2
static_assertions-1.1.0
strsim-0.8.0
syn-1.0.54
tempfile-3.1.0
termcolor-1.1.2
textwrap-0.11.0
thread_local-1.0.1
time-0.1.44
twox-hash-1.6.0
typenum-1.12.0
unicode-width-0.1.8
unicode-xid-0.2.1
vcpkg-0.2.11
vec_map-0.8.2
version_check-0.9.2
wasi-0.10.0+wasi-snapshot-preview1
wasi-0.9.0+wasi-snapshot-preview1
winapi-0.3.9
winapi-i686-pc-windows-gnu-0.4.0
winapi-util-0.1.5
winapi-x86_64-pc-windows-gnu-0.4.0
zstd-0.5.3+zstd.1.4.5
zstd-safe-2.0.5+zstd.1.4.5
zstd-sys-1.4.17+zstd.1.4.5
"

https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-vcs/mercurial/mercurial-5.7.ebuild

ага, показательный пример

rand-0.3.23
rand-0.4.6
rand-0.7.3
rand_core-0.3.1
rand_core-0.4.2
rand_core-0.5.1

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

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

Да так почти везде. https://github.com/GNOME/librsvg/blob/master/Cargo.lock

Там тоже куча пакетов повторяется, потому что всем зависимостям подавай свою версию.

Едрить,

[[package]]
name = "itoa"
version = "0.4.7"
...

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

Разработчики не в состояни объединиться и сделать одну библиотеку для манипуляции со строками, объединяющую подобные функции? Хорошо «сообщество».

Ах да, есть ещё dtoa, отдельно! В обоих куча unsafe блоков.

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

мувнуть

Нутыпонел. Мувая, ты явно показываешь, что этот объект тебе больше не нужен.

Ну смотри, в таком коде

auto i = new int(); delete i; delete i;

та же ситуация навроде «явно вызвал деструктор, удивляется выстрелу в ногу», значит смартпойнтеры не нужны по такой логике?

Угу, ментейнер патчит список зависимостей, собирает статически и выкатывает новую ревизию.

Есть возможность мимо ментейнера пропатчить, если он тупит. И на гитхабе dependabot шлет такие PR.

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

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

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

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

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

Твой подход, «нормальному айтишнику не проблема сходить» приводит именно к тому что имеем. Когда я пишу под эмбеды на с/cpp, с библиотеками полная жопа в стиле «вася выложил архив на форум».

Жесть какая-то, отпустил сам поинтр, потом обращается к нему и что-то этим доказать хочешь. Смотри еще один аргумент, когда будешь тыкать ЦППшников в дерьмо:

int main() {
...
   abort();
...
}

Компилируется без ошибок, а потом падает, сцуко!! Возмутительно!!

что тут можно обсуждать.

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

Прикинь, а мне вообще неинтересно защищать благополучие какой-нибудь дырвой корпорации

Например какой?

ЦПП/Ц одни из вещей, которые реально являются «общественным достоянием».

Пилится такими же foundations как все остальное

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

Чего нет?

Встроенного пакетного менеджера и нормальной экосистемы пакетов

А зачем он встроенный? Куча систем сборки умеют выкачивать зависимости.

Экосистема? Это слишком красивое слово для того, чем это сейчас является.

Ну вот в итоге и выходит, что на js/ruby/python/rust не проблема найти библиотеки под свои задачи, на на cpp выбор не очень.

Чего тут непонятного-то? Фиговая экосистема - прямое следствие «а зачем он встроенный?»

Под какие задачи ты не можешь найти библиотеки?

Так экосистема фиговая, раз встроенный - очень слабое звено.

Я знаю проекты, где в рамках системы сборки есть возможность выкачать зависимости или использовать системные. Собрать основную библиотеку и на её основе собрать биндинги для библиотек ещё на 3 языках. Cargo уже научился собирать для других языков?

Я не буду втягиваться в этот спор, оглянись вокруг.

Я и сам в таком участвовал, когда контора исчерпала возможности для «нормального» роста, то началось - экосистема, недоязычек, привлечение «миллионов», юзер френдли. Фу пля, наелся.

Все ликуют, кроме числодробителей. Числодробители получают ещё один полезный пинок для свалинга на не-POC языки.

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

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

Но переписывать свой же проект на другой язык ради переписывания и потому что что-то вдруг стало модно и там якобы больше пакетов (за счёт дробления на itoa, dtoa и т.п. что ли?) ничего не меняя в реализации - крайне странно.

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

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

Под какие задачи ты не можешь найти библиотеки?

Конкретно у меня - разновидности медианных фильтров и прототреды. Там везде надо либо свое лепить либо «поработать руками».

В lvgl - недавно аллокатор памяти подкручиваали (tlsf).

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

Cargo уже научился собирать для других языков?

Там много пакетов в виде биндингов. Деталей не знаю.

Так экосистема фиговая, раз встроенный - очень слабое звено.

Ну а я о чем твержу. ПлюсЫ просирают полимеры. Из-за моментов, с самим языком не связанных. Будь там с библиотеками как в клятом жыэсе или расте - я бы и не рыпался, сам язык меня устраивает.

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

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

И учти, я помогаю опакечивать нужные мне репы под platformio, помогаю в меру сил проектировать lvgl и делал туда вариант i18l и конвертор шрифтов. Ну то есть, я не занимаюсь нытьем и не являясь специалистом по цэпэпэ тем не менее понимаю про что пишу.

https://github.com/benhoyt/protothreads-cpp

median search

Те примеры, которые я нахожу строчек на 20, включая пример, и сначала просто сортируют.

Как насчёт работоспособных библиотек для графических интерфейсов?

Будь там с библиотеками как в клятом жыэсе или расте

«Удалить первый пробел», «удалить второй пробел», …. нет уж спасибо.

Но вот trim в стандартную библиотеку давно б могли добавить в реализацию для строк. А не отдельными библиотеками.

Дело не в том, чтобы взять плюсы. Это безотносительно языка, на котором написан проект.

я помогаю опакечивать нужные мне репы под platformio, помогаю в меру сил проектировать lvgl и делал туда вариант i18l и конвертор шрифтов.

Это как раз хорошо.

https://github.com/benhoyt/protothreads-cpp

Это вариант «после сборки добаботать напильником». Там «шедюлера» нет. И это, поверь, я в курсе про эттот реп и вообще все какие есть на тему прототредов.

Те примеры, которые я нахожу строчек на 20, включая пример, и сначала просто сортируют.

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

Как насчёт работоспособных библиотек для графических интерфейсов?

По эмбеды - никак. Иначе б я в lvgl не вписывался.

«Удалить первый пробел», «удалить второй пробел», …. нет уж спасибо.

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