LINUX.ORG.RU
ФорумTalks

Опубликован RFC по добавлению кода на Rust в Git core.

 ,


0

6

https://lore.kernel.org/git/20250904-b4-pks-rust-breaking-change-v1-0-3af1d25e0be9@pks.im/

Пока в качестве proof of concept на rust был переписан один небольшой модуль varint.c. Основная цель - наладить систему сборки и принципы interop между кодом на C и кодом на Rust. Предполагается, что с версии Git 3.0 rust будет необходим для его сборки.

★★★★★
Ответ на: комментарий от beastie

И только у Rast такой идеи нет. Кроме как «переписать всё на раст».

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

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

provaton ★★★★★
() автор топика
Последнее исправление: provaton (всего исправлений: 1)

Ну rfc - это ведь пока не значит, что обязательно примут, да?

Предполагается, что с версии Git 3.0 rust будет необходим для его сборки.

Кем предполагается?

Beewek ★★★
()
Ответ на: комментарий от provaton

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

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

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

А вот то, что написание кода на расте сродни удаление гланд через зад - очевидно. Может поэтому растоманы и не могут ничего нового написать, они заняты ублажением своего borrow checker’a. Они думают не о задаче, а «чтобы скомпилилось». Языком Си можно думать, анальными абстракциями раста - нет

kvpfs_2
()
Ответ на: комментарий от provaton

Только почему-то ржавчина постоянно ломается. Скомпели ка мне вот это: https://github.com/matklad/rustraytracer

А по поводу юнит-тестов – это не для языка, а для логики.

beastie ★★★★★
()
Ответ на: комментарий от kvpfs_2

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

Ну смотря с какой стороны смотреть. Если смотреть соотношение количества ошибок работы с памятью и всех багов в принципе - да, немного. Но если смотреть соотношению кол-ва CVE, вызванных ошибками работы с памятью, и общего кол-ва CVE, то согласно подсчетам микрософта - это будет 70%. https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-systems-programming-language/ А CVE - это очень дорогой баг, это тебе не кнопочка на 5 пикселей вправо съехала.

Во-вторых, хорошая система типов помогает справиться в том числе и с логическими ошибками. Не со всеми, конечно, но в основном как раз с очень скучными и рутинными, на которые вот вообще не хочется терять время и энергию. Забытый обработчик ошибок, забытый if (some_var == null), забытый обработчик для какого-то варианта из энумерации, и прочее подобное. В результате меньше отвлекаешься на мелочевку и концентрируешься больше на логике программы. Например, представь программу, которая по сети получает какие-то данные, потом преобразовывает их по какому-то алгоритму и записывает в БД. И параллельно предоставляет интерфейс для чтения данных из БД, преобразованию, и сериализации в какой-то формат. На расте мне нужно протестить только две функции преобразования. Получение по сети, запись в БД, сериализация будут работать просто по факту компиляции.

А вот то, что написание кода на расте сродни удаление гланд через зад - очевидно.

Не очевидно.

они заняты ублажением своего borrow checker’a.

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

Языком Си можно думать, анальными абстракциями раста - нет

Почему ты так считаешь?

provaton ★★★★★
() автор топика

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

yvv1
()
Ответ на: комментарий от kvpfs_2

Этим «энтузиастам» за это платят?

Да.

Это единственный способ сделать язчок нужным?

Для раста - да. Погугли «Rust Evangelism Strike Force».

Stanson ★★★★★
()
Ответ на: комментарий от goingUp

А это потому что администрация ЛОРа по какой-то совершенно невообразимой причине не желает сделать «реакцию» КГ/АМ. Поэтому клоун получается сильно неоднозначным - его используют и вместо «КГ/АМ», и когда кто-то притаскивает очередную невменяшку от каких-то клоунов, и когда сам мимокрокодил клоунаду устраивает.

Я думаю большая часть клоунов относится вовсе не к самому ТС а к действующим лицам новости которую он притащил. По крайней мере я клоуна именно поэтому влепил, а не потому что у ТС КГ/АМ и не потому что он сам клоун.

Stanson ★★★★★
()
Ответ на: комментарий от provaton

Ну смотря с какой стороны смотреть. Если смотреть соотношение количества ошибок работы с памятью и всех багов в принципе - да, немного. Но если смотреть соотношению кол-ва CVE, вызванных ошибками работы с памятью, и общего кол-ва CVE, то согласно подсчетам микрософта - это будет 70%. https://msrc.microsoft.com/blog/2019/07/we-need-a-safer-systems-programming-language/ А CVE - это очень дорогой баг, это тебе не кнопочка на 5 пикселей вправо съехала.

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

Почему ты так считаешь?

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

А вообще мне на раст было бы фиолетово, ну есть ещё один язычок со своими адептами, мне не подходит. Ну вы же фанатики, которые хотят выжечь всех остальных и лезите во все щели

kvpfs_2
()

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

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

yvv1
()
Ответ на: комментарий от yvv1

производительности

Эту байку все растоманы повторяют как мантру. Но… где пруфы, Билли? ;)

I have written the same simple numerical program in Rust, C, Go, and was hoping that Rust runtime would be about as fast as C. It turns out that it is 10x slower than the best C compiled program, and 7x slower than the go version.

https://users.rust-lang.org/t/rust-vs-c-vs-go-runtime-speed-comparison/104107

beastie ★★★★★
()
Ответ на: комментарий от beastie

Ты сам-то читал что там по ссылке, которую цитируешь?

But as pointed out, i was (stupidly :stuck_out_tongue_closed_eyes: ) running the debug version.

Это не единсвенное место, где чувак накосячил.

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

yvv1
()
Последнее исправление: yvv1 (всего исправлений: 1)
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)