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

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

Что за херня. Почему у меня так же один файл?

Что за херня. Почему у меня так же один файл?

Для hello world одного файла достаточно.

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

Аккуратист-перфекционист, значит.

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

Язык — всего лишь средство выражения мыслей по поводу чего-то. Если язык не внятен, заумный или многословен, то он малоинтересен другим людям.

В язык D, например, встроена концепция модульного тестирования со всеми сопутствующими атрибутами контрактного программирования. Так что можно начинать писать код с тестов, постепенно обретая работающее основание идеи, мысли, выраженные в коде. А затем это развивается в самотестируемую законченную функциональную сущность.

Так что можно начинать писать код с тестов

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

use libc::{c_void, size_t};
type Foobar = Option<extern fn(*mut c_void, *mut c_void, size_t, size_t)>;

И?

Кстати, как на C или C++ будет

use libc::{c_void, size_t};
type Foobar = extern fn(*mut c_void, *mut c_void, size_t, size_t);

?

Rust гарантирует безопасность на действительно высоком уровне.

https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html

Safe Rust is the true Rust programming language. If all you do is write Safe Rust, you will never have to worry about type-safety or memory-safety. You will never endure a dangling pointer, a use-after-free, or any other kind of Undefined Behavior.

Просто не нужно выдумывать себе свой раст, которого нет.

В жертву этому принесено многое - синтаксис, время компиляции, учет времени жизни и пр.

Время компиляции там не из-за лайфтаймов медленное. C++ такой же медленный.

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

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

И здесь то и выходит на первый план вопрос - а зачем платить больше, если результат тот же?

Rust - это не только безопасность. Rust - это современный язык с множеством плюшек. Ну и cargo, куда же без него. Тут адепты плюсов сразу начнут рассказывать про мифический «современный С++», но до конкретики дело редко доходит, что и было проиллюстрировано выше.

Если вы думаете, что Rust - это просто Сишка, которая бьет по рукам за неверное использование указателей - то советую изучить азы языка.

Ну тривиальщина же

Ну то есть не писали. Всё понятно. Для справки, код на Rust:

extern "C" fn foo(i: i32, ptr: *mut u8) -> i32;

#[repr(C)]
struct Bar {
    f: f32,
    l: i64,
}

но к сишной - я не понимаю

А вот ТС понимает.

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

Ровно на оборот. Ибо я могу не беспокоиться о куче проблем.

А потом вдруг внезапно

Ну то есть я не в курсе что за либу я добавляют? ЗСБ.

А платить за него вы продолжаете временем компиляции

Опять время компиляции? Вы на первопне собираете?

строгостью компилятора

Вкусовщина. Для меня строгость компилятора - это благо.

и т.д.

И т.д. что? Не нужно быть таким загадочным.

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

Потому что использование unsafe стирает различия между Rust и С++ в плане безопасности

а этому утверждению противоречит наличие safe

И?

И, выглядит как говно. Я не вижу удобства. Я вижу лишний мусор + ворованный using из крестов.

type Foobar = extern fn(*mut c_void, *mut c_void, size_t, size_t);

Что именно будет? Как будет функция - там выше было показано. void(void *, void *, size_t, size_t) - так.

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

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

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

у тебя какое-то бинарное мышление

Что именно будет?

Как будет выглядеть non-nullable указатель на функцию?

Понимаешь, в чем фишка - есть два типа продуктов: «коробочные решения» и «энтерпрайз». Черта последнего - люди всегда рядом и подкрутить что-либо - не проблема. В первом случае качество выше - не вспоминается сходу проектов(не в версии 0.x), страдающих хреновой инфраструктурой. Всё это - мелочи на фоне основной работы(написания, собственно, production-кода и правильного покрытия этого кода тестами)

Не проверял, но по идее:

typedef void *fooBar (void *ud, void *ptr, size_t nsize, size_t osize);
not_null<fooBar> = funcname;

Ты затралить решил, или серьёзно не понимаешь, что это ерунда?

Rust пытается создать идеальный мир. Похвальное стремление. Но кроме Rust в этом мире больше никого нет.

Ещё есть Haskell, но там в другую сторону выверт.

Тоже отпишусь по этому поводу, не удержался)

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

Любой safe язык опирается работу с системным нативным кодом, иначе он просто ничего не сможет сделать, ни файл прочитать, ни в сеть сходить. И все виртуальные машины весьма эффектно взрываются, при ошибках в работе с памятью в нативном коде. Например ваше счастье, если JVM при вызове кривой JNI функции просто упадет с сегфаультом. На практике же это частенько приводит к неявному повреждению данных например в хипе. Если побились объекты, ну будет вылет (когда-то, например когда gc налетит на херь в хипе). А может произойти так, что вы умудритесь попасть в зону атрибутов например и просто переписать какие-то живые данные, которые потом будут считаны вашим кодом как валидные. Так что по такой логике полностью safe языков вообще теоретически существовать не может. Он могут быть более или менее safe, но никогда полностью.

Но справедливости ради, создать утечку в safe rust можно только двумя способами: циклические ссылки и forget. То есть шанс нарваться на подобную проблему катастрофически мал.

Как мне автоматически проверить используется ли в основном коде и коде зависимостей эти две фичи? К примеру, можно взять resvg.

А как быть с проверкой зависимостей на unsafe?

Возможности – это, например:

...

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

К примеру, можно взять resvg.

В resvg (точнее в svgdom) есть циклические ссылки. Но так же есть и тесты на утечки и доп. костыли. Иначе нормальное API для работы с деревом не сделать. Тут нужен GC.

А как быть с проверкой зависимостей на unsafe?

cargo geiger, grep

Не видел, чтобы кто-то использовал mem::forget... Разве что в биндингах.

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

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

• про контроль в compile-time за вызовом нужных методов;
• про policy-based design (и еще одна на похожую тему);
• про то, как шаблонами можно определять имеющуюся функциональность.

Про декларативное определение пайплайнов на шаблонах статья сейчас в работе. В течении недели должна появится, надеюсь.

Собственно, там в статьях и ссылки можно найти.

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

В resvg (точнее в svgdom) есть циклические ссылки.

А в зависимостях, ведь иначе предоставляя пользователю свой safe код (даже с тестами), на самом деле нет гарантии, что не будет утечек. Нужна автоматическая проверка.

Не видел, чтобы кто-то использовал mem::forget... Разве что в биндингах.

В контексте rust слышу часто «гарантии». Т.е. необходима автоматическая проверка, чтобы или исключить или предупредить, что возможны утечки.

на самом деле нет гарантии, что не будет утечек

Ещё раз: раст не гарантирует отсутствия утечек. resvg вообще сишные либы дёргает. Так что тут вообще всё сложно.

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

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

А вообще покусанных Александреску в мире C++ много.

Вопрос, пускают ли их к созданию вышеописанного кода на C++ (Вот D у него получился, да).

герантофил

фрактал

Вопрос, пускают ли их к созданию вышеописанного кода на C++

Нет, конечно. Как можно. Никто же потом в таком коде не разберется :)

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

Ты затралить решил, или серьёзно не понимаешь, что это ерунда?

Пиши issue на https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#...

Вот кстати, запустил твой пример:

char foo() {
/*(1)*/    long i = 0xFF00000000000000;
/*(2)*/    return i;
}

int main()
{
    return foo();
}

(1): warning C4310: приведение обуславливает усечение постоянного значения
(2): warning C4244: return: преобразование "long" в "char", возможна потеря данных

И как уже рассказал аноним в этом посте: Автор Wayland композитора Way Cooler переписывает своё детище с Rust на C (комментарий)

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

int main()
{
    return foo();
}

(1): error C2397: преобразование из "long" в "char" требует сужающего преобразования

Знатно набросил. За такое надо премию выдавать.

Ну да, ржавый он как рак.

Есть такие, которые гарантирую отсутствие use-after-move?

Гарантировать не могут. А вот бить по рукам учатся:

https://clang.llvm.org/extra/clang-tidy/checks/bugprone-use-after-move.html

Это еще и к вопросу о полной бесполезности стат.анализаторов для C++.

Вот это поворот!

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

move решается помечанием источника как «uninitialized» чтоб ниже по коду он давал ворнинг.

move решается помечанием источника как «uninitialized» чтоб ниже по коду он давал ворнинг.

А можно пример того, как это выглядит в коде?

в генте на firefox-bin. Да, у меня теперь в нем нет звука

даже при использовании apulse?

Даже при использовании apulse. Хотя скайп с апульсой работал.

Спасибо за демонстрацию удобства C-стиля объявления типов.

Это сарказм)?

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

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

тип-функция. Кстати, 95% птушников не знают о существовании такого. Как и decay. Радует, что хотя-бы адекватные люди есть.

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

Что за херня. Почему у меня так же один файл?

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

Safe Rust is the true Rust programming language. If all you do is write Safe Rust, you will never have to worry about type-safety or memory-safety. You will never endure a dangling pointer, a use-after-free, or any other kind of Undefined Behavior.

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

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

Время компиляции там не из-за лайфтаймов медленное. C++ такой же медленный.

Медленный, да не такой же. Или borrow-checker в Rust бесплатным стал?

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

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

Rust - это современный язык с множеством плюшек. Ну и cargo, куда же без него.

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

Ну то есть не писали. Всё понятно.

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

А вот ТС понимает.

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

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

Ровно на оборот. Ибо я могу не беспокоиться о куче проблем.

Ровно наоборот в вашем утверждении означает, что компилятор тратит ваше время и усилия чтобы НЕ дать гарантии? Звучит немного бредово. И поверьте мне, компиляторы других языков тоже позволяют не беспокоиться о куче проблем. Это тоже не аргумент.

Ну то есть я не в курсе что за либу я добавляют? ЗСБ.

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

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

Опять время компиляции? Вы на первопне собираете?

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

Вкусовщина. Для меня строгость компилятора - это благо.

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

а этому утверждению противоречит наличие safe

Зачем вы ерунду пишете?

у тебя какое-то бинарное мышление

Ну действительно же ерунду пишите

Ещё есть Haskell, но там в другую сторону выверт.

Хаскель для меня зверь загадочный. Ничего сказать не могу)

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

Вот кстати, запустил твой пример:

Как это противоречит моим словам?

Чтобы на разводить полемику, а то я слишком много времени последние два дня здесь провожу, я еще повторю свой тезис - си и плюсы позволяют вернуть long из функции с типом возвращаемого значения char. Точка.

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

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

Ну не скажите, тут все зависит от того как писать. Я вот пишу на акторах и при таком подходе практически нет этой преcловутой «цены», поскольку все вопросы контроля времени жизни забирает на себя фреймворк. При таком подходе, код на расте, мало чем отличается от кода на той же скале. И это позволяет раскрутить раст на полную по части веб-программирования. Преимущества которые дает раст в микросервисах сложно переоценить - скорость, очень аккуратное потребление памяти и бинарники без тысяч внешних зависимостей. Плюс на данный момент инфраструктура покрывает по сути любое пожелание из это сферы - http1/2, grpс, коннекторы к практически любым базам данных и брокерам сообщений. Маршализация реализуемая набором serde лучшая что я где либо видел, ближайший конкурент наверное только spray. Вот например код актора - тык.

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

Это вот все примеры реального кода на расте. Как видите в нем нет никаких ужасов и той страшной цены о которой все говорят.

Ну если вы используете фреймворк, то это именно использование фреймворка, а не языка. Тут у плюсов например, есть мощнейший аргумент в виде Qt. Вы сейчас по факту говорите о экосистеме. И у раста она заметно хуже чем у си или плюсов. Тем более вы портируете сишный код. В общем это, на мой взгляд, некорректная метрика. Мне вот вообще не очевидно чем растовый парсер лучше сишного? Какую задачу вы достигли переписав его на Rust? Я подозреваю, что вы его переписали на Rust просто потому что в таком виде код удобнее использовать в экосистеме Rust и все.

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

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

Только в конкретном участке кода.

Медленный, да не такой же.

Пруфца бы.

Или borrow-checker в Rust бесплатным стал?

Он и был бесплатным.

Да ладно? А то не хватает сейчас современных языков с плюшками что ли? Да их немеряно.

Перечислите современные языки без GC.

Вы передергиваете очевидные вещи.

Если бы писали, знали бы, что ваш пример - это только верхушка айсберга.

Потому что интеграция с сишным кодом в Rust намного хуже чем в D

Есть какой-либо пример где Rust хуже?

Звучит немного бредово.

Только потому, что вы сравниваете свой любимый D с каким-то вымышленным Rust. В реальном расте всё по-другому.

Изначально вы этого не планировали.

То есть при добавлении новой зависимости я в принципе не представляю что она делает? Чушь же.

У Rust еще хуже с этим.

Пример бы.

Тем более вы портируете сишный код.

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

Мне вот вообще не очевидно чем растовый парсер лучше сишного? Какую задачу вы достигли переписав его на Rust?

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

Тут у плюсов например, есть мощнейший аргумент в виде Qt

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

Вы сейчас по факту говорите о экосистеме.

Опять же, о какой экосистемы мы сейчас говорим? Моя основная сфера это веб-разработка. В этой сфере я не наблюдаю дефицита экосистемы. Любой мой чих в этой области был полностью удовлетворен. Единственное что я сделал тут сам, это написал нормальный акторный фреймворк, так как уж больно странные реализации данной технологии имеют место быть.

Тем более вы портируете сишный код.

Доп. Потом он перекочевал на jni, а с jni в еще один другой драйвер почти в неизменном виде. Это код как раз из jni парсера.