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.

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

Тогда я что-то не понял. Поскольку речь шла вот об этой части: «Я видел как в сишечке функция с типом long возвращает переменную типа char»

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

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

А кто вам сказал, что «возможности» == «безопасность».

Мы же про C++ vs Rust или как? Ну если речь идёт про возможности, то Rust далеко впереди (не считая вариадиков).

Его легко переиспользовать.

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

Ну вот в каком-то из Rust-овских обсуждений бросили ссылку на некий крэйт с реализацией эффективной lock-free очереди. У которой по капотом все на unsafe.

Всё верно, ибо Send и Sync unsafe по определению.

Хорошо, какие проблемы привносят санитайзеры?

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

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

Мы же про C++ vs Rust или как?

Да. И я повторю еще раз то, о чем говорил:

Есть неасиляторы C++, застрявшие на уровне «C с классами», не использующие возможности C++. Они не получают никаких бенефитов от C++, но зато гребут проблемы с безопасностью полной ложкой. Для таких переход на Rust хотя бы избавляет от проблем с безопасностью.

Есть остальные, которые вовсю используют то или иное подмножество C++. И получают бенефиты. Например, в уменьшении объема кода, большим контролем в compile-time, реализацией нужных им абстракций. При этом гребут проблемы безопасности также, но уже в меньшем объеме.

Переход на Rust даст им большую безопасность, это однозначно. Но вот компенсирует ли потерю всех других бенефитов... Тут большой вопрос.

И на всякий случай повторю еще раз: это мое объяснение того, что в Rust сейчас больше переходят разработчики с других языков, нежели опытные C++ники.

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

Во-первых, это не обязательно.

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

Всё верно, ибо Send и Sync unsafe по определению.

Ага. Вот так вот рассказы о safe rust и гарантиях плавно превращаются в случаии, когда unsafe по определению.

Старая песня. Можно не продолжать.

Проверят только тот код, который был вызван.

И что, это теперь называется «создание новых проблем»? Раньше санитайзеров не было, даже тот код, который бы вызван, в run-time проверить было нельзя. Сейчас можно. И это стало проблемой. Отлично, чё :)

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

Ха-ха! Шикарное заблуждение, что это поможет. Когда у тебя legacy, ты тупо не можешь включить эту опцию, потому что у тебя ничего вообще не соберется. А статический анализатор выдает столько информации, что диву даешься как это все работает. НО! Это все реально работает. Приносит деньги. Ты уверен, что ты сможешь убедить руководство выделить время и деньги на устранение технического долга копившегося последние 10 лет минимум в условиях когда продукт работает и приносит деньги, а еще нужно реализовать много фич, которые уже требует заказчик, потому что они нужны были вчера?

Добро пожаловать в реальный мир, писатель драйверов для линукс.

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

Ты уверен, что ты сможешь убедить руководство выделить время и деньги на устранение технического долга копившегося последние 10 лет минимум в условиях когда продукт работает и приносит деньги, а еще нужно реализовать много фич, которые уже требует заказчик, потому что они нужны были вчера?

И тут приходит хипстер и говорит: а дальше мы будем писать на Rust!

:)))

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

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

для своего драйвера я могу включить любую опцию

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

Это, конечно, ложь, раст — это следующее поколение, искупление грехов создания С++

А в чем там был «грех»? Страуструпу нужен был ООП язык и компиляция в эффективный код как инструмент для работы над диссером. Диссер защитил, С++ эволюционировал в то, что он есть сейчас. Страуструп подходил к программистам и заставлял под дулом пистолета писать на С++? В чем «грех»?

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

Есть остальные, которые вовсю используют то или иное подмножество C++. И получают бенефиты.

Какие?

в уменьшении объема кода

Во времена electron это уже даже не смешно.

что в Rust сейчас больше переходят разработчики с других языков, нежели опытные C++ники.

И у вас есть какие-либо статистические данные на этот счёт? servo пишут плюсовики, если что.

В случае C++ такого онанизма просто не было бы.

Ну попробуйте обернуть указатель со своим счётчиком ссылок в shared_ptr. А значит или используем сырые указатели или пишем свои врапперы. Разницы никакой.

Ага. Вот так вот рассказы о safe rust и гарантиях плавно превращаются в случаии, когда unsafe по определению.

Ну как бы unsafe является частью языка и его существование никто не отрицает. Вопрос в частоте его использования. А она исчезающе мала.

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

для своего драйвера я могу включить любую опцию

Ну можешь конечно. Просто жизнь обычно сложнее. В теории все звучит классно, а на практике возникают маленькие нюансы. Сишечка для некоторых вещей, в частности драйвера, не обязательно ядра линукс, действительно подходит. Потому что там все на низком уровне, на уровне байт и регистров. А для высокого уровня уже не комильфо. Для больших и сложных проектов, где есть множественные взаимосвязи между компонентами, особенно когда нет ТЗ или оно дорабатывается в ходе разработки сишечка не так подходит как тот же С++ - там уже есть и перегрузка, и шаблоны и т.д. На плюсах модели получаются компактнее - я портировал сишный код и на плюсы, и на D - реально половину сишного кода просто выкидываешь. На плюсах и код компактнее за счет тех же шаблонов. И более читабельный за счет той же перегрузки функций. Сишечка нишевый язык, по факту.

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

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

Какие?

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

Во времена electron это уже даже не смешно.

Речь не про объем бинарного кода, а про объем и сложность исходного.

И у вас есть какие-либо статистические данные на этот счёт?

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

Вы можете у местных Rust-адептов поспрашивать, как много из них пришли в Rust именно из современных плюсов. И насколько они этими плюсами владели.

servo пишут плюсовики, если что.

И где то серво после стольких лет разработки?

А значит или используем сырые указатели или пишем свои врапперы. Разницы никакой.

Повторю еще раз:

Во-первых, это не обязательно.

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

Постарайтесь напрячься и вдуматься в то, что вам пишет собеседник. Для вас это сложно, но сделайте все-таки усилие над собой.

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

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

так я же не спорю :) заблуждение у некоторых в том что rust им что-то даст в этой сфере.

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

И тут приходит хипстер и говорит: а дальше мы будем писать на Rust!

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

З.Ы. а вот на D, кстати, реально переписать часть сишного или плюсового проекта не затрагивая остальной код. Так был компилятор переписан с плюсов на D. Поэтому D это более реальный вариант переписывания, чем Rust. Человек, который пишет на С/С++ может начать писать на D практически сразу. И safety в D тоже есть, меньше чем в расте, да, но больше чем в C/C++

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

И где то серво после стольких лет разработки?

В Firefox Quantum

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

Человек, который пишет на С/С++ может начать писать на D практически сразу.

Я как бы в курсе. Эксперментировал с D1 в прошлом. И немного отслеживал D2.

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

Я как бы в курсе. Эксперментировал с D1 в прошлом. И немного отслеживал D2.

Да я в курсе, что вы в курсе)) Это больше для стороннего читателя)

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

так я же не спорю :) заблуждение у некоторых в том что rust им что-то даст в этой сфере.

Ну теоретически Rust может дать что-то в этой сфере. Только цена будет очень высокая. Так что практически ничего не будет.

В этом и промах Rust, на мой взгляд, что он слишком многое приносит в жертву своей идее. Принцип «все или ничего» играет против него. Никто не будет переписывать все на Rust. А без этого гарантий безопасности уже не будет. Но польза от Rust, конечно есть. Как минимум его опыт будет учтен в очередных языках, да и в существующих. А в нише, связанной с безопасностью, он будет востребован, я думаю.

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

Ах да, я же забыл, что у вас очень скудные представления о C++.

Главное верить (с)

как много из них пришли в Rust именно из современных плюсов

См. выше. Я бы с удовольствием использовал «современные плюсы», но я в упор их не вижу. А мне бы они очень пригодились в Qt коде. Только не нужно про убогие string_view, optional, variant и algorithms. Я про что-то, что лучше или как минимум не хуже rust альтернатив.

И где то серво после стольких лет разработки?

Чуть менее чем на половину в лисе. servo - это тестовый полигон для обкатки новых идей.

В случае C++ такого онанизма просто не было бы.

То есть аргументов не будет?

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

А без этого гарантий безопасности уже не будет.

Советую изучить основы языка.

Принцип «все или ничего» играет против него.

Наличие unsafe противоречит вашему тезису.

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

Вы так говорите, как будто я один не осилил C++. Количество багов в плюсовом коде говорит строго об обратном.

Главный поинт в том, что этот софт есть и он двигает экономику дальше, в отличие от. Вот когда кодовая база на Расте станет хотябы 1/3 (произвольное число «больше, чем ничего) - вот тогда можно будет сравнивать, а пока сравнивать нечего, как в прочем нет и повода для срача тут на эту тему.

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

Главное верить (с)

Нет, просто я с вами уже несколько лет здесь общаюсь. Как бы есть представление о том, насколько вы «владеете» C++.

См. выше.

См. выше что? Я вам сказал, откуда у меня представления о качестве переходящих в Rust из C++. Так на что мне еще смотреть, вы какую-то свою статистику показывали?

Скорее вы в очередной раз тупите.

Я бы с удовольствием использовал «современные плюсы», но я в упор их не вижу

И это проблема современных плюсов, ага. Ну OK.

Только не нужно про убогие string_view, optional, variant и algorithms.

А я про них и не говорил. Можно было бы рассказать про нормальный ООП, с наследованием реализации, с множественным наследованием. Про шаблоны. В том числе параметризуемые скалярами. Не говоря уже про variadic-и. Про constexpr-функции. Про if constexpr. Про inline-переменные, про inline namespaces и разные другие вещи.

Только не в коня корм, вы, как яркий представитель разработчика с Qt головного мозга дальше std::optional и std::variant не видите.

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

Чуть менее чем на половину в лисе.

Охриненный результат для стольких лет развития, да.

То есть аргументов не будет?

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

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

Наличие unsafe противоречит вашему тезису.

Так я и имею в виду, что если что-либо делать через unsafe - так а зачем оно тогда? Наличие unsafe нарушает гарантии, предоставляемые Rust. Просто потому, что какими бы замечательными возможностями язык не обладал, если где-то глубоко будет unsafe, то есть вероятность, что возникнет ошибка, баг, утечка. А если использовать сторонние либы, написанные не на Rust, то так и будет. Отсюда и ноги растут у RiiR. Во всем мире принято лечится от синдрома NIH, а в сообществе Rust все наоборот. Потому что использование unsafe стирает различия между Rust и С++ в плане безопасности. Немного утрировано, но смысл именно такой.

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

нормальный ООП

Вкусовщина. Интерфейсы куда удобнее.

множественным наследованием

Это уже стало достоинством?

В том числе параметризуемые скалярами.
Про constexpr-функции. Про if constexpr.

Уже в nightly.

Про inline-переменные

Костыль. В языке с модулями тупо не нужно.

inline namespaces

Лул. Так себе костыль. Нет чтобы нормальный ПМ запилить.

дальше std::optional и std::variant не видите.

И это всё? Я думал может в этот раз услышу что-то новое. А тут перетирание старых костылей.

Охриненный результат для стольких лет развития, да.

5-6 лет всего. У вас, конечно же, уйдет намного меньше времени на написания языка и половины браузера.

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

Вкусовщина.

Сказал человек, требующий от других каких-то аргументов.

Специально для вас: без разницы, как вы лично оцениваете возможности C++. Они есть. Ими можно пользоваться. Можно не пользоваться. Есть выбор.

И те, кто выбрал их использование (скажем, того же множественного наследования), просто лишаться привычного им инструмента сменив C++ на Rust.

А посему вопрос стоимости перехода с современного C++ на Rust отнюдь не такой простой.

За исключением вашего случая. Поскольку вы и C++ используете постольку, поскольку. Да и умом отличаетесь. И кругозором.

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

Так я и имею в виду, что если что-либо делать через unsafe - так а зачем оно тогда?

Для локализации. Ваш КО. 100% unsafe или 5%. Выбор за вами.

Во всем мире принято лечится от синдрома NIH, а в сообществе Rust все наоборот.

Вы лично сколько биндингов написали? Хотелось бы услышать историю успеха.

Немного утрировано, но смысл именно такой.

Смысл строго противоположный.

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

Мне вообще иногда кажется, что Фалкон - это проект по дискредитации раста. Ну нельзя же так тупить всерьез.

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

Речь шла про фичи C++, которых в принципе нет в Rust. Вы назвали только ООП и вариадики. Это и так всем известно. Но это не делает C++ удобным, современным и безопасным. Ну и смысл тогда?

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

RazrFalcon ★★★★★
()

Rust ненужен, Wayland ненужен, композитор - это человек, пишущий музыку. Вроде всё понятно.

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

Речь шла про фичи C++, которых в принципе нет в Rust. Вы назвали только ООП и вариадики. Это и так всем известно. Но это не делает C++ удобным, современным и безопасным.

Пилять, такое ощущение, что вы разговариваете не со мной, а с голосами в своей голове.

Речь (по крайней мере с моей стороны) шла о том, что

  • современный C++ далеко ушел от древнего C++. Поэтому разрабатывать на C++ сейчас – это уже несколько не то, что разрабатывать на C++ даже 10 лет назад. Иногда сильно не то;
  • но при всем при том, C++ имеет безболезненную интеграцию как с C-шным наследием, как и со всем остальным, что может выставить наружу C-шный интерфейс. В отличии от Rust-а, что видно на примере обсуждаемой статьи;
  • разработчики, которые активно используют фичи современного C++, будут лишены оных при переходе на Rust. А значит стоимость такого перехода будет сильно не нулевой. Даже в плане переучивания. Не говоря уже про поддержание и развитие кодовых баз, которые уже написаны.

Вы же, как баран, твердите одно: C++ не современен, не безопасен. Ну и неудобен для вас лично.

Так успокойтесь, с этими вашими убеждениями никто не спорит. Речь не о ваших убеждениях и заблуждениях. А о том, например, почему опытные C++ники не торопятся в Rust. А торопятся туда те, кто либо с C++ не связан, либо знает C++ на вашем или еще худшем уровне.

Уж не знаю, как донести до вас это еще понятнее и подробнее.

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

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

Какие? Вариадики?

либо знает C++ на вашем или еще худшем уровне.

Так о чём и речь. Может кто-то скрывает от меня невероятные фичи современного C++. Вот я и пытаюсь их найти.

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

Какие?

См.выше. Только перед этим свое самомнение и убежденность в том, что вы точно знаете о чем идет речь, лучше засунуть куда подальше.

Вот я и пытаюсь их найти.

Вы не сможете. Проверено временем.

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

Для локализации. Ваш КО. 100% unsafe или 5%. Выбор за вами.

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

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

И здесь то и выходит на первый план вопрос - а зачем платить больше, если результат тот же? И на фоне ответа на этот вопрос становиться очевидным, что Rust есть смысл применять только, если нет зависимостей от библиотек на других языках. В противном случае вы не можете гарантировать безопасность на том уровне, на котором она декларируется создателями языка. Чудес не бывает.

Вы лично сколько биндингов написали?

Благодаря тому, что D поддерживает линковку с сишечкой на 100% из коробки и в значительной степени плюсовый ABI, включая шаблоны, написание биндингов на D к сишному коду тривиальная вещь. Там по факту и писать нечего. К плюсовому коду биндингу посложнее и там уже врапперы скорее всего понадобятся. Так что с этой точки зрения я вообще не вижу сложностей по написанию дишных биндингов к сишному коду. Ну тривиальщина же:

// сишный код

int foo(int i, char* ptr);

typedef struct Bar
{
    float f;
    long  l;
} Bar;
vs
// дишный код

extern (C):
int foo(int i, char* ptr) nothrow @nogc;

struct Bar
{
    float f;
    long  l;
}
Убрали typedef ибо лишний и добавили линковку с сишным ABI и атрибуты, что функция не выбрасывает исключения и не использует сборщик мусора. Все.

И я писал эти биндинги ни раз и не два. Более того, что касается сишного кода - зачастую его портировать на D не намного сложнее чем сделать биндинги. Ибо код очень близок. К тому же есть dstep и dpp, которые биндинги могут сгенерировать за вас.

В общем для меня как для дишника вообще непонятно, как можно иметь какие-то мало мальские проблемы с биндингами к сишной библиотеке. К плюсовой еще ладно, но к сишной - я не понимаю.

Смысл строго противоположный.

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

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

Из вашей тупости вовсе не следует, что я д'Артаньян.

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

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

Для таких простейших случаев и в rust будет также практически, и есть даже авто генерация https://github.com/rust-lang/rust-bindgen но как показывает топик для сложных случаев этого недостаточно, по моему и в D будут похожие проблемы.

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

В жертву этому принесено многое - синтаксис

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

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

Так какой там может быть сложный случай с сишным кодом, я не пойму? Пока самый сложный что мне пришел на ум - указатель на функцию. Пожалуйста:

typedef void *fooBar (void *ud, void *ptr, size_t nsize, size_t osize);
vs
alias fooBar = void* function (void *ud, void *ptr, size_t nsize, size_t osize);
Как говорится, найдите n отличий.

Использование сишного кода из дишного это тривиальщина чистой воды. Никаких проблем там нет от слова совсем. И все сложные случаи D поддерживает на 100%. Если нет - это баг. Слова автора языка, Уолтера Брайта, автора компиляторов для С/С++.

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

Следи за пальцем:

char foo() {
    long i = 0xFF00000000000000;
    return {i};
}

int main()
{
    return foo();
}

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

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

Вкусовщина чистой воды. Разве что мне не нравится, что `*`, например, при объявлении переменной относится к переменной, а не к типу. Когда одна переменная это разницы не имеет, а когда несколько уже имеется. Но это опять же мне так нравится. Абстрактно, что в Rust, что в C++ объявления содержат только необходимую информацию и ничего лишнего. И да, по вкусовщине - по мне так у Rust просто вырвиглазный синтаксис. Понамешали всего в кучу. Но это субъективщина.

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

только ООП и вариадики. Но это не делает C++ удобным, современным и безопасным

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

anonymous
()

Итого

Rust таки говно. Но не в плане синтаксиса/сложности/etc. Слабым местом оказалось отсутствие обратной совместимости. С сишкой. Ещё одно подтверждение отличного дизайна c++

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

Это не указатель на функцию.

Точно, забыл исправить. В коде используется как `fooBar*` вот я и лажанул. Здесь определение функции объявляется как тип данных. Как правильно это сказать - не знаю.

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

Да и модули многого стоят - где на D один файл `foo.d`, на плюсах три - `foo.h`, `foo_fwd.h` и `foo.cpp`.

Как это в сравнении с модулями Turbo Pascal (Delphi, Free Pascal)? Похоже или нет? Допустим, откомпилировал модуль в бинарный файл и больше не нужны исходники — доступно бинарное связывание кода из откомпилированных модулей?

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