Продемонстрирована возможность разработки частей Linux на Rust

Эм, что еще можно написать про паникующую обертку с вызовом функции и анврапом? Объясните холопу, я чего-то сильно не понимаю.

Эм, что еще можно написать про паникующую обертку с вызовом функции и анврапом?

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

Я хз как отловить сегфолт.

По степени убежденности в наличии серебряной пули Rust-оманы соперничают разве что с Lisp-ерами и Oberon-щиками :)

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

У раста просто много приверженцев, которые писать на нём в достаточном объёме (на работе, в смысле) не могут, поэтому и шишки не набили и восторг пройти не успел.

Да, поэтому они во всем правы, а консерваторы, которые не имеют проблем со своими мейнстримными инструментами, — нет. Особенно это четко выражается, когда какой-нибудь RazrFalcon начинает в сторону того же C++ какашками бросаться и выясняется, что он-то C++ нормально и не знает.

SEH я так понимаю, что только через асм можно использовать?

и да, любое описание типов нагружает восприятие (и его следует продумать), но все равно в плюсах это сделано ужасно (а в расте еще хуже)

Так можно пример как правильно типы указывать? Ну и указание типов (аргументов функций) «как в расте» во многих новых языках используется и на то есть причины.

Да, поэтому они во всем правы, а консерваторы, которые не имеют проблем со своими мейнстримными инструментами, — нет.

Этого я не говорил.

Но «не иметь проблем с мейнстримными инструментами» и «ничего слаще редьки не пробовать» - вещи разные. Разумеется, это относится не ко всем сторонникам «мейнстримных инструментов».

Системный язык с динамической типизацией? Ну-ну.

Можно ещё тотальный вывод типов сделать. (:

Но «не иметь проблем с мейнстримными инструментами» и «ничего слаще редьки не пробовать» - вещи разные.

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

Я тут сильно не соглашусь. Как сказал Алан Перлис: «язык, который не меняет стиля мышления, не заслуживает внимания».

он не прав (по крайней мере в таком переводе); можно было бы сказать «язык с другой парадигмой может заслуживать внимания», как-то так

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

это другой инструмент с другим scope и заменить vtable он не может

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

короче: изучать новые парадигмы вижу смысл, менять старые — не вижу

а да, еще у хаскеля есть редукция графа вместо общепринятых eager вычислений — это обобщение eager вычислений, так что парадигма опять расширяется, а не меняется

Сразу после Go, JS, и лиспа с хаскелем.

Не льстите себе. Lisp-еры и Oberon-щики, действительно, будут поупоротее. Но всем остальным до вас еще далеко. Особенно в вашем лице.

Что там с SEH уже подзабыл, а для VEH есть нормальное API https://github.com/red75prime/dxgen/blob/master/src/scaffolding/src/seh.rs

в сишке структуры нулевой длины запрещены.

В курсе, выше даже где-то уточнял. Но вообще есть расширение на эту тему, но как (и зачем) с ним живут - не в курсе.

А, вспомнил. Для seh тоже есть нормальный api. Статьи, где упоминаются сегментные регистры -старьё

Дык, если Rust претендует на нишу C, то должна же быть какая-то понятная мотивация для C-шника.

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

Отсюда желание понять: в чем смысл данных с нулевым размером?

В каких-то местах это может сэкономить память.

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

Как будто это единственная (и самая большая) сложность.

У меня нет железных аргументов за тот или другой вариант реализации «пустых» типов данных. Какие неудобства будут вылезать чаще (мне) сложно сказать, но критических проблем не вижу. Можно поискать были ли обсуждения в контексте раста, но (пока) лень.

Сказал человек с синдромом утёнка и стокгольмским синдромом.

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

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

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

Можно поискать были ли обсуждения в контексте раста, но (пока) лень.

Ну нужно. Я понимаю, что у Rust-оделов была какая-то своя мотивация, но даже если я сам ее не разделяю, то это ничего не меняет. Ну вот так в Rust-е, ну OK, еще одна особенность.

Lisp-еры и Oberon-щики, действительно, будут поупоротее.

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

плюс к тому есть scheme/racket, который я нифига не знаю, и в котором строят статически типизированный язык поверх динамически типизированного, но по-моему это неверный путь, надо действовать наоборот

Панику уже можно перехватывать на внешней границе функции, реализующей алгоритм?

Можно.

О, спасиб!

Я помню, что об этой фиче говорили, но, видимо, пропустил ее появление.

Спасибо

Если при этом нужно будет перестроить мозги, ну значит нужно будет перестроить. Чтобы затем писать на Rust-е, как на Rust-е, а не как на Java или на C++.

почему я еще против «перестройки мозгов» — по той причине, что язык должен отражать стиль и уровень современного научного мышления, а не проблематику отдельно gc или отдельно borrow checker-а, скажем

и поэтому попытки языковой тусовки внушить, что у языка есть некий Стиль Мышления для меня выглядят в лучшем случае смешно — там есть только инструменты, которыми пользоваться удобно, можно, сложно, или невозможно

Да, Вася получит от Фединой библиотеки код ошибки, может быть сделает какой-то откат операции у себя, но продолжит работу далее нормально. Вместо краха и рестарта.

В общем случае Вася может испортить что-то у тебя в адресном пространстве и без рестарта не обойтись.

В общем случае Вася может испортить что-то у тебя в адресном пространстве

Мы все еще про Rust или уже про C++?

Поэтому в C++, если работа с исключениями разрешена, нет такой дилеммы как выбор между возвращаемым значением и исключением: контракт нарушен — исключение.

Тоже варианты имеются. Hапример, асерты.

Hапример, асерты.

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

А если assert-ы продолжают работать в Release-сборках, то это уже один из элементов defensive programming.

В общем случае Вася может испортить что-то у тебя в адресном пространстве и без рестарта не обойтись.

вот о чем я тут бы хотел наверно поговорить — так это об уровнях гарантий (тема всплыла еще в разговоре с mersinvald)

вот, скажем, в плюсах UB это все что угодно

если бы в расте не были бы так робки и сделали попытку как-то гарантированно ограничить вред от unsafe функции какой-то областью адресов например, то это была бы интересная альтернатива доказательству их правильности

И Rust-оманы как раз по степени веры в серебряную пулю явно на лидирующих местах.

Ну что я могу сказать? Может последствия того, что язык молодой, а может стоит пообщаться за пределами лора.

и да, любое описание типов нагружает восприятие (и его следует продумать), но все равно в плюсах это сделано ужасно (а в расте еще хуже)

Так можно пример как правильно типы указывать?

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

Ну и указание типов (аргументов функций) «как в расте» во многих новых языках используется и на то есть причины.

ты про что конкретно?

Мы все еще про Rust или уже про C++?

А без разницы. Наломать дров и в расте можно.

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

Наломать дров и в расте можно.

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

как-то гарантированно ограничить вред от unsafe функции какой-то областью адресов например, то это была бы интересная альтернатива доказательству их правильности

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

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

Критиковать не предлагая альтернативу слишком легко. (:

Не полностью продуманный вариант тоже интересен.

ты про что конкретно?

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

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

Тогда за них можно только порадоваться. (:

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

«язык, который не меняет стиля мышления, не заслуживает внимания».

а вот еще что заслуживает внимание — это архитектура эльбруса, но это уже больше из области железа, так как софтово ее сложно дешево эмулировать... вроде бы

и из мелочей — мелкие объекты objective-c (которые внутри одного слова или двойного слова)

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

да; поэтому типы аргументов функции имеет смысл указывать отдельно, например

f(x,y) = int { x = int(?); y = int(2);
    u = "asdf";
    v = 100;
    return v+length(u)+x+y;
}

и конечно не обязательно именно в таком синтаксисе

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

Если мы говорим про C/C++, то там assert-ы до компилятора не доходят вообще, а изымаются на стадии препроцессинга.

архитектура эльбруса

И Эль-76. Вот уж там синтаксис - так синтаксис. Помнится, меня чем-то поразило разыменование опционального типа или что-то в этом роде. Надо будет раскопать книжку, поискать.

видел на просторах интернета 2 или 3 отсканненые книжки

одна из них есть у меня вживую, там небольшая часть очень интересна, а остальное просто ужасно

да; поэтому типы аргументов функции имеет смысл указывать отдельно, например

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

от повторений должно спасать ide (и даже примитивные редакторы могут ускорить ввод идентификатора), а параметров будет много (точнее, описаний параметров у приличного языка будет *очень* много, их просто не поместить внутри списка аргументов функции, даже если портить человеку зрение кавычками и однобуквенными обозначениями типа 'a)

кстати, в этом треде я стал подумывать о кодогенерации из приличного синтаксиса в раст; вполне возможно, особенно учитывая удобство трейтов (и ненужность смены парадигмы для них, гы-гы); вот только обсуждение проблем с объектами нулевой длины меня как-то насторожило — сыроват язык еще

любое описание типов нагружает восприятие

Зато упрощает разработку и уменьшает время втыкания в документацию

тяжелый чемодан нагружает человека, но, что важно, существенно по-разному нагружает когда он его несет в руках и когда везет на тележке

так и с описанием типов

Так приходится повторяться,

когда в жабке пишут public static final Борщ борщ = new Борщ() то тут повторение идиотское, так как все рядом

когда же повторение является выжимкой из бОльшего текста, то оно разумно, как, скажем, .hxx является выжимкой из файла .cxx при условии, что функции у нас не однострочные

другое дело, что ide должно помогать

Ибо раст позволяет иметь только одну мутабельную ссылку на объект

нихрена у вас там спарта.

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

ассерты там идут в дебаг. вообще-то.

Речь про релизные сборки, в которых NDEBUG и традиционный assert в этих случаях разворачивается в пустой макрос.