Состоялся (https://blog.rust-lang.org/2018/02/15/Rust-1.24.html) релиз языка программирования Rust 1.24 (http://www.rust-lang.org), развиваемого проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime.
По структуре язык Rust напоминает C++, но существенно отличается в некоторых деталях реализации синтаксиса и семантики. Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек поддерживается репозиторий crates.io (https://crates.io/).
В подготовке нового выпуска приняли участие 152 разработчика. Основные новшества (https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...):
- Реализована утилита rustfmt (https://github.com/rust-lang-nursery/rustfmt) для автоматического формирования исходных текстов в соответствии с рекомендациями (https://github.com/rust-lang-nursery/fmt-rfcs) по оформлению кода на языке Rust. Для установки утилиты следует использовать команду "rustup component add rustfmt-preview";- Включена по умолчанию инкрементальная компиляция, позволяющая пересобирать только изменившиеся части кода. Данный режим позволяет значительно сократить время сборки проекта при повторной компиляции после внесения мелких правок. Кроме того, в новом выпуске параметр codegen-units по умолчанию увеличен до 16, что позволило существенно (https://github.com/rust-lang/rust/issues/45320) ускорить процесс сборки за счёт распараллеливания операций, ценой незначительного снижения производительности результирующего исполняемого файла (для обеспечения максимальной производительности можно указать codegen-units=1);
- Устранено неопределённое поведение обработчиков краха в контексте функций FFI (https://doc.rust-lang.org/book/first-edition/ffi.html) (Foreign Function Interface), работа которых могла отличаться в зависимости от ABI. Например, до сих пор оставался непредсказуемым код на базе "C" ABI:
extern "C" fn panic_in_ffi() {
panic!("Test");
}В Rust 1.24 такой код теперь всегда приводит к прерыванию выполнения, вместо неопределённого поведения;
- До 10 раз ускорено выполнение операции поиска символов внутри строки при помощи функции str::find, которая переписана с использованием memchr. На memchr также переведена реализация [u8]::contains, но ускорение её работы не столь внушительно (ускорение примерно в 3 раза). С использованием ассемблерных инструкций проведена оптимизация f32::min и f32::max;
- В разряд стабильных переведена новая порция API, в том числе RefCell::replace, RefCell::swap и std::sync::atomic::spin_loop_hint;- Обеспечена возможность использования внутри неизменных выражений (constant, static) функций Cell, RefCell, UnsafeCell, {integer}::min_value, max_value, mem’s size_of, align_of, ptr::null, null_mut, а также функции работы с различными целыми типами Atomic (AtomicBool::new, AtomicPtr::new, AtomicIsize::new и т.п.). Например, теперь можно указать "static COUNTER: AtomicUsize = AtomicUsize::new(1);"
- Добавлена поддержка новых целевых платформ armv4t-unknown-linux-gnueabi и aarch64-unknown-openbsd.URL: https://blog.rust-lang.org/2018/02/15/Rust-1.24.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=48087
Как оно по сравнению с Vala ?
Что такое Vala? Вы откуда к нам приехали? У нас только го, раст, питон, си, ява и тп.
В Solus Linux используют Vala, Go, C.
Ясно откуда, из GNOME, конечно же
Гибкий, быстрый, строгий. Пожалуй самый строгий из императивных языков программирования. При это присутствует возможность построения абстракций (~нулевой стоимости) практически любой сложности, но ради справедливости стоит отметить, что не любой. Например HKT ещё не завезли и не факт что вообще завезут.
> Пожалуй самый строгий из императивных языков программированияТы забыл добавить самое важное ", которые я знаю".
Например go более строгий.
Ага, строгость уровня interface{} и передачи в горутины не thread-safety типов.
Гагага, есть наблюдательные. У нас строго типизированный язык, но мы тут сделаем хак... оп, и у нас interface{} по функциям гуляет
Смысл строгой типизации не в том, чтобы не дать программисту возможности сделать желаемое, а в том, чтобы не дать ему случайно сделать то, чего он не хотел. Использование interface{} это явный выбор программиста, а вот преобразования типов компилятором в выражениях без соответсвующего прямого указания это неявное действие.
Ну и отдельно отмечу, что interface{} это совсем не синоним произвольного типа. Без _явного_ преобразования в конкретный тип единственное, что можно с таким объектом сделать, это сохранить и передать куда-либо еще. К примеру такой код работать не будет:
func add ( a,b interface{} ) interface{} {
return a+b
}
> не в том, чтобы не дать программисту возможности сделать желаемое, а в том, чтобы не дать ему случайно сделать то, чего он не хотелвсё так.
> Ну и отдельно отмечу, что interface{} это совсем не синоним произвольного типа.
Да.
> Без _явного_ преобразования в конкретный тип единственное, что можно с таким объектом сделать, это сохранить и передать куда-либо еще.
Да вот
func some(a interface{}) {
b := a.(MyType)
}при некотором стечении обстоятельств упадёт только в рантайме.
Но тут да, первое снова верно:
> не в том, чтобы не дать программисту возможности сделать желаемое, а в том, чтобы не дать ему случайно сделать то, чего он не хотел"Если очень хочется, то пожалуйста, мочи". В go, однако, эти interface{} на каждом шагу расплодились
> Да вот
> func some(a interface{}) {
> b := a.(MyType)
> }
> при некотором стечении обстоятельств упадёт только в рантайме.Конечно. Потому оно и называется type assertion, а не type cast. У него есть вторая форма, которая позволяет проверить, действительно ли переменная этого типа:
b,ok:=a.(MyType)
В случае если "a" окажется другого типа, то в "ok" будет false, а переменная "b" будет инициализированна нулевым значением типа MyType. И никакой паники в рантайме.
Да вот беда, вот вам пример:
http://mobile.opennet.ru/opennews/art.shtml?num=48096#30
А вот вопрос: interface{} можно ли считать более безопасным аналогом указателя на void?)
В общем-то да. Интерфейсная переменная в go являет собой структуру из двух полей, первое является указателем на структуру, описывающую тип текущего хранимого значения, второе является как раз указателем на void.
У вас это у кого? Леммингов?
Elementary OS - https://ru.wikipedia.org/wiki/Elementary_OS (7-ой в списке https://distrowatch.com)
Большая часть окружения написана на языке Vala, что позволяет достигнуть производительности, сравнимой с языком C.
> Большая часть окружения написана на языке Vala, что позволяет достигнуть производительности,
> сравнимой с языком C.А гнум написман прямо на С, что не мешает ему безбожно тормозить. Что сказать то хотел?
>> Большая часть окружения написана на языке Vala, что позволяет достигнуть производительности,
>> сравнимой с языком C.
> А гнум написман прямо на С, что не мешает ему безбожно тормозить.
> Что сказать то хотел?Только то, что это не такой уж и неизвестный язык программирования, раз целая DE и разный софт под неё на Vala написаны, причём на дистрибутиве не из редких.
> А гнум написман прямо на С, что не мешает ему безбожно тормозить.Когда он был написан на C и Vala, он не тормозил. Тормозить стал, когда хипстота напихала туда JS.
> Elementary OS - https://ru.wikipedia.org/wiki/Elementary_OS (7-ой в списке https://distrowatch.com)
> Большая часть окружения написана на языке Vala, что позволяет достигнуть производительности, сравнимой с языком C.Транслирование в сишку не дает автоматически сишной скорости. Да и завязка на GTK и glib слишком сильна. Нишевой ЯП, в общем.
Валя - это транспайлер урезанной старой версии C# в C. В целом достаточно приятная и полезная штука.
только коммерческие проекты на ней писать нельзя так как она гном библиотеки линкует by design.
Под desktop легко, там LGPL как в Qt. Но если конечно же, кто-то сделал независимую реализацию GLib/GObject под zLib/MIT/Boost/BSD тогда внимания Vala приобрела намного больше. Чудесный язык, но перешел на сторону D с C++, доволен, особенно после того как добрали interop с C++ (что не мало важно, есть много хороших вещей на нем, а изобретать велосипед не охота).
И да, GNOME & GTK там не обязательны, только GLib/GObject.
> Что такое Vala? Вы откуда к нам приехали? У нас только го,
> раст, питон, си, ява и тп.Си у вас нету, не пользуются хипстеры сями.
Это стиральный порошок?
Подобно Objective-C но для GTK
Vala это обертка над Си да еще и заточенная исключительно на GTK.
Гораздо интереснее сравнение с Go. При том что тут нет сборщиков мусора и т.п, но есть защита по работе с памятью. К сожалению ощущение что кроме как внутри Мозилы его никто серьезно не пользует. То ли есть объективные недостатки, то ли просто не пробовали не ясно.
Объективный недостаток - Rust слишком не похож на мейнстримные языки. Соответственно подавляющая масса программистов чтобы вкатиться должна потратить много времени и усилий, многие просто бросят это дело в самом начале, скажут, мол язык фекалия с инопланетными синтаксисом и/или семантикой и пойдут дальше кодить на Java/C/C++/C#/Go/JavaScript/Python.
Вот только не надо. У го тоже вполне инопланетный синтаксис как бы его не называли C-подобным, а многое вообще схоже с растом.
У Go вполне читабельный и понятный синтаксис. А главное, - он примитивный. Есть, конечно, бредовые моменты, как например, методы с большой буквы, или массивы с квадратными скобками впереди. Но в целом, идеи интересные.
> Есть, конечно, бредовые моменты, как например, методы с большой буквыБольшая и маленькая буква в начале _любого_ идентификатора никак не связана с методами, это гениальный в своей простоте индикатор экспортируемости. Так что приватные методы можно без проблем начинать с маленьких букв.
Любой язык, который навязывает оформление кода (в т.ч. и выбор имен) - broken by design.
> Любой язык, который навязывает оформление кода (в т.ч. и выбор имен) - broken by design.В смысле, заставляет расставлять везде скобочки и ;, не разрешает начинать имена с цифр или того же $, не дает на практике (т.к. implementation defined) использовать кириллицу?
Нет. Любое утверждение можно довести до абсурда. Но когда программа ломается и меняет поведение в зависимости от того, какой пробел ты поставил или с какой буквы начал имя метода, то что-то неладно в королевстве датском.Начинать имена с цифр или спец-символов, а также использовать национальные символы в именах - однозначное зло, и очень хорошо, что в разумных языках это запрещено или как минимум не приветствуется. Хотите конопатиться с умляутами, китайскими иероглифами или каким-нибудь ивритом? Нет уж, спасибо.
> Но когда программа ломается и меняет поведение в зависимости от того, какой пробел ты поставил
> Нет. Любое утверждение можно довести до абсурда.this
Ведь если заменить "пробелы" на "скобочки" (довольно частая категория ошибок кстати, см. знаменитый goto fail), то смысл почему-то останется тот же.Просто пробелы используются не только как банальный разделитель между идентификаторами, ключевыми словами и прочим. Это позволяет выкинуть бесконечные лесенки скобочек, не теряя в читаемости.
> с какой буквы начал имя метода, то что-то неладно в королевстве датском.
Пролог, фортран ... не, не слышали? Ну ладно фортран, но мне интересно, как в прологе будет выглядеть альтернативное, компактное и элегантное решение решение, заменяющее Myvar|myatom.
> Начинать имена с цифр или спец-символов, а также использовать национальные символы в
> именах - однозначное зло, и очень хорошо, что в разумных языках это запрещено или как минимум не приветствуется. Хотите конопатиться с умляутами, китайскими иероглифами или каким-нибудь ивритом? Нет уж, спасибо.А как же "свобода оформления кода", "ненавязывание имен" и прочее, что обычно приводится в качестве аргумента?
Тем более, "навязывание" пробелов заменяет кучу скобочек, практически ничего не требуя взамен (помому что читаемый формат кода - что-то само собой разумеющееся).
А вот запрет на спецсимволы - просто запрет, потому что "разумно". Двойные стандарты?
> Ведь если заменить "пробелы" на "скобочки" (довольно частая категория ошибок кстати, см. знаменитый goto fail), то смысл почему-то останется тот же.Да, тот же. В C, к примеру, как код ни оформляй, на какой строке и сколькими пробелами ни окружай скобки, смысл не изменится. goto fail, ЕМНИП, вообще был о другом - там метка fail не там стояла.
> Пролог, фортран ... не, не слышали?
Слышал давно и благополучно забыл. Остаюсь при своём утверждении.
> А как же "свобода оформления кода", "ненавязывание имен" и прочее, что обычно приводится в качестве аргумента?
Как я уже сказал, любое утверждение можно довести до абсурда. Если требование "использовать ASCII" - навязывание, то я за такой уровень "навязывания". Хотите считать это двойными стандартами - ваше право. Я предпочитаю считать это здравым смыслом.
>> Ведь если заменить "пробелы" на "скобочки" (довольно частая категория ошибок кстати, см. знаменитый goto fail), то смысл почему-то останется тот же.
> Да, тот же. В C, к примеру, как код ни оформляй, на какой строке и сколькими пробелами ни окружай скобки, смысл не изменится.Ох уж это выборочное восприятие. А если недоставить пару скобок? Или поставить не там? Cмысл не изменится? А из оформления, обычно что-то отличное от
{
a
{
}
}
или
a{
b{
}
}т.е. несоблюдение иерархии скобок, не считается уже дурным тоном?
> goto fail, ЕМНИП, вообще был о другом - там метка fail не там стояла.
Ага, не там. Вне скобочек. Опциональных в if.
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;
> Ох уж это выборочное восприятие. А если недоставить пару скобок? Или поставить
> не там? Cмысл не изменится?Изменится. Но в отличие от эта ошибка будет видна вполне себе невооруженным глазом.
> т.е. несоблюдение иерархии скобок, не считается уже дурным тоном?
Нет, не всегда.
std::find_if(v.begin(), v.end(), [](int val) { return val == 42; });
class foo
{
int m_n;public:
int get_n() const { return m_n; }
void bar(std::optional< int > x = {});
};std::array< int, 3 > arr = {{ 1, 2, 3 }};
Вообще не вижу проблем, всё компактно и понятно.
>> goto fail, ЕМНИП, вообще был о другом - там метка fail не там стояла.
> Ага, не там. Вне скобочек. Опциональных в if.
>
> if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
> goto fail;
> goto fail;Гм, мне эта ошибка помнилась по-другому, ну да ладно. В чём ваш поинт? В том, что этой ошибки бы не было, если бы не скобки?
> Изменится. Но в отличие от эта ошибка будет видна вполне себе невооруженным глазом.В отличие от чего? Вы продолжайте, не стесяйтесь. А то, как оно "отлично" видно было, показал gotofail. Отсутствие пробела, понимаешь, будет незаметно, то ли дело "излюбленное" if(x) a();b(); в одной строке.
>> т.е. несоблюдение иерархии скобок, не считается уже дурным тоном?
> Нет, не всегда.
> пример, в котором иерархия скобочек полностью и безоговорочно соблюдается и который соотв. приведенному:
{
a
{
}
}
> Вообще не вижу проблем, всё компактно и понятно.Яснопонятно. Идеи для вбросов закончились или вам действительно не видно за деревьями леса?
Намекну: почему не
class foo
{
int m_n;public:
int get_n() const {
return m_n; }
void bar(std::optional< int > x = {});
};
Кстати, не понял, зачем еще и скобочки вот тут:
void bar(std::optional< int > x = {});
std::array< int, 3 > arr = {{ 1, 2, 3 }};
cмотрится круто, но cемантичекски, как бы, совсем не о том.> Гм, мне эта ошибка помнилась по-другому, ну да ладно. В чём ваш
> поинт? В том, что этой ошибки бы не было, если бы не скобки?Трактоваине и вангвание причин - были у каждого свои.
А пойнт в том, что если бы {} не были не опциональными, то выглядело бы оно скорее всего вот так:
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) {
goto fail;
}
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) {
goto fail;
goto fail;
}if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) {
goto fail;
}
Убрали скобочки и оп-па, кое-где в коде изменился смысл.
>> Изменится. Но в отличие от эта ошибка будет видна вполне себе невооруженным глазом.
> В отличие от чего?В отличие от пробелов, имеющих семантику (отличную от "тупо разделитель"), например. Или от Unicode в именах. Выбирайте сами на свой вкус.
>[оверквотинг удален]
>
> class foo
> {
> int m_n;
> public:
> int get_n() const {
> return m_n; }
> void bar(std::optional< int > x = {});
> };
>Потому что это банально неудобно. Для меня, во всяком случае, для вас - не знаю. Но заметьте, семантика этого кода осталась прежней.
Не пойму, вы хотите сказать, что со скобками можно написать вырвиглазный код что ли? Так я не спорю - с любым синтаксисом можно написать такое, что потом хрен разберёшь. Мой поинт, что даже вырвиглазно оформленный код со скобками и без сюрпризов с пробелами и Unicode разобрать проще.
> Кстати, не понял, зачем еще и скобочки вот тут:
>
> void bar(std::optional< int > x = {});
> std::array< int, 3 > arr = {{ 1, 2, 3 }};
>
> cмотрится круто, но cемантичекски, как бы, совсем не о том.Вы писали об "иерархии скобочек", что я понял как "соответствие отступов уровням вложенности скобочек". В соответствии с этим, этот код мог быть написан по-другому:
void bar
(
std::optional< int > x =
{
}
);
std::array< int, 3 > arr =
{
{
1, 2, 3
}
};Это вы имели ввиду или нет - не знаю, разбирайтесь сами.
> Убрали скобочки и оп-па, кое-где в коде изменился смысл.
Охренеть, вот неожиданность, да?
> А пойнт в том, что если бы {} не были не опциональными,Пойнт в том, что считать табулированный блок одним куском кода в этом примере будет только заядлый питонист. Любой мало-мальски вменяемый кодер (да хоть зелёный джуниор, блин) сразу же обратит внимание на отсутствие блока.
>> А пойнт в том, что если бы {} не были не опциональными,
> Пойнт в том, что считать табулированный блок одним куском кода в этом
> примере будет только заядлый питонист. Любой мало-мальски вменяемый кодер (да хоть
> зелёный джуниор, блин) сразу же обратит внимание на отсутствие блока.Сам придумал что-то, сам же опроверг.
Пойнт в том, что передерг и спрыг с темы, он такой передерг и спрыг с темы, что почти заменяет конкретику (которую в этой ветке никто из ярых защитников "свободного форматировани" так и не привел).
Ключевое слово тут - "пару". Скобки парные, и это несколько страхует от ошибок. Кроме того, скобка - это легко наблюдаемый значащий символ - и приведённый пример goto fail вообще странен, в здравом уме он читается "на раз". А вот значимые пробелы в коде - это идиотизм в чистом виде.
Если тебе выделить небольшой фрагмент кода и сказать, что в нем есть ошибка, то конечно ты ее "на раз" прочтешь. Но вот без этих дополнительных подсказок "очевидную" ошибку упустили весьма опытные программисты и получили уязвимость.
> Нет. Любое утверждение можно довести до абсурда. Но когда программа ломается и меняет поведение в зависимости от того, какой пробел ты поставил или с какой буквы начал имя метода, то что-то неладно в королевстве датском.Сейчас я тебе скажу страшное, приготовься. В любом ЯП, например С, в котором идентификаторы являются чувствительными к регистру, замена большой буквы на маленькую или наоборот в идентификаторе поломает программу, причем независимо от позиции этой буквы. Ужас, правда?
А еще, представь себе, ANSI C накладывал ограничение значимости только первых 6 символов на внешние идентификаторы и только в C99 его расширили до 31. Поэтому ты не мог дать внешним функциям имена типа coollib_func1 и coollib_func2, приходилось делать что-то вроде cl_f1 и cl_f2. Теперь видишь, насколько же сильно он был broken by design по твоему определению?
> Сейчас я тебе скажу страшное, приготовься. В любом ЯП, например С, в
> котором идентификаторы являются чувствительными к регистру, замена большой буквы на маленькую
> или наоборот в идентификаторе поломает программу, причем независимо от позиции этой
> буквы. Ужас, правда?Раз уж мы срываем покровы, то я тебе шепну по секрету, что я говорил об именах, которые я даю сам своим функциям, переменным и пр. И уж извини, мне бы хотелось самому решать, с заглавной буквы начинать имена или с прописной.
> А еще, представь себе, ANSI C накладывал ограничение значимости только первых 6
> символов на внешние идентификаторы и только в C99 его расширили до
> 31. Поэтому ты не мог дать внешним функциям имена типа coollib_func1
> и coollib_func2, приходилось делать что-то вроде cl_f1 и cl_f2. Теперь видишь,
> насколько же сильно он был broken by design по твоему определению?Ничто не совершенно. Но надо заметить, что (а) реальные комипляторы кроме, может быть, совсем замшелых считали значимыми больше 6 и даже 31 символа и (б) для C 31 символа вполне достаточно. Не знаю, как вы, но я как-то не привык в качестве имен функций набивать второй том Войны и мира.
До тех пор, пока ты не создаешь отдельный пакет, ты можешь начинать идентификаторы с любой буквы. Даже в случае пакета тебе ничего не мешает всё начинать с заглавной. Единственное ограничение состоит в том, что ты не можешь начинать с маленькой буквы то, что хочешь экспортировать. Это просто ничтожно по сравнению с требованием уникальности первых шести символов или требованием использовать только [A-z_]. Но ты в упор не хочешь этого видеть, ведь к таким ограничениям ты уже привык. Так что остается диагностировать у тебя двойные стандарты вкупе с синдромом утенка.
> Единственное ограничение состоит в том, что ты не можешь начинать с маленькой буквы
> то, что хочешь экспортировать.
> Это просто ничтожно по сравнению с требованием уникальности первых шести символов
> или требованием использовать только [A-z_].У нас с вами разные представления о том, какое из этих ограничений более существенно. (Про первые 6 символов я уже писал - по факту нету этого ограничения.)
Это не просто разные представления, это синдром утенка во всей красе.
Интересно, а как ты относишься к очень распространенным требованиям/практикам/стилям начинать приватные идентификаторы с одного подчеркивания, имена классов писать всегда с большой буквы, переменные всегда с маленькой, а макросы и только их всеми большими? Скорее всего, тебе это кажется нормальными, так как ты к этому уже привык. Возможно даже считаешь такие соглашения удобными. И если не дурак, то даже следуешь принятым в коллективе соглашениям такого рода, когда пишешь код не лично для себя. Так почему же тебя так коробит подобное правило, введенное в стандарт языка?
Про синдром утёнка - это мимо. Во всяком случае, в том, что касается выбора имён.> Интересно, а как ты относишься к очень распространенным требованиям/практикам/стилям начинать приватные идентификаторы с одного подчеркивания, имена классов писать всегда с большой буквы, переменные всегда с маленькой, а макросы и только их всеми большими?
Первый символ подчеркивания (и второй - подчеркивание либо заглавная буква) зарезервирован для реализации языка. В остальном - вполне типичные соглашения. Одни из многих.
> Так почему же тебя так коробит подобное правило, введенное в стандарт языка?
Потому что я поработал в разных проектах, и во многих соглашения были разные. И в каждом случае они были вполне себе осмысленные и местами даже обоснованные. К примеру, сейчас я работаю в проекте, где приняты соглашения имен в стиле_стандартной_библиотеки_c++ - для классов, функций и переменных. Раньше работал в ПроектеВСтилеMicrosoft, а местами приходилось и в проектахВСтилеJava ковыряться.
Выносить в язык ограничения подобного рода - значит, поощрять одно соглашение и запрещать другие. Вам, вероятно, это кажется допустимым, потому что вы подстроились под это ограничение и возможно даже подогнали свой стиль, если регулярно пишите на Rust. Возможно, вам даже хотелось бы, чтобы все писали код так, как вы. Мне это ограничение кажется совершенно излишним, необоснованным и даже вредным. К примеру, чтобы экспортировать метод из библиотеки на C мне не нужно его переименовывать и искать по всему коду его вызовы.
> Вам, вероятно, это кажется допустимым, потому что вы подстроились
> под это ограничение и возможно даже подогнали свой стиль, если регулярно
> пишите на Rust. Возможно, вам даже хотелось бы, чтобы все писали
> код так, как вы.Казалось бы, причем тут ржавчина ...
ну, как-бы тема называется "Релиз языка программирования Rust 1.24", так-что ржавчина очень причём.
> ну, как-бы тема называется "Релиз языка программирования Rust 1.24", так-что ржавчина очень причём.А, ну да. Обсуждали синтактическую особенность гошных экспортов. В теме о ржавчине. Поэтому "подстроились под это ограничение, если вы пишите на расте" сойдет за аргумент. Логично.
Конечно, никакого синдрома утенка. Ведь всем понятно, что смена регистра одной буквы, не выходя из исходника, это в разы более сложная операция, чем открытие файла заголовка, копирование туда полного определения функции и добавление к нему слова extern.
> К примеру, чтобы экспортировать метод из библиотеки на C мне не нужно его переименовывать и искать по всему коду его вызовы.уж лучше один раз переименовать, чем при использовании держать в уме, стиль идентификаторов в каждой либе.
хотя в С разные стили в разных либах даже полезны, но в расте, к счастью, есть неймспейсы
> До тех пор, пока ты не создаешь отдельный пакет, ты можешь начинать
> идентификаторы с любой буквы. Даже в случае пакета тебе ничего не
> мешает всё начинать с заглавной. Единственное ограничение состоит в том, что
> ты не можешь начинать с маленькой буквы то, что хочешь экспортировать.А пацаны, которые писали стандарты C/С++ и те, кто их реализовывал на практике, об этом не знали и понаписали все с маленькой. Вот же дятлы -- в libc все с маленькой буквы, pthreads ...
То ли дело FindFirst() и FindNext(), или WinAllocMem() и WinSubAllocMem() -- вот как надо.
> Любой язык, который навязывает оформление кода (в т.ч. и выбор имен) -
> broken by design.ПРАВИЛЬНО, КакХочуТакПишу, не_надо_мне_ничего_навязывать.
> ПРАВИЛЬНО, КакХочуТакПишу, не_надо_мне_ничего_навязывать.Именно так. Code style выбирается в рамках проекта и под проект. Попытка зачесать оформление всех проектов под единственно правильное (с) истинное (с) верование авторов языка - это overburden.
>> ПРАВИЛЬНО, КакХочуТакПишу, не_надо_мне_ничего_навязывать.
> Именно так. Code style выбирается в рамках проекта и под проект. Попытка
> зачесать оформление всех проектов под единственно правильное (с) истинное (с) верование
> авторов языка - это overburden.rustfmt может настраиваться под ваш стиль.
> Объективный недостаток - Rust слишком не похож на мейнстримные языки. Соответственно подавляющая масса программистов чтобы вкатиться должна потратить много времени и усилийОй, да ладно.
https://www.rust-lang.org/pdfs/Rust-Tilde-Whitepaper.pdf
Стартап, и в нём веб-программеры на ходу переучиваются с ruby на rust, переписывая код с ruby на rust. Достигая при этом 100% успеха, ссутся кипятком от сокращения расхода памяти на 92%, и не могут нарадоваться на то, что баги теперь проявляются не во время выполнения, а на этапе компиляции.
Веб-программисты, Карл!
Пусть играются, рубистов не жалко.
> Пусть играются, рубистов не жалко.Это я "играюсь" с rust'ом. Они зарабатывают денег на нём.
> Vala это обертка над Си да еще и заточенная исключительно на GTK.Не вводите людей в заблуждение, это не так: vala - это не обертка над Си, его компилятор транслирует код написанный на vala с си-сорцы. Заточена она не под GTK, а использует GObject - объектную систему построенную на glib и libc (больше зависимостей нет). Про нужность той же glib если даже писать на си рассказывать думаю не нужно. Связь между glib и GTK для самых маленьких в картинках: https://en.wikipedia.org/wiki/GLib
Vala - штука довольно мощная, гибкая и точно должна понравится сишникам. А что rust? Я сишник, мне должен понравиться rust?
> .. Про нужность
> той же glib если даже писать на си рассказывать думаю не
> нужно.По мне, "нужность" glib --- очень спорный момент.
> Про нужность той же glib если даже писать на си рассказывать думаю не нужно.Вот и предлагается не писать на си, а писать на Rust.
Тот самый случай, когда даже си лучше чем это.
> Тот самый случай, когда даже си лучше чем это.Чем лучше?
Чем это.
> Заточена она не под GTKА на чем кроме gtk можно писать гуи-приложения?
Я пишу на MFC. Рекомендую.
Можно подробнее? Есть биндинг?
А для Erlang нет биндинга к MFC?
Ну так чисто поржать.
>> Vala это обертка над Си да еще и заточенная исключительно на GTK.
> Не вводите людей в заблуждение, это не так: vala - это не обертка над Си, его компилятор транслирует код написанный на vala сЭто и есть "обертка над си". Не пойму, чего в этом особенного.
Тогда и rust можно назвать обёртка над llvm, ведь по факту это так.
> Тогда и rust можно назвать обёртка над llvm, ведь по факту это так.Можно. Разрешаю. Такая же обертка, как и шланг.
А если уж не различать "по факту" между компилятором высокоуровневого ЯП и низкоуровневым бэкэндом-инфраструктурой для компилирования, то тогда и питоны с жабаскриптами тоже считай почти нативщина, ведь там же есть JIT, которые суть обертка ...
> Vala - штука довольно мощная, гибкая и точно должна понравится сишникам. А
> что rust? Я сишник, мне должен понравиться rust?Rust должен нравиться плюсовикам, но никак не сишникам.
> Vala - штука довольно мощная, гибкая и точно должна понравится сишникам.Нет. Мне Vala совершенно не нравится. ООП -- sucks. Все эти вызовы через виртуальные таблицы методов -- замечательный способ оттормозить процессор в самую крайность. То есть, во-первых, вообще не очень ясно зачем C'шнику нужен ООП, и какой он к чертям C'шник, если ему ООП нужен. А во-вторых, если всё же нужен, то лучше уж C++: тот даёт больше контроля над тем, что будет вызываться через vtable, а что нет, да и оптимизирует он виртуальные вызовы, я полагаю, лучше, чем если их сначала компилять в C, а затем из C куда-то ещё. Чтобы соптимизировать виртуальный вызов, оптимизатор должен работать в абстракциях типов с виртуальными методами, C'шный оптимизатор так не умеет.
Vala -- это неплохая замена для Python'а. Может быть. По идее должно быть быстрее, и вообще менее требовательно по ресурсам. Но для C -- это не замена нисколько.
> что rust? Я сишник, мне должен понравиться rust?
Нет, не должен. Но я бы рекомендовал глянуть.
> Как оно по сравнению с Vala ?Вроде разработчикам Gnome очень нравиться Rust и они работают над его интеграцией,
пока что наравне с Vala, а потом кто знает, много было постов на https://www.reddit.com/r/rust/ об этом.
В gnome-builder в меню выбора языка есть: С, С++, С#, Vala, Python, JavaScript и все.
Rust отсутствует. Считаю, это показатель.
> В gnome-builder в меню выбора языка есть: С, С++, С#, Vala, Python, JavaScript и все.Rust отсутствует. Считаю, это показатель.
это тем патлатым придуркам на скутерах, что испоганили гном? не мудрено - их патлатые друзья уже испоганили файрфокс
Годно, нужно. Надеюсь, скоро заменит богомерзкие unmanaged языки.
Нет, в "богомерзком" C++ ОО сделано и то элегантней.
В Rust'е нет Java-like ООП-а. Rust немного о другом. В Rust'е балом правит статический полиморфизм взамен полиморфизму подтипов. Хотя в случае чего, можно конечно и полиморфизмом подтипов воспользоваться, но статический полиморфизм покрывает большинство ситуаций и к тому же дешевле, нежели полиморфизм подтипов(прямой вызов функции обращением по адресу функции, вместо того, чтобы для начала найти этот адрес в таблице виртуальных методов.
> В Rust'е нет Java-like ООП-а. Rust немного о другом. В Rust'е балом
> правит статический полиморфизм взамен полиморфизму подтипов. Хотя в случае чего, можно
> конечно и полиморфизмом подтипов воспользоваться, но статический полиморфизм покрывает
> большинство ситуаций и к тому же дешевле, нежели полиморфизм подтипов(прямой вызов
> функции обращением по адресу функции, вместо того, чтобы для начала найти
> этот адрес в таблице виртуальных методов.Елки моталки скинте ссылку на все термины то что вы тут понаписали, а то нефига вообще непонятно .
> Елки моталки скинте ссылку на все термины то что вы тут понаписали,
> а то нефига вообще непонятно .Тут одно из двух:
1. С ООП вы всерьез не сталкивались, и скорее всего оно и не сильно нужно.
2. Уроки сами себя не сделают!
> Нет, в "богомерзком" C++ ОО сделано и то элегантней.В С++ ОО нет и никогда не было(и никогда не будет).
Попробуйте создать производный класc от std::vector ололо.
И что же помешает создать производный класс от std::vector, а? Он вроде как не final, бери да создавай.
> В С++ ОО нет и никогда не было(и никогда не будет).В С++ ООП реализован настолько, насколько это возможно для низкоуровневого компилируемого языка.
Вообще, ООП в каждом языке -- свой, со своими нюансами и фишечками. Тяжело выбрать какой-то один, канонический, чтобы другие языки тыкать в то, что их-то ООП не настоящий.
Не спорю, в С++ он реализован xерово, но в Rust ещё ужасней.
> Не спорю, в С++ он реализован xерово,Я не говорю о том, что он реализован хреново. Я говорю о том, что он реализован так, как это было возможно. Часть архитектурных решений сделаны не очень, но при этом он вполне пригоден для использования.
> но в Rust ещё ужасней.
В Rust вообще говоря не ООП, а полиморфизм типов, почти один-в-один классы в Haskell. Это не ужасно, это просто другой подход.
Притом более гибкий подход, по сравнению с традиционными ООП в C++/Java. Как пример: в OCaml есть тоже есть ООП, но в большинстве случаев удобнее использовать полиморфизм типов и модули.
managed языки не нужныне надо оберегать программиста от возможных ошибок, надо учить так чтобы программисты их не делали.
C++ это легаси язык для старперов которые помнят все друрости реализованные там.
Действительно теперь подход проще: хренакс хренакс и в продакшен.
> Действительно теперь подход проще: хренакс хренакс и в продакшен.Клиент не будет ждать пока Вы разработаете спустя 30 лет свою программу когда Ваш коллега с меньшим ... опытом организует MVP за один вечер.
К сожалению, многие MVP так и не доходят до уровня решения на C/C++ из-за неокупаемости.
При всем моем уважении к C/C++ это фундаментальные языки для систем фундаментальных и отработанных и требующих соответствующего системного подхода: вроде Баз данных, систем под нагрузкой и т.д.
Задачи вроде веба ну вы в курсе кто там Ruby и PHP педалируют во всю. И главное работодатели довольны наняв школьников и студентов за десятую зарплаты нормального ынжынера.
Все дело в деньгах карл а не в идеалах
>> Действительно теперь подход проще: хренакс хренакс и в продакшен.
> Клиент не будет ждать пока Вы разработаете спустя 30 лет свою программу
> когда Ваш коллега с меньшим ... опытом организует MVP за один
> вечер.Угу, который через неделю накроется медным тазом на втором десятке пользователей. А от макак, которые его на коленке состряпали, уже и след простыл.
Клиенты разные бывают. Есть такие, которым важно качество, и они не прочь заплатить за него.
> надо учить так чтобы программисты их не делали.
> сам не способ написать простое предложение без ошибок.
>> сам не способ написать простое предложение без ошибок.
>не способты тже
>>> сам не способ написать простое предложение без ошибок.
>>не способ
> ты тжеи я тоже. пожетому вот LFLAGS=-Wall -g3
>managed языки не нужныне надо оберегать программиста от возможных ошибок, надо учить так чтобы программисты их не делали.Ядро Линукс течёт. Я все сказал.
Школота_ничего_не знает,_но_всюду_лезет.jpg
Чтобы заменить самого себя нужно познать рекурсию.
Без TCO ничего не выйдет.
> Без TCO ничего не выйдет.У Вас рекурсия с зади не оптимизирована
Определённое напряжение вызывает назойливое проталкивание инфраструктуры доставки бинарников ("пакетный менеджер, позволяющий получить нужные для программы библиотеки в один клик") и сборки ("Включена по умолчанию инкрементальная компиляция,"). Питоний подход к оформлению тоже не радует: "Реализована утилита rustfmt для автоматического формирования исходных текстов в соответствии с ...".
rustfmt скорее как аналог go fmt было запилено.
Cargo вполне умеет тащить зависимости просто с git сервера, или брать их локально с фc, так что, нет.
> Cargo вполне умеет тащить зависимости просто с git сервера, или брать их
> локально с фc, так что, нет.А "язык отдельно, управление кодом --- отдельно" --- это устаревшая концепция, о которой вспоминают только враги всего прогрессивного, да?
а в чем собственно проблема? Cargo - система сборки вроде cmake, все что она делает - это скачивает нужные файлы и вызывает конпелятор (rustc) с нужными опциями. Единственное не отдельное - это то, что она пилится самими разработчиками языка
> Определённое напряжение вызывает назойливое проталкивание инфраструктурыИМХО это одна из основных фич, вспомните боль подключения чего-то стороннего
в свой кросс-платформенный проект, здесь это можно сделать практически одной строчкой.Причем не знаю как с пакетным менеджером питона, но здесь все сделано по уму.
Можно с помощью cargo-vendor все зависимости упаковать, так что сборка не требует
доступа к Интернету.> Питоний подход к оформлению тоже не радует:
А как review кода проводить без автоматического форматирования?
>А как review кода проводить без автоматического форматирования?review нужно только 6ыдлокоду индусов. Код это искусство. Проводя review вы обижаете художника.
>>А как review кода проводить без автоматического форматирования?
> review нужно только 6ыдлокоду индусов. Код это искусство. Проводя review вы обижаете
> художника.Аналогично: review процессы отдельно, язык отдельно. Не?
>>>А как review кода проводить без автоматического форматирования?
>> review нужно только 6ыдлокоду индусов. Код это искусство. Проводя review вы обижаете
>> художника.
> Аналогично: review процессы отдельно, язык отдельно. Не?Я бы ещё частично кодоанализ вынес из языка и соглашения об оформлении кода.
Мне почти всё нравится в rust, но когда snake case проверяется прямо компилятором - этого я не пойму.
>>>А как review кода проводить без автоматического форматирования?
>> review нужно только 6ыдлокоду индусов. Код это искусство. Проводя review вы обижаете
>> художника.
> Аналогично: review процессы отдельно, язык отдельно. Не?Так язык и reivew связаны только тем что аналог clang-format идет вместе с компилятором
rust, впрочем clang-format вроде с clang тоже устанавливается.
> Так язык и reivew связаны только тем что аналог clang-format идет вместе
> с компилятором
> rust, впрочем clang-format вроде с clang тоже устанавливается.Это аналог не clang-format, а gofmt. Разница в том, что первый можно настроить.
> Это аналог не clang-format, а gofmt. Разница в том, что первый можно настроить.Что-то ты гонишь чувак. А rustfmt.toml это типа не настройки?
Зачем вы пишите в такой провокативной манере?
Отличная манера. Аноним, продолжай. Нужно больше примеров с критицизмом и ненавистью.
>> Определённое напряжение вызывает назойливое проталкивание инфраструктуры
> ИМХО это одна из основных фич, вспомните боль подключения чего-то стороннего
> в свой кросс-платформенный проект, здесь это можно сделать практически одной строчкой.Концептуально совпадает с современной Web-разработкой. Интересно, что эту концепцию тянут в разработку ядер и прочей встройки.
> Причем не знаю как с пакетным менеджером питона, но здесь все сделано
> по уму.
> Можно с помощью cargo-vendor все зависимости упаковать, так что сборка не требует
> доступа к Интернету.Это не существенно. Вам отгружают фактически BLOB, содержимое (состояние, история) которого вы никак не контролируете.
> Это не существенно. Вам отгружают фактически BLOB, содержимое (состояние, история) которого
> вы никак не контролируете.В смысле blob? Сборка все время осуществляется из исходников, они распакованные лежат в ~/.cargo/что-то там, IDE вас перебросит туда если вы сделаете "goto" и именно из этих исходников соберется ваш проект.
IDE? На хрусте? :)
> А как review кода проводить без автоматического форматирования?Внезапно, глазами. Вообще не понимаю, как одно с другим связано.
>> А как review кода проводить без автоматического форматирования?
> Внезапно, глазами. Вообще не понимаю, как одно с другим связано.Вот именно что глазами, просматривать сотни строк изменений глазами,
из-за того что другая IDE по другому код отформатировала,
вам свои глаза что ли не жалко и свое время?
>>> А как review кода проводить без автоматического форматирования?
>> Внезапно, глазами. Вообще не понимаю, как одно с другим связано.
> Вот именно что глазами, просматривать сотни строк изменений глазами,
> из-за того что другая IDE по другому код отформатировала,
> вам свои глаза что ли не жалко и свое время?Различные (распространенные) варианты форматирования кода меня лично не напрягают при рецензировании. Лишь бы суть происходящего была понятна. Если вас форматирование вводит в ступор, то возможно, вам рано рецензировать. Разумеется, если вам попался код, претендующий на первую десятку в IOCCC[1], то рецензирование можно завершить сразу с комментарием "переформатировать".
[1]: https://www.ioccc.org/
>>>> А как review кода проводить без автоматического форматирования?
>>> Внезапно, глазами. Вообще не понимаю, как одно с другим связано.
>> Вот именно что глазами, просматривать сотни строк изменений глазами,
>> из-за того что другая IDE по другому код отформатировала,
>> вам свои глаза что ли не жалко и свое время?
> Различные (распространенные) варианты форматирования кода меня лично не напрягают при
> рецензировании. Лишь бы суть происходящего была понятна.Яснопо. Расходимся. "Рецензиант" даже не понял сути проблемы.
> Яснопо. Расходимся. "Рецензиант" даже не понял сути проблемы.Видимо, потому что у меня она просто не возникает. Может, вы объясните?
> Видимо, потому что у меня она просто не возникает. Может, вы объясните?три слова: системы контроля версий
>>>> А как review кода проводить без автоматического форматирования?
>>> Внезапно, глазами. Вообще не понимаю, как одно с другим связано.
>> Вот именно что глазами, просматривать сотни строк изменений глазами,
>> из-за того что другая IDE по другому код отформатировала,
>> вам свои глаза что ли не жалко и свое время?
> Различные (распространенные) варианты форматирования кода меня лично не напрягаютПри чем здесь вообще общие стили, и насколько они напрягают?
Мы говорим о различии стилей, то есть приходит тебе на review патч,
там на самом деле изменений две строчки, а еще 300 строчек изменены,
потому что табы пробелами заменены, или перед фигурными скобочками
перевод строки поставлен, и т.д. и т.п., именно за этим нужны такие тулзовины
типа rustfmt, чтобы их поставить в git pre-commit hook и в VCS и далее на review
попал патч который только две строчки изменил.И даже если так повезло и твой review tool внутри содержит что-то типа rustfmt/clang-format/go fmt, и сможет отфильтровать эти бесполезные изменения,
то потом "git blame" будет "врать" для этих строчек.
В общем в современной разработке в VCS код должен храниться в определенном формате,
если мы не можем уйти от хранения AST в виде текста.
> При чем здесь вообще общие стили, и насколько они напрягают?
> Мы говорим о различии стилей, то есть приходит тебе на review патч,
> там на самом деле изменений две строчки, а еще 300 строчек изменены,
> потому что табы пробелами заменены, или перед фигурными скобочками
> перевод строки поставлен, и т.д. и т.п.,Тулзовины не спасут от отсутствия культуры работы с кодом.
> то есть приходит тебе на review патч, там на самом деле изменений две строчки, а еще 300 строчек изменены,потому что
кто-то чересчур вумный запустил для всего файла
> такие тулзовины типа rustfmt
А если не можешь настроить IDE, чтобы она не ломала существующее форматирование, то надо менять. Либо IDE, либо профессию.
>> Определённое напряжение вызывает назойливое проталкивание инфраструктуры
> ИМХО это одна из основных фич, вспомните боль подключения чего-то стороннего
> в свой кросс-платформенный проект…и npm leftpad.
>>> Определённое напряжение вызывает назойливое проталкивание инфраструктуры
>> ИМХО это одна из основных фич, вспомните боль подключения чего-то стороннего
>> в свой кросс-платформенный проект
> …и npm leftpad.Не знаю насчет javascript, но это же
а)Компилируемый язык
б)Все зависимости версионированыПоэтому у "npm leftpad" маленькая вероятность случиться.
> Питоний подход к оформлению тоже не радует: "Реализована утилита rustfmt для автоматического формирования исходных текстов в соответствии с ...".Ээ-э, а как же clang-format? Или тот же indent - там автор видимо вообще угнал машину времени, чтобы иметь возможность подсмотреть "питоний подход к оформлению" :)
indent --- не часть компиляторного проекта. А вот clang-format, кажется, вместе с libformat --- в репозитории clang. Что говорит о тяге CLang/LLVM команды к построению летающих комбайнов.
> indent --- не часть компиляторного проекта. А вот clang-format, кажется, вместе с
> libformat --- в репозитории clang. Что говорит о тяге CLang/LLVM команды
> к построению летающих комбайнов.Скорее их лучшее пониманию проблем разработчиков C++ работающих в больших командах.
> indent --- не часть компиляторного проекта.Пока не прибивают гвоздями к компилятору, не вижу разницы.
Тем более, прикрутить автоформат к готовому парсеру проще, чем клепать свой (недо)парсер (или его эрзац на регекспах, в которых потом и сам черт ногу сломит), а "нужность" на практике показана хотя бы тут:
https://github.com/torvalds/linux/blob/master/Documentation/...
> But even if you fail in getting emacs to do sane formatting, not everything is lost: use indent
> panic!("Test");Этой строчкой можно охарактеризовать весь язык.
В любой непонятной ситуации паниковать:))
abort() выбор мастеров?
>> panic!("Test");
> Этой строчкой можно охарактеризовать весь язык.
> В любой непонятной ситуации паниковать:))А что, лучше продолжать работу в UB, портить файлы и данные?
Лучше сразу продумывать работу функции до конца и не приделывать ей пятое колесо и делать субъективные выводы о том, что если она вдруг не сделает "panic" (или abort), то данные обязательно испортятся. Мне уже тошно читать иногда исходники firefox'а мозиловцев на русте. Что не строчка, то перечисление, завернутое в класс(точнее наоборот), то какой нибудь panic.
Ситуации разные бывают, и иногда все же важнее не упасть в обморок, а успеть сохранить не сохраненные данные.
> Лучше сразу продумывать работу функции до конца и не приделывать ей пятое
> колесо и делать субъективные выводы о том, что если она вдруг
> не сделает "panic" (или abort), то данные обязательно испортятся. Мне уже
> тошно читать иногда исходники firefox'а мозиловцев на русте. Что не строчка,
> то перечисление, завернутое в класс(точнее наоборот), то какой нибудь panic.
> Ситуации разные бывают, и иногда все же важнее не упасть в обморок,
> а успеть сохранить не сохраненные данные.А можно пример? Во-первых классов в rust вообще нет.
Во-вторых ошибки и обязательность их обработки это то в чем Rust силен.
Всякие "?", .map_err и т.д. и т.п. в C++ об этом можно было только мечтать,
или пилить свой framework вместо работы.
Rust has a tiered error-handling scheme:If something might reasonably be absent, Option is used.
If something goes wrong and can reasonably be handled, Result is used.
If something goes wrong and cannot reasonably be handled, the thread panics.
If something catastrophic happens, the program aborts.
(c) https://doc.rust-lang.org/nomicon/unwinding.html> Лучше сразу продумывать работу функции до конца и не приделывать ей пятое колесо и делать субъективные выводы о том, что если она вдруг не сделает "panic" (или abort), то данные обязательно испортятся.
Не "обязательно испортятся", а "нет способа дать какие-либо гарантии в отношении того, что будет делать любой код, какой бы мы не написали" и ещё, вероятно, "нет никакого осмысленного действия, которое мы могли бы совершить". Продумывать сразу -- это очень хорошо задумано, но это не работает. Сразу я может и продумал, но затем произошёл рефакторинг кода в соседнем сорце, и всё что я там себе напридумывал оказалось неверным. Когда я продумываю "сразу", я не могу предусмотреть всего, что будет с этой программой дальше, как будет меняться её код, и какие инварианты, на которые я полагаюсь, будут нарушены. А тут, мы оказываемся в очень интересной ситуации. Мы ведь думаем о программах в рамках логики, а логика -- это такая штука, что если каким-то образом в нашей базе истинных утверждений окажется одно ложное, то дальше логика может доказать истинность любого утверждения и одновременно она может доказать ложность любого утверждения. Иными словами, если в логических рассуждениях была допущена хотя бы одна ошибка, то мы сходу теряем любую способность отличать истину от лжи.
И всё, приехали. Потому что невозможно писать осмысленный код, не полагаясь ни на что. То есть, мы можем переключиться с аристотелевой логики в режим байесианской логики, и писать код, который работает с какой-то вероятностью, но у нас нет технологий написания такого кода. Попадаются отдельные хаки, но они не тянут на технологию, скорее на отсутствие технологии.> Что не строчка, [...], то какой нибудь panic.
> Ситуации разные бывают, и иногда все же важнее не упасть в обморок, а успеть сохранить не сохраненные данные.Никто не мешает, "падая в обморок", отловить панику, сохранить несохранённые данные и упасть только после этого.
https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
std определяет достаточно гибкий механизм, которого хватит вполне для любого user-space кода. А для не-userspace можно определить свою panic_fmt и делать по-своему.
Ну а если браузер падает в обморок при любой ошибке, то тут вопрос не в том, правильно это или нет, а в том, как часто это случается. Браузер должен вызывать abort, если дальнейшее его поведение непредсказуемо, потому что непредсказуемое поведение браузера слишком чревато. И ничего сохранять при этом он не должен, я переживу, если часть истории будет потеряна, или последние закладки, которые я добавлял, потеряются. Даже если сотня текущих открытых вкладок будет потеряна -- не беда. Хуже будет, если браузер допустит выполнение произвольного кода или сольёт данные кредитки васяну-хакеру.
Так что вопроса что делать браузеру, "if something goes wrong and cannot reasonably be handled", у меня лично не стоит. Вопрос лишь в том, как часто "something goes wrong". Причём под этой частотой, я подразумеваю не частоту упоминания слова panic в коде, а частоту реальных падений.
Может кто знает прямые урлы на скачивание архивов? Без rustup?
> Может кто знает прямые урлы на скачивание архивов? Без rustup?
> скочал-запустилИ эти люди смеются над вендузятниками.
Для федоры из dnf вытянуть можно
> И эти люди смеются над вендузятниками.Грешно смеяться над убогими.
Судя по тому что на нём пишут операционные системы - это скорее всего замена С
> Судя по тому что на нём пишут операционные системы -то у когото слишком много свободного времени.
Исошного стандарта нет -- значит, нет и языка. Фтoпкy.
Исошные стандарты устаревающие каждые три года - вот это сильно лучше.
> Исошные стандарты устаревающие каждые три года - вот это сильно лучше.Лучше. Уже хотя бы тем, что стандарт есть, и ему следуют все, включая компиляторописателей.
c99 ISO/IEC 9899:1999, a past version of the C programming language standard.
Источник wikipedia
Так и запишем: использует википедию вместо мозга.
> Исошного стандарта нет -- значит, нет и языка. Фтoпкy.Сюрприз: исошные стандарты языков появляются существенно позднее самих языков.
>> Исошного стандарта нет -- значит, нет и языка. Фтoпкy.
> Сюрприз: исошные стандарты языков появляются существенно позднее самих языков.Важно то, что при стандартизации принимаются во внимание опыт и тенденции всей индустрии. Если язык развивается одной конторой/группой/человеком, то и следует он веяниям этой конторы/группы/человека. Так что язык, для которого не ведутся работы по международной стандартизации - это местячковая игрушка, какой бы привлекательной она ни была.
> Так что cишка пребывала 20 лет в небытие и положении местячковой игрушкипофиксил.
Этот чудесный проект использует в качестве бэкенда LLVM, из-за чего не может собраться на некоторых архитектурах: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881845В результате под эти архитектуры нельзя собрать новые версии Firefox и librsvg, которую хипстота решила перевести на rust.
Так вроде бы правильные пацаны, помимо архитектуры не как у всех, сидят на ESR версиях?
ESR-версии рано или поздно закончатся, а для librsvg такого понятия вообще нет. А Мозилле до кроссплатформенности, судя по всему дела нет, они больше на винду ориентируются.
> Этот чудесный проект использует в качестве бэкенда LLVM, из-за чего не может
> собраться на некоторых архитектурах: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881845
> В результате под эти архитектуры нельзя собрать новые версии Firefox и librsvg,
> которую хипстота решила перевести на rust.А что он должен использовать? Если бы они сами писали бекенд с нуля, с поддержкой архитектур было бы ещё хуже. Не ссы, починят.
gcc же, ну
> gcc же, нуИ были бы комментарии в духе «Игрушечный ЯП, транслируется в си! Неосилили свой бэкэнд/можно сразу на си писать! Однозначно ненужно!»
Опеннетчикам не угодишь.
> До 10 раз ускорено выполнение операцииТо есть теперь скорость выполнения равна 10 разам?
А чего это никто пхп не ругает? Непорядок на опеннетике.
> А чего это никто пхп не ругает? Непорядок на опеннетике.Си ругают, а она скопирована с пхп, фигурные скобки и все такое.
> приняли участие 152 разработчикаКак обмельчали программисты. Для Теха было достаточно одного Кнута.
sysvinit реально переписать на rust?
будет от этого польза, если переписать на rust с максимально возможной параллелизацией?
Руки прочь от SysVinit! Негоже кошерному SysVinit от LLVM не зависеть.
Поправил. Руки прочь от SysVinit! Негоже кошерному SysVinit от LLVM зависеть.
>>> До 10 раз ускорено выполнение операции поиска символов внутри строки при помощи функции str::find, которая переписана с использованием memchr. На memchr также переведена реализация [u8]::contains, но ускорение её работы не столь внушительно (ускорение примерно в 3 раза). С использованием ассемблерных инструкций проведена оптимизация f32::min и f32::max;С такими оптимизациями скоро питон догонят!
Раст внутри мозиллы и сдохнет. Пока экосистема нарастёт, он станет ненужен
Вот уже битый час компилится rust-1.24 на замену rust-1.23, который требуется только firefox-58.0.2. Чего же он такой трудный?!
Ну это ж мозилла! Один LLVM весит столько же, сколько вся оcтальная операционка. А сборка Firefox'а...
> Ну это ж мозилла! Один LLVM весит столько же, сколько вся оcтальная
> операционка. А сборка Firefox'а...rust-1.24.0 - 1ч14м.
firefox-58.0.2 - 1ч37м.Для сравнения:
gcc8-devel-8.0.1.s20180211 - 14м.
> rust-1.24.0 - 1ч14м.
> firefox-58.0.2 - 1ч37м.
> Для сравнения:
> gcc8-devel-8.0.1.s20180211 - 14м.Ну, видимо новые-модные языки позаковыристеее простого Си (или простого Си++, вроде, в gcc?..). Тем более, что оба "конкурсанта" таскают с собой всё-всё-всё - библиотеки бандлят патченые, рантаймы-гуи-батарейки в комплекте и пр.
Сложный язык и рантайм.... ну, со сборкой LO/AOO посравнивай. Или boost-а какого. Тоже много, наверное, получтся.
> rust-1.24.0 - 1ч14м.
> firefox-58.0.2 - 1ч37м.А LLVM в это время вошло, или оно ещё в плюс?
>> rust-1.24.0 - 1ч14м.
>> firefox-58.0.2 - 1ч37м.
> А LLVM в это время вошло, или оно ещё в плюс?Он теперь "за" gcc.
http://www.opennet.ru/openforum/vsluhforumID3/113384.html#2
http://www.opennet.ru/openforum/vsluhforumID3/113145.html#34
http://www.opennet.ru/openforum/vsluhforumID3/113145.html#41Чегеварит супротив "партнёров", требует
https://www.opennet.ru/openforum/vsluhforumID3/113145.html#277
удовлетворения насущных хотелок аж дым стоит!
По поводу ситуации во FreeBSD у меня мнения нет.А вот с мнением про LLVM в упомянутых ссылках я вполне согласен.
>> rust-1.24.0 - 1ч14м.
>> firefox-58.0.2 - 1ч37м.
> А LLVM в это время вошло, или оно ещё в плюс?Нет. Это время на сборку соответствующих пакетов. Rust чего-то там делает с LLVM, какие-то шашни мутит, судя по выхлопу процесса сборки. В общем, один монстр использует другого в каких-то позах.
> gcc8-devel-8.0.1.s20180211 - 14м.Не верю. Это разве что без тестов. С тестами у меня несколько часов на SSD.
>> gcc8-devel-8.0.1.s20180211 - 14м.
> Не верю. Это разве что без тестов. С тестами у меня несколько часов на SSD.% pkg info gcc8-devel
gcc8-devel-8.0.1.s20180211
Name : gcc8-devel
Version : 8.0.1.s20180211
Installed on : Sat Feb 17 10:53:12 2018 MSK
Origin : lang/gcc8-devel
Architecture : FreeBSD:11:amd64
Prefix : /usr/local
Categories : lang
Licenses : GPLv3, GPLv3RLE
Maintainer : gerald@FreeBSD.org
WWW : https://gcc.gnu.org
Comment : GNU Compiler Collection 8
Options :
BOOTSTRAP : off
GRAPHITE : off
Shared Libs required:
libgmp.so.10
libmpfr.so.4
libmpc.so.3
libisl.so.15
Shared Libs provided:
libitm.so.1
libssp.so.0
libatomic.so.1
libcc1plugin.so.0
libcc1.so.0
libgcc_s.so.1
libquadmath.so.0
libcp1plugin.so.0
liblto_plugin.so.0
libstdc++.so.6
libgomp.so.1
libgfortran.so.5
Annotations :
FreeBSD_version: 1101509
cpe : cpe:2.3:a:gnu:gcc:8.0.1:::::freebsd11:x64
Flat size : 193MiB
Description :
GCC, the GNU Compiler Collection, supports a number of languages. This
port installs the C, C++, and Fortran front ends as gcc8, g++8, gfortran8,
respectively.WWW: https://gcc.gnu.org
Gerald Pfeifer <gerald@FreeBSD.org>
chromium-63.0.3239.132 - 4ч25м.Процессор AMD Phenom II X6 1055T, ОЗУ 11,5 ГБ.