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
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)