LINUX.ORG.RU

Автор Wayland композитора Way Cooler переписывает своё детище с Rust на C

 , ,


2

9

Как-то давно смотрел список Wayland композиторов, в нём был проект Way-Cooler, примечательный тем, что декларировался как духовный наследник AwesomeWM и проект использовал Rust. Но недавно я набрёл на пост автора с грустными новостями. В новостях про Rust часто просят привести примеры ПО, разрабатываемого на этом языке, т.е. многим интересен опыт реального применения этого языка. Именно таким опытом и делится автор по ссылке выше.

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

Автор на протяжении примерно года писал биндинг к библиотеке wlroots, за это время он внёс более 1000 изменений и в итоге репозиторий wlroots-rs содержал более 11 тысяч строк Rust кода, при чём это не просто копипаста одного куска для каждой сущности библиотеки, автор написал несколько макросов, один из которых сам же назвал уродливым. Автор пишет, что все 11 тысяч строк это просто обёртки, которые занимаются управлением памяти и при этом они не покрывают и половины API wlroots. Кроме того, автор заметил, что разобраться и пользоваться плодом его трудов довольно сложно и некоторые отказываются от использования wlroots-rs в пользу wlroots.

Основными проблемами при написании обёртки для wlroots автор называет описание модели владения объектами wlroots на языке Rust. По ссылке автор показывает несколько примеров кода, которые демонстрируют проблему. Кроме того, автор не видит возможности написать на Safe Rust расширение протокола Wayland.

В итоге автор принял непростое решение переписать Way-Cooler на C. Автор упоминает некоторые другие проекты, столкнувшиеся с аналогичной проблемой написания биндингов, которые приняли противоположное решение – переписать библиотеки на Rust.

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

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

Если не умеешь использовать аналогии, лучше и не пытайся.
На пальцах:

Пугачёва != язык_программирования
// Ах, ты же не осилил C, тогда вот так:
Пугачёва <> язык_программирования
// Или так:
Пугачёва ~= язык_программирования

Надеюсь хоть так будет понятно.

Владимир

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

Причём тут твоя пугачева и архитектура фон Неймана?

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

С годами все лучше и лучше становится

На самом деле оно уже прокисло давно, но упоротые «ценители» продолжают хлебать и нахваливать

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

Дискуссию с вами не я веду.

Владимир

anonymous
()

Пока на закрыли комменты зовите Царя в тред.

anonymous
()

А мог бы вместо враппера написать rust++ по аналогии с d++, и тогда бы больше ни у кого не возникло нужны обвязывать код на расте врапперами

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

На D вообще нет нужды писать врапперы для сишечки. Да и для плюсов не всегда нужно. Биндингов достаточно и работает все из коробки.

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

лучше это время пустить на что-то другое.

На разбор и переписывание библиотек с C на D хотя бы.

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

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

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

Наверное, 99% хейтеров С — тупо новички, которым хочется с места в карьер. Чтобы ничего не изучать, а тупо «сесть и игры писать». А задела нет, поэтому такое говно и получается.

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

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

Странно, что он не прошарил раньше. На зато теперь шарит, да.

i-rinat ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

подключаемая к человеку система была запитана от обычного китайского блока питания

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

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

И только потом, поняли, что с ними не девочки из инстаграм общаются, и, вообще, «прокурор ближе, чем они думали».

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

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

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

У кого-нибудь осталась ссылочка? :)

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

«конструктора-ЭКГ», у которого подключаемая к человеку система была запитана от обычного китайского блока питания.

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

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

оржественно именуешь её «Цельная СИшка с надёжными буфферами»

Кто помнит Cyclone? Кто-то знает почему он помер?

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

Он оказался недостаточно модным и молодёжным.

Владимир

anonymous
()
Ответ на: комментарий от quantum-troll

Нагуглил, его дело оказывается частично живет в Rust.

The Cyclone language was an attempt to add memory safety to C. In a way, many of its objectives were similar to those of Rust. In fact, Cyclone is highlighted as one of the influences on Rust.

Cyclone adopts the region-based approach to memory management. In this approach, data is allocated into regions and references are annotated to identify the region in which the data they refer to resides. ... Simplistically, we can say that regions are like lifetimes in Rust. Certainly, they exhibit many similar properties.

Cyclone’s approach offers more flexibility in terms of the structures it can represent but, at the same time, is perhaps more “relaxed” about deallocation of memory.

Rust is quite strict, on the otherhand, but as a result can be more aggressive in deallocating memory. Rust also perhaps hides users from memory management to some extent, as such details are often hidden behind abstract data types (like Vec)

anonymous
()

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

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

Ну вот тебе другая история. Восемь месяцев назад попробовал раст. Вначале был шокирован от непонимания того, как на нем вообще что-то можно нормально писать. Хотел бросить это дело, но вспомнил про свой опыт со scala, которая произвела на меня такой же эффект. Я искренне не понимал как можно на ней что-то написать, пока не понял, что нужно полностью выкинуть из головы все чему меня учили много лет дяди в книжках по ООП и классическому программированию и впустить в свою голову новую идеологию - функциональное программирование. Эффект был настолько сильным, что после него Java стала выглядит жутким костыльным монстром из канализации и писать на ней я могу теперь только под сильной анестезией (за значительное денежное вознаграждение). Вот то же самое я сделал с растом, перестал видеть в нем обертку над си, и решил что не нужно мешать компилятору выполнять его работу. И после этого раст из непонятного уродца превратился в могущественного доброго волшебника, позволяющего писать чистый, безопасный и очень быстрый код. Испытал сильную боль за то, что написал десятки тысяч строк на си, потратил недели на поиски утечек , сегфаультов и прочей подобной лабуды. А ведь будь у меня под рукой раст, сколько времени можно было бы сэкономить.

Что конкретно писалось мной на расте. Ну с десяток мелких консольных программок я не беру в расчет. Написал карманную систему расчета радиаторов по методу MCA. Переписал библиотеку Akka Actors на раст с учетом специфики языка (крейт sealrs если кому будет интересно, заранее извиняюсь за очень кривой английский в доках). Последний месяц занимаюсь активным переписыванием личной библиотеки микросервисов со scala на rust. Рассматриваю планы по переписыванию вот этого проекта на раст, так как он был заброшен по причине невозможности работы jvm на < ARM7 и крайней прожорливости данной технологии по ресурсам, что неприемлемо для таких систем (это прошивка для построения аппаратно-индифферентных ПЛК)

Какое у меня впечатление сложилось о данном языке? Ну за исключением некоторых шероховатостей этот язык смело дает хорошего пендаля джаве на поприще веб-программирования и еще более жесткого пендаля си на поприще системного яп. Но у него две серьёзные особенности. Первая - высокий порог входа (на мой взгляд выше чем у крестов). Вторая - необходимость уметь менять парадигму мышления. Эти две особенности полностью перекрывают к нему доступ хипстерам-хомячкам (первая особенность) и порождают толпу хейтеров-ксенофобов (вторая причина) которые не видят ничего дальше того, чему их научили в университете/на последней работе. Из-за этого вокруг языка сформировалась довольно странная атмосфера, часть его просто не понимает, часть его ненавидят за то что он отличается от других яп, а часть постигла его дзен и просто молчат, потому что им уже доказывать точно ничего не нужно и они просто его используют в каждодневной работе.

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

На дишечке, например. Тоже не идеал, но куда удобоваримее педеруста.

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

Как минимум — с надежной гальванической развязкой. Но лучше всего — от батареек, чтобы уж наверняка не шарахнуло. Читай нормы на медицинское оборудование.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от MyTrooName

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Serbis

Хотел бросить это дело, но вспомнил про свой опыт со scala, которая произвела на меня такой же эффект.

И сколько ты потратил времени на изучение Scala?

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

этот язык смело дает хорошего пендаля джаве

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

Ну серьезно, ладно конкуренция с си и крестами - там понятно. Но тащить раст в высокоуровневое программирование... Норкомания какая-то.

anonymous
()
Ответ на: Нашел кулстори. от shkolnick-kun

Во, точно!

Плохо только, что нормальные статьи в это говно зачем-то публикуют!

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от anonymous

Функциональщина в расте покруче чем в ява.

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

А то я все тот грузовой лифт на абдурине вспоминаю

Не упал он ещё?

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

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

Serbis
()
Ответ на: Нашел кулстори. от shkolnick-kun

Имя автора показалось знакомым...

Пару лет назад закладывал в одну из разработок blackswift.

Конец немного предсказуем: https://m.habr.com/ru/company/unwds/blog/387369/

В общем, Артамонов -хороший пиарщик, и кое что понимает в технике, но со свифтом - нехорошая история получилась.

shkolnick-kun ★★★★★
()
Ответ на: Имя автора показалось знакомым... от shkolnick-kun

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от anonymous

Очень просто. 1. Потребление памяти, в рантайме в 100-150 раз меньше чем у jvm. Если у вас кластер с репликами, это это сотни гб озу уходящих в никуда. Что бы это прочувствовать, попробуйте сделать несложное веб-приложение (5-7 микросервисов) на VPS. Результат будет очень простой, оно не будет нормально работать потому что пойдет свап-оверхед. Пример частный, но отмасштабируйте его до уровня датацентра и получите схожего рода проблемы только иного класса. А вот микросервисы на расте в приведенном примере работают прекрасно. 2. Jvm медленная, c джитом, со всеми оптимизациями она в самых хороших условиях работает раза в 4 медленнее чем раст. Она удобоварима ровно до того момента, пока вам не нужно делать активный io. Как только это случается (например обработка потоков данных через ws), jvm скатывается по скорости до уровня питона.

Ручное управление памятью

Ээээ, где вы видели в расте ручное управление памятью?

отсутствие инфраструктуры

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

серьезного использования

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

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

Лень — двигатель прогресса. И человек всегда старается облегчить свою работу

все правильно. кто-то учит раст, потому что лень жрать кактус, а кто-то жрет кактус, потому что лень учить раст.

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

С каких там годов Пугачёва поёт?)

Ты извращенец-герантофил. У тебя как у Галкина, только Пугачевы на уме, да лопающиеся буфера.

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

Ээээ, где вы видели в расте ручное управление памятью?

Не ручное, но явное. Нет гц, решающего эту проблему за тебя.

quantum-troll ★★★★★
()
Ответ на: комментарий от Serbis

Таких людей мало чтоб такое осилить, у меня, жабодевелопера, на изучение базовых конструкций Kotlin ушел месяц, чтоб просто писать код, а со всеми абстракциями я разобрался после того как полгода на нем писал. Плюс еще корутины по верхам - месяц. И typescript месяца два до момента когда вопросов не осталось. Но все это ООП языки. А тут haskell, scala, rust, и все с новыми парадигмами...

А ты можешь сказать зачем? Чисто интерес или поиск удобного инструмента для конкретных задач? Потому что в моем случае это было второе, задача первича инструмент вторичен. На js без типизации писать я не смог, а анодроид с жабами разных версий меня напугал, плюс еще выяснилось что код с корутинами понятней чем java + реакт фреймворки.

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

А от какого блока питания она должна быть запитана?

Очевидно же, что от необычного американского (который сделан в Китае).

anonymous
()
Ответ на: комментарий от quantum-troll

Ну и? Эту проблему решает компилятор. И если активно и целенаправленно не мешать ему это делать, то никакой разницы между gc и borrow checkerом я не наблюдаю.

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

Странные у тебя сравнения. Какой кактус? Нормальные средства, проверенные временем и надежно работающие. А [censored] — какая-то хипстота, да и только. Тупо придумали новый ЯП, потому что скучно было. Нет смысла на него свое время тратить. Другое дело — если захочется вдруг в GUI, то придется, наверное, учить кресты, т.к. в С с оопщиной хуже значительно.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от anonymous

А ты можешь сказать зачем? Чисто интерес или поиск удобного инструмента для конкретных задач?

Сильные языки являются самостоятельными инструментами. А слабые же сами по себе бесполезны и под каждый чих требуют фреймворк. Вот пример. У меня есть небольшая подработка - я собеседую кандидатов для одного интегратора. В основном идут как раз джависты. В перечне вопросов у меня есть такой - объясните что такое Domain Driven Design и как эта методология влияет на архитектуру серверного ПО. Я отсобеседовал по джаве где-то человек 15, и ответило мне на этот вопрос только двое. При этом оба не понимали как именно данный метод определяет архитектуру конечного кода. Затем я им стал им рассказывать про спринг - а вот у вас там есть репозитории, сервисы, сущности, контроллеры, ничего не находите похожего. И о чудо, людей осиняет, что спринг это и есть оказывается фреймворк построенный на DDD! Т е люди каждый день работают с некоторой системой и не видят за ней фундаментальных архитектурных паттернов.

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

Резюмируя сказанное - языки по типа Java/C++/Python являются в большей мере языками для написания инструментов, а такие как Scala/Rust/Haskell сами по себе воплощают в себе инструмент. Как я к этому пришел? Много писал на java за деньги и со временем мне стала закрадываться мысль о том, что это не очень удобный и довольно угловатый язык. Возникла мысль - а есть ли что-то лучше? Выяснилось что есть! Вы можете использовать веер из языков и фреймворков первого типа и эффективно решать десять разных задач десятью разными способами. Или же вы можете взять один язык второго типа и столь же же эффективно решить эти задачи всего одним способом. Я пришел к выводу о том, что лучше иметь в распоряжении пару современных танков, чем десяток ржавых рыдванов времен первой мировой.

Serbis
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.