LINUX.ORG.RU
ФорумTalks

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

 ,


0

5

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