Представлен (https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-201...) релиз языка системного программирования Rust 1.31 (http://www.rust-lang.org), развиваемого проектом Mozilla. Кроме штатного номера версии выпуск также обознечен как Rust 2018 и преподносится (https://hacks.mozilla.org/2018/12/rust-2018-is-here/) как наиболее важный релиз с момента формирования (https://www.opennet.ru/opennews/art.shtml?num=42241) версии 1.0 в 2015 году. В рамках выпуска проведена работа по консолидации всех улучшений и изменений, подготовленных за последние три года, в виде целостного продукта. Rust 2018 (https://rust-lang-nursery.github.io/edition-guide/rust-2018/...) выступит основой для наращивая функциональности в последующие три года, по аналогии с тем, как выпуск Rust 1.0 стал базисом для развития языка в прошедшие три года.Для разделения несовместимой функциональности введена концепция редакций языка (https://doc.rust-lang.org/stable/edition-guide/). Редакции с номерами "2015" и "2018" могут использоваться в качестве метки для определения среза состояния языка (поле "edition" в секции "[package]" метаданных cargo-пакетов), затрагивающего только несовместимые изменения.
Редакция "2015" включает уже стабилизированную к текущему моменту функциональность и все будущие изменения не нарушающие совместимость, а редакция "2018" дополнительно охватывает нарушающие совместимость новшества, предложенные в текущем выпуске 1.31 и утверждённые для реализации в будущем. Кроме самого языка редакции также учитывают состояние инструментария и документации (например, в редакции 2018 в состав введены модули поддержки IDE, rustfmt и Clippy).Режим "2015" позволяет сохранить полную совместимость с существующими приложениями без внесения нарушающих совместимость изменений. Активировать режим "2018" имеет смысл при желании задействовать в коде будущие возможности языка, такие как ещё не реализованные концепции async/await и "try". Так как данная возможность может потребовать корректировки кода старых программ, написанных до резервирования слов async, await и try, указанные ключевые слова уже внесены в редакцию "2018", несмотря на то, что сама функциональность ещё не добавлена.
Иными словами, в выпуске Rust 1.31 заранее произведена фиксация ключевых слов для ещё не готовых новшеств, нарушающих обратную совместимость, и ожидаемых в последующие три года. При этом грядущие изменения и новшества, не приводящие к нарушению совместимости, по мере своего появления будут доступны для пакетов независимо от выбранной редакции - специфичными для редакции "2018" и не попадающими в редакцию "2015" станут только изменения, нарушающие совместимость.
Основные новшества (https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...) Rust 1.31:- Реализована техника NLL (Non-Lexical Lifetimes), расширившая систему учёта времени жизни заимствованных переменных. Вместо привязки времени жизни на лексическом уровне, NLL осуществляет учёт на уровне набора указателей в графе потока выполнения. Новый подход позволяет увеличить качество проверки заимствования переменных
(borrow checker (https://doc.rust-lang.org/book/ch04-02-references-and-borrow...)) и допустить выполнение некоторых видов корректного кода, использование которого ранее приводило к выводу ошибки. Новое поведение существенно упрощает отладку. Например:fn main() {
let mut x = 5;
let y = &x;
let z = &mut x;
println!("y: {}", y);
}
Выполнение данного кода в редакции "2015" приводит к выводу ошибки "cannot borrow 'x' as mutable because it is also borrowed as immutable" для всего блока "{}" не детализируя источник проблемы, а начиная с Rust 1.31 при выборе редакции "2018" ошибка будет локализована для выражения 'println!("y: {}", y);', которое вызывает конфликт;- Внесены изменения (https://doc.rust-lang.org/edition-guide/rust-2018/module-sys...) в систему модулей, нацеленные на её упрощение: для большинства случаев убрана необходимость использования "extern crate"; добавлена возможность импорта макросов при помощи выражения "use" вместо атрибута "#[macro_use]"; абсолютные пути начинающиеся с названия пакета (crate) теперь разбираются относительно текущего пакета; возможно сосуществование подкаталогов foo.rs и foo/ subdirectory may coexist, при размещении субмоделей в подкаталоге больше не нужен mod.rs. Изменения применимы только в режиме "2018";
- Добавлены новые способы упрощённого задания области видимости (lifetime elision (https://doc.rust-lang.org/nomicon/lifetime-elision.html)) в функциях и заголовках шаблонов (impl). Вместо
"impl‹'a› Reader for BufReader‹'a› {}" теперь можно указывать "impl Reader for BufReader‹'_› {}".
- Добавлен новый способ определения функций - "const fn", который дополнил уже существующие выражения "fn", "unsafe fn" и "extern fn". Определённые через "const fn" могут вызываться как обычные функции, но также использоваться в любом контексте вместо констант, например "const SIX: i32 = foo(5);". Данные функции вычисляются на этапе компиляции, а не в ходе выполнения, поэтому на них накладываются определённые ограничения (допускаются арифметические операции и операции сравнения над целыми числами, запрещены булевые операторы "&&" и "||", допускается чтение только из констант, можно вызывать только функции, определённые как "const fn" и т.п.);
- Помимо cargo, rustdoc и rustup в состав включены утилиты clippy ( linter) и rustfmt (форматирование кода), а также плагины для поддержки интегрированных сред разработки Visual Studio Code, IntelliJ, Atom,
Sublime Text 3 и Eclipse;
- Стабилизированы новые атрибуты для инструментов Rust, таких как rustfmt и clippy. Например, "#[allow(clippy::bool_comparison)]" для ограничения применения clippy;- В разряд стабильных переведена новая порция API, в том числе From‹NonZeroU8›, From‹&Option‹T››, slice::align_to, slice::chunks_exact;
- В пакетный менеджер Cargo добавлена поддержка параллельной загрузки нескольких пакетов при помощи HTTP/2. За исключением специфичных случаев переведено в разряд необязательных выражение "extern crate".
- Запущена инициативы по оптимизации Rust для предметно-ориентированных областей. Созданы рабочие группы для развития средства для разработки сетевых сервисов (развивает async/await), создания приложений для командной строки (развивает библиотеки для CLI-интерфейса), поддержки WebAssembly (компиляция и взаимодействие с wasm) и создания решений для встраиваемых устройств (улучшение поддержки ARM).Напомним, что язык Rust сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime. Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек поддерживается репозиторий crates.io (https://crates.io/).
URL: https://hacks.mozilla.org/2018/12/rust-2018-is-here/
Новость: https://www.opennet.ru/opennews/art.shtml?num=49747
Пора бы уже потихоньку перетаскивать ядро на Rust
На Лисп или Квик Бейсик. Оба проверены временем. А Раст ещё не заслужил.
Rust это как Ada, но с хипсторами. Зачем?
Старые штопаные дыры на новый ЯП? Для нового ЯП нада новое ядро!
Долой монополизм Linux!
Таки есть же Redox
Единственное что не нравится - это лицензия MIT.
Слишком свободная?
Вам смешно а вот лицензия MIT, как то раз покусала, мою бабушку.
Я требую ее запретить!
мы вас услышали, ваша бабушка добавлена в список запрещенных ресурсов.
> Слишком свободная?Для проприертарщиков, от и против пользовуемых.
>пользовуемыхКто пустил на форум пьяного?
И зачем она? Хипстеры для хипстером фигачат? Лучше уж Haiku OS
https://www.redox-os.org/
Те кто умеет разрабатывать ядра то обоходятся и без Rust, им не нужен "безопасный" язык, они должны прекрасно разбираться в том что они делают и зачем. Хотя назвать безопасным язык с unsafe блоками сложно, так как теряется весь смысл этой "безопасности".
> Те кто умеет разрабатывать ядра то обоходятся и без Rust, им не нужен "безопасный" язык,Потому что ядра пишут не люди а роботы, притом пишут сразу на машинном коде, так как не надо тратить время на компиляцию
>> Те кто умеет разрабатывать ядра то обоходятся и без Rust, им не нужен "безопасный" язык,
> Потому что ядра пишут не люди а роботы, притом пишут сразу на
> машинном коде, так как не надо тратить время на компиляциюУ каждого языка свои задачи. И Rust для этой задачи не создавался впринципе. А си был изначально создан для написания переносимого Unixа.
А без unsafe ядро написать получится?
> А без unsafe ядро написать получится?Насколько знаю даже в Redox около 15%.
>Те кто умеет разрабатывать ядра то обоходятся и без Rust, им не нужен "безопасный" языкЗагуглил Linux Kernel уязвимости. Ни одного результата!
Действительно "безопасный" язык не нужен!
> >Те кто умеет разрабатывать ядра то обоходятся и без Rust, им не нужен "безопасный" язык
> Загуглил Linux Kernel уязвимости. Ни одного результата!
> Действительно "безопасный" язык не нужен!Говнокод не перестаёт быть говнокодом даже в безопасных языках. Просто в отличии от C такие языки будут бросать исключение. Но в любом случае это не сделает говнокода конфеткой. Наверное единственная полезная вещь для адекватного программиста: исключить человеческий фактор (опечатался, забыл проверить и т.д).
>Загуглил Linux Kernel уязвимостиГлубокий уровень экспертности
если в ядре линукс нет уязвимостей то те кто его писал просто боги программирования)) просто эти дыры еще не откопали или они не проявили себя напрямую или в составе работы с другими приложениями. идеальный код без дыр... это "Hello World" наверно? :)
> Те кто умеет разрабатывать ядра то обоходятся и без Rust, им не
> нужен "безопасный" язык, они должны прекрасно разбираться в том что они
> делают и зачем. Хотя назвать безопасным язык с unsafe блоками сложно,
> так как теряется весь смысл этой "безопасности".Ну да, ну да. Поэтому в линуксе и остальных ядрах, написанных знатоками ядраписания отсутствуют баги. unsafe вроде как призван обособлять участки кода, подверженные риску. В следствие чего будет проще искать и исправлять баги, потому как уже заранее известно где этот баг мог возникнуть. Нет я не идеализирую Rust и не говорю что это истина в последней инстанции, но почему бы не дать ему шанс... Не понимаю почему все так настроены против Rust да и вообще против всего нового. Не нравится? Не используй. Ведь никто не заставляет.
> Не понимаю почему
> все так настроены против Rust да и вообще против всего нового.
> Не нравится? Не используй. Ведь никто не заставляет.Потому что «новое» не синоним «хорошего». Трудно понять это без подсказки-то?
Есть множество специализированных (если ты понимаешь значение этого слова) языков, некоторым более полувека. На них написаны миллиарды строк кода полезных программ. Обезьяны мечтают всё это скопом упразднить и запретить ради убогого и дефективного by design жлобоскрипта «патамушта на ём лихко песать кот для бровзера».
>[оверквотинг удален]
>> делают и зачем. Хотя назвать безопасным язык с unsafe блоками сложно,
>> так как теряется весь смысл этой "безопасности".
> Ну да, ну да. Поэтому в линуксе и остальных ядрах, написанных знатоками
> ядраписания отсутствуют баги. unsafe вроде как призван обособлять участки кода, подверженные
> риску. В следствие чего будет проще искать и исправлять баги, потому
> как уже заранее известно где этот баг мог возникнуть. Нет я
> не идеализирую Rust и не говорю что это истина в последней
> инстанции, но почему бы не дать ему шанс... Не понимаю почему
> все так настроены против Rust да и вообще против всего нового.
> Не нравится? Не используй. Ведь никто не заставляет.Да я и не против rust, я считаю его отличной заменой C++/C в системном ПО. Но меня напрягают наивные утверждения что если ядро будет написано на rust то никакие угрозы безопасности ему не страшны. Говнокод не зависит от языка, только от рук программиста.
"релиз языка системного программирования Rust 1.31"
Какая система написана на Rust?
Linux
Например, Redox https://www.opennet.ru/opennews/art.shtml?num=46919
Этот самый Redox очень трудно назвать ОС. Если внимательно почитать список его возможностей и ограничений, то оно больше на какую-то демку похоже, чем на ОС. Они не осилили даже работу с дисками, про остальное даже не говорю.
они сравнивают его c C++))) это мило однако. как детский автоматик сравнивать с АК))
Не, не, мы используем в нескольких местах в проде: раст однозначно тащит и разработка несколько проще, чем на С++, но изучить и привыкнуть ушло время. Но в целом думаю за ним будущее.
Ржа, честно говоря, неплохой язык в своей ключевой идее (современный системный ЯП с автоматизацией управления памятью), но реализация и сателлитный шлак просто убивают. У плюсов весьма неуютный синтаксис и неочевидная семантика, и нужно было сильно постараться, чтобы сделать хуже. У Ржи получилось, да так, что смотреть на это без крови в глазах невозможно, а чтение хоть сколько-нибудь сложного кода напоминает изощренную интеллектуальную пытку. Плюс вместо того, чтобы пилить чисто компилятор и отдать все прочее на откуп давно проверенным средствам, они навертели и NIH менеджер пакетов, и NIH систему сборки, и еще кучу всякой херни, которая объективно не нужна и ничем, кроме хипстоты, не выделяется. Тьфу.
> люс вместо того, чтобы пилить чисто компилятор и отдать все прочее на откуп давно проверенным средствамКаким интересно? Скоро 2018 год, а single header либы для плюсов это норма, потому что пакетного менеджера нет, систем сборки N штук.
Как раз сейчас недостаточно сделать просто компилятор. Нужно делать "экосистему" и cargo - это плюс, т.к. инструментарий для сборки, тестирования, бенчмарков, форматирования и т.п. можно развивать вместе с языком, все проекты пользуются единый подход.
> Скоро 2018 год2019 fixed
> потому что пакетного менеджера нетИ не нужен. Есть системный менеджер пакетов, его более чем достаточно. Не надо уподобляться питону, в котором столько всего этого добра наверчено, что аж уже слои абстракции начали городить, чтоб не загаживать поверх загаженного.
> систем сборки N штук
Есть одна система сборки - Make. Она много лет прекрасно работает. У нее один недостаток: NIH. Вот и плодятся как грибы после дождя сначала обертки поверх нее, потом обертки поверх оберток, потом обертки поверх оберток поверх оберток...
> Есть системный менеджер пакетов, его более чем достаточно.При условии, что ты пишешь софт под конкретный дистрибутив.
> Есть одна система сборки - Make. Она много лет прекрасно работает. У
> нее один недостаток: NIH. Вот и плодятся как грибы после дождя
> сначала обертки поверх нее, потом обертки поверх оберток, потом обертки поверх
> оберток поверх оберток...Ну никто тебя не останавливает показать нам свой чудесный makefile, в котором ты собираешь программу кроссплатформенно в разных дистрибутивах, с разными флагами компиляции, разными путями к системным либам.
Потом не забудь убедить весь остальной мир, что показанное тобой - это "нормально".
> Плюс вместо того, чтобы пилить чисто компилятор и отдать все прочее на откуп давно проверенным средствам,Ага, на примере C++ можно увидеть как ваш совет клево работает,
не подскажите почему столько single-header библиотек в C++?
>не подскажите почему столько single-header библиотек в C++?потому что труп страуса не ослилил в модули?
> Ага, на примере C++ можно увидеть как ваш совет клево работает, не подскажите почему столько single-header библиотек в C++?Потому что они слишком маленькие, чтобы их оформлять в полноценную библиотеку? Всякие glm и иже с ними весьма тривиальны.
Менеджер пакетов и система сборки во всех языках свои, ничего необычного в этом нет.
> Менеджер пакетов и система сборки во всех языках свои, ничего необычного в этом нет.Но и ничего хорошего тоже.
И в итоге у тебя в системе стоит 50 менеджеров пакетов в дополнение к системному и 100 сборочных систем вместо одной. И зачем все это? Просто кто-то не осилил сделать по-нормальному.
покажите мне систему сборки, которая одинаково хорошо работает как с джаваскриптом, так и с крестами, перлом и powershell
тогда вам и D понравится))
D как раз так себе и уже не актуален. Rust куда интереснее.
Junior Frontend Developer это явно виднее. Понятный синтаксис если когда-то видел C/C++/C#/Java, грамотно реализованы модули, режим betterC, обширная стандартная библиотека, пакетный менеджер, scope exit, mixin, адекватные шаблоны, CTFE, UFCS, immutable, нормальный const, opDispatch, slices, GC и/или std.allocator под задачу, for & for parallel, foreach в котором сразу есть доступ и к индексу, Unicode, interop вместе с C и что интересно - C++ (что немаловажно, есть куча всего от чего отказаться тяжело)... Это из памяти по быстрому. D очень плохой язык, Вы правы.
D как язык прикольный, но во всех бенчмарках, какие я нашел, результаты были не очень по сравнению с другими языками-конкурентами
WekaIO Matrix (https://www.weka.io/resources/wekaio-matrix). Written in DLang. Лучший benchmark для D когда-либо.
> WekaIO Matrix (https://www.weka.io/resources/wekaio-matrix). Written in DLang. Лучший
> benchmark для D когда-либо.
> UNMATCHED
> PERFORMANCE
> BREAKTHROUGH
> ECONOMICSты точно уверен, что знаешь что такое бенчмарк?
Возможно. Из того что видел, D был на уровне с C & C++. Но помимо, WekaIO Matrix самая быстрая FS на сегодняшний день.
вот здесь у D в среднем по больнице результаты медленнее чем у конкурентов (но тут больше меряют фреймфорки чем сам языки так что это не слишком показательно) https://www.techempower.com/benchmarks/#section=data-r17а вот этот проект по бенчаркингу выглядит адекватно (если почитать требования к реализациям), но нет D: https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (может, попробую портировать одно из решений к наиболее простым задачам на D в свободное время и посмотреть что выйдет)
а всё остальное, что я находил -- это было написано васяном ради чтобы было о чем написать статью (и часто в комментариях указывали на серьезную разницу в реализациях)
так что, не подумай что я утверждаю что D тормоз, но просто хотелось бы больше бенчмарков
> был на уровне с C & C++при использовании BetterC или в штатном режиме со сборщиком мусора?
В общем. Даже с GC. Просто не использовать его как нечеловек. Я никогда не любил его, но нашел удобным на этапе прототипа когда только трогаешь почву на начале. И то у меня было это все дело на начале выполнения приложения, когда уже в глубь то у меня пошел OpenCL и было отлично. Но если кусок тормоз именно из-за GC - std.allocator в руки, но это уже следующий этап да и не всегда необходимо.
Я бы не советовал иммутабельность даже упоминать как фичу D в контексте Rust, который как раз реализован для контролируемой мутации
Но все же immutable есть, хоть это и не основное место в языке. Так же как и @safe или @pure.
Насчет "проще" - это вы, батенька, погорячились. Но сам по себе язык мне нравится, хотя мозги он способен выносить просто великолепно. И производительность в режиме сборки --debug просто 3.14сец.
Будущее у него появится не раньше, чем появится его ANSI/IEEE стандарт. А он не появится до тех пор, пока язык полностью не освободится от авторских и прочих прав.
> пока язык полностью не освободится от авторских и прочих прав.
>от авторских и прочих прав.
>прав.Я вижу, что эо слово д.б.бы быть "ограничений".
Реальность с чёрное-это-белое новоязом пугает, да.
Какие у вас интересные аналогии, милитаристские.
> они сравнивают его c C++))) это мило однако. как детский автоматик сравнивать с АК))Ну детский автоматик здесь C++,
конечно к этому автоматику прикрутили железный ствол,
и каких-то раком остальные части или заменили или заставили работать,
но регулярно все разваливается.
растаман что ли? ))) ну взгляни на свой раст. как ломают совместимости. и еще не скоро перестанут. это проблема всех языков проограммирования, которые только появились. поэтому он и не может похвастать привлекательностью. а мозги то у вас еще детские))
> ну взгляни на свой раст. как ломают совместимостиНу покажи как ломают? В данном посте ввели новую опцию,
без ее включения весь старый код продолжит без проблемы компилироваться,
и этот старый код можно как угодно перемешивать со старым.А C++ такое может? Подсказка библиотеки собранные в режиме c++98 и c++11 gcc
вместе не сможет слинковать, ABI они сломали.Я же говорю детская игрушка этот C++.
всех вас на D))))ахахах
Есть такие вещи, про которые люди хорошо отзываются и рекомендуют их всем, но сами ими не пользуются.Ваш д никому не нужен
я скорее поклонник классического Си. плюсы только как его развитие( несколько зловредное для мозгов). а D так интересовался. я скорее питон выберу.)))( хоть он и интерпретируемый)
Перед Вами стоит прикладная задача?Или вы так просто, студент или предподаватель?
После D, C++ боль. Вечно не хватает электронных вещей на которые отвлекает внимание. Особенно при работе со строками, да и scope exit просто фантастически хороший. Но есть все же одна вещь которая помогает потом при работе с C++. Начинаешь думать по другому и это сказывается на качестве, меньше кода с тем же результатом, да и C++17 начинаешь использовать чаще из-за "не может же эта простая задача решается так глупо" и вынуждает забывать C++98. CTFE, UFCS, property, UDA, compile time introspection не хватает, но хоть в общем на C++17 становится легче.
> А C++ такое может?Может. Пожалуй, самая большая поломка обратной совместимости за всю историю стандартизованного C++ -- удаление std::auto_ptr (и триграфов, если у кого-то был настолько старый код) в C++17. В остальном же никто не запрещает взять код на C++98, добавить в него чего-нибудь из C++11 и собрать всё это в режиме C++17.
Обратная совместимость ABI на совести разработчиков компиляторов, язык тут не при чём.
> язык тут не при чём.А разве не язык заставляет name mangling делать?
Нет, не язык. Это расплата за возможность пользоваться теми же самыми компоновщиками, что и C, вместо того, чтобы городить новые специальные для одного единственного языка.
> А разве не язык заставляет name mangling делать?Алгоритм name mangling-а, раскладка классов/структур в памяти и прочие элементы ABI стандартом не регламентируются (некоторые требования всё-таки есть, но в контексте этого обсуждения они несущественны), каждый компилятор волен делать их по-своему.
>> А C++ такое может?
> Может.Где? Пересобрать все в режиме C++17 это не то о чем я спрашивал.
Я спрашивал можно ли часть объектников собрать в режиме c++03, часть в c++11,
а остальное в c++17 и потом слинковать и чтобы все это заработало корректно?Впрочем из вашего ответа очевидно что не может, так кто ломает совместимость?
как какая? mozilla firefox. В принципе ничего система, браузер вот скоро заменят на хромиум, и вообще будет шикарно.
firefox quantum
servo
Servo
Cистема контроля версиями pijul, например.
> Редакция "2015" включает уже стабилизированную к текущему моменту функциональность и все будущие изменения не нарушающие совместимость, а редакция "2018" дополнительно охватывает нарушающие совместимость новшества,Можно было бы не портить традицию и использовать "2.x" и "3.x" для обозначения разных, не совместимых между собой, веток языка.
> Можно было бы не портить традицию и использовать "2.x" и "3.x" для обозначения разных, не совместимых между собой, веток языка.ну вообще это версия компилятора (1.31), а версия языка 2018,
и компилятор 1.31 поддерживает и 2015 и 2018 варианты,
и может собрать проект из разных (crate) которые вперемешку написаны на 2015 и 2018
Правильно, и пусть пользователь гадает, почему у него при минорном обновлении с 1.30 на 1.31 все сломалось. Впрочем, растаманам не привыкать, походу...
А почему при обновлении компилятора должно что-то ломаться? Старый код без аннотации "компилируй меня в 2018 редакции" будет компилироваться по-старому; обратная совместимость на уровне компилятора не нарушена, только на уровне синтаксиса.
>> Можно было бы не портить традицию и использовать "2.x" и "3.x" для обозначения разных, не совместимых между собой, веток языка.
> ну вообще это версия компилятора (1.31), а версия языка 2018,Ну вообще-то версия языка и обыгрывалась (просто у того ЯП версия эталонного _компилятора_ совпадает с поддерживаемой версией ЯП) ;).
> Можно было бы не портить традицию и использовать "0.2.x" и "0.3.x" нестабильных (тех, в которых всё меняется каждые несколько месяцев) веток языка.почин
Qt не хватает
Вот да. Прикрутили бы, писал бы.
а то что кути постоянно ломают совместимость не страшно? хотя для небольших проектов самое то.
> а то что кути постоянно ломают совместимость не страшно? хотя для небольших проектов самое то.С чего вдруг? В течении мажорной версии они не то что API, ABI не ломают.
Дык и сам Rust постоянно меняют. Тут ведь как выходит что не новая версия руки в ноги и опять все перехерачивать. То ли дело Си с его обратной совместимостью код 89 года собирает и даже варнинги не валт
> Дык и сам Rust постоянно меняют.
> Тут ведь как выходит что не новая версия руки в ноги и опять все перехерачиватьИ что именно они ломают? С 1.0 только добавляли новый функционал, не ломая уже существующий.
https://azul.rs/
Зачем? WPF или WinForms надо.
https://github.com/KDE/rust-qt-binding-generator
Теперь "кедораст" не будет считаться ругательством?
ахахах упал со стула))) теперь все будут боле осмотрительны со словами)))ахахах
https://hacks.mozilla.org/2018/12/rust-2018-is-here/
"Stuffing my head with code, then turning it into codecartoons" на этом, пожалуй, и закончим.
Clippy столько исправлений выявил! Очень крутая штука, даже баг помог найти
Rust уже написан на Rust...
Может на Go его переписать?..
Любой язык - подмножество Perl ©
Кто-то забыл про десятое правило Гринспена.
Для хыпстоты самое то, люди же продолжут писать на c/c++.
продолжат*
Хипстерский не люди? Ей богу, фошызм какой-то
Да хипстота ваши плюсы, люди продолжат писать на Каболе.
кОболе, хипстота )
Вот только любой новый стандарт C++ переносит костыльные реализации раста двух-трехлетней давности, и то в виде отвратительной STL, да еще и часто с ненулевой стоимостью.
А си будет жить, правда в основном лишь там, где еще недавно писали только на асме и в компактных инструментах вроде стандартных консольных утилит
Раст создали для того чтобы все знали что может быть ещё хуже и писали дальше бы на С++.
>Запущены инициативы по оптимизации Rust для предметно-ориентированных областей.а gui?
https://azul.rs/
Спасибо!
Надо будет посмотреть, что это такое.
Какой-то ад, в релиз не собирающийся и, похоже, не способный выглядеть хоть сколько-нибудь нативно
Да, один из недостатков раста - молодость и недостаток стабильных решений. Все быстро развивается. Тот же azul основан на webrender, который 3 недели назад ушел в бету.Впрочем, молодость - это единственный недостаток, который устраняется сам по себе, с течением времени.
http://relm.ml/relm-intro
Не нужно.
Правила статического анализатора раста приводят в бешенство при использовании гтк. И хочется какого-никакого паттерна, чтобы были вьюхи, модели, и чтобы не начинать каждый мелкий проект с написания велосипеда MVC
> предметно-ориентированных областейСпасибо тебе автор за грамотные термины, как бальзам на душу.