Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Как одно из событий 2015, можно также упомянуть активное развитие крутейшей IDE для rust.
Недавно была хорошая статья о том, для кого и зачем сделан язык Go. ИМХО не помешала бы такая же о Rust.
За что минусы-то, да ещё и в карму?.. Я ж ничего обидного про Rust не сказал!
Раст сделан для тех, кто пишет на С и С++ и хочет делать это лучше ценой дополнительной нагрузки на программиста.
В принципе, все.
В принципе, все.
Я так понимаю уже будет ломающая некоторые пакеты 1.7 версия users.rust-lang.org/t/upcoming-breakage-starting-in-rust-1-7-from-rfcs-1214-and-136/4207
Ну ломает она очень небольшое количество пакетов, в 99% случаев никто это не почувствует.
Да и изменения там в принципе только исправляют некорректное поведение языка: раст позволял делать вещи, которые не должен был позволять делать в принципе.
Да и изменения там в принципе только исправляют некорректное поведение языка: раст позволял делать вещи, которые не должен был позволять делать в принципе.
Выпускать новые на 100% обратно совместимые версии языка практически невозможно. Например, простое добавление одного нового метода в стандартной библиотеке может в очень редких случаях сломать кому-то код – если он до этого объявил свой типаж с таким же методом и реализовал его для этого типа. А добавление нового приватного поля может повлиять на ABI-совместимость.
Разработка Rust мне нравиться тем, что во-первых они постулируют принципы, по которым можно определить, какие изменения приемлемы для минорного релиза, а какие нет. Во-вторых, в случае с минорными обратно-несовместимыми изменениями компилятор за 2 релиза начинает выдавать предупреждение для кода, который сможет сломаться в будущем, с объяснением проблемы и рекомендацией, как ее можно избежать.
Ну и в третьих, разработчики Rust тестируют как добавление обратно несовместимого изменения отразиться на всей экосистеме, буквально компилируя все публичные пакеты новой версией языка и прогоняя для них тесты. Насколько я знаю, это беспренцендентное решение. Иногда бывало такое, что Steve Klabnic (один из core разработчиков Rust) сам заранее рассылал PR тем проектам, у которых может сломаться код в следующих версиях Rust.
Разработка Rust мне нравиться тем, что во-первых они постулируют принципы, по которым можно определить, какие изменения приемлемы для минорного релиза, а какие нет. Во-вторых, в случае с минорными обратно-несовместимыми изменениями компилятор за 2 релиза начинает выдавать предупреждение для кода, который сможет сломаться в будущем, с объяснением проблемы и рекомендацией, как ее можно избежать.
Ну и в третьих, разработчики Rust тестируют как добавление обратно несовместимого изменения отразиться на всей экосистеме, буквально компилируя все публичные пакеты новой версией языка и прогоняя для них тесты. Насколько я знаю, это беспренцендентное решение. Иногда бывало такое, что Steve Klabnic (один из core разработчиков Rust) сам заранее рассылал PR тем проектам, у которых может сломаться код в следующих версиях Rust.
Конечно, я этим согласен. Я это указал, не чтоб как то поругать раст, а для общей информации, там довольно детальное изложение с формулами есть, возможно кому-то интересно будет почитать.
Без проблем, просто из вашего комментария можно сделать вывод, что у Rust серьезные проблемы с обратной совместимостью, хотя на самом деле это не так. Мало кто так сильно заботиться об обратной совместимости, как это делает сегодня команда Rust. Именно по-этому любая мелкая обратная несовместимость явно декларируется и обсуждается.
Ну зачем Rust такая гадость, как исключения? Требую их исключить!
Формально это не исключения, а просто дополнительный сахар для паттерн матчинга на Result с ранним возвратом. Дальнейшее развитие макроса try! по сути. Хотя лучше бы они, ИМХО, работали над HKT и монадическими комбинаторами.
Нужда в сборке мусора мне тоже непонятна. Зачем заслонять киллер-фичу borrow-checker'а попсовым GC? Ну не конкурировать Rust'у с Go/Java/C#/Python, зачем лезть не в свою нишу?
Опять же не путайте GC как неотъемлемую часть рантайма языка, и как опциональную библиотеку. Никто в сам раст GC впиливать не собирается. Будет отдельная либа для сборки мусора, как в Си++. Сейчас проблема в том, что нет красивого стабильного синтаксиса указать, какой конкретно аллокатор использовать при размещении данных в куче, есть по факту только Box, который всегда юзает дефолтный аллокатор (jemalloc). В язык просто добавят синтаксис, позволяющий размещать переменные не только напрямую через malloc на куче, но и под контролем GC, который можно выбрать любой, не выбирать вообще, или выбрать несколько разных и использовать вместе по потребностям.
Всё равно не вижу большой проблемы. Ну появится тип Gc<T>, наравне с Rc<T>, Arc<T> и Box<T>, ну и что? Семантика работы с ним будет аналогичная, использование — только явное, то есть не будет так, что ты делаешь
let x = 123; и оно внезапно подхватывается актичным сборщиком мусора, который будет следить за x.Понятно, что внутре будет не просто одна только неонка, а сложная алгоритмически-ёмкая реализация, но для пользователя языка это просто новый синтаксис.
Ну и сборка мусора и аллокаторы на самом деле тесно связанные вещи, поскольку хип, управляемый сборщиком мусора, всё равно хип, и по сути имеет интерфейс аналогичный malloc/realloc/dealloc. Разница в том, что управляет этим хипом: сам программист, или какой-то хитрый алгоритм за сценой.
Ну и сборка мусора и аллокаторы на самом деле тесно связанные вещи, поскольку хип, управляемый сборщиком мусора, всё равно хип, и по сути имеет интерфейс аналогичный malloc/realloc/dealloc. Разница в том, что управляет этим хипом: сам программист, или какой-то хитрый алгоритм за сценой.
Мне, просто, кажется, что GC — это фундаментальная вещь, влияющая на стиль кодирования. Если такая библиотека взлетит, то это деформирует семантику языка (я не про его ядро, а про способ мышления им), изменит направленность community, а также отвратит низкоуровневых разработчиков (поскольку будет написана туча GC-based кода, который и станет стандартом de-facto). Впрочем, я могу ошибаться, поглядим, что из этого получится.
Во-первых, для С тоже есть кучу библиотек, реализующих GC, и ничего, вроде бы никто еще не забыл, что на C можно писать без сборщика мусора.
Во-вторых, если кому-то хочеться писать свои проекты с использованием GC, но при этом пользоваться теми приемущиствами, которые дают библиотеки Rust, то почему бы и нет? Главное, чтобы такое нововведение не помешало системному программированию, но я не думаю, что с этим будут хоть какие-то проблемы.
Особенность Rust в данном случае в том, что для него создать полноценный и опциональный GC гораздо сложнее, ведь Rust дает гораздо больше гарантий, чем C, а это значит, что компилятор и GC должны каким-то образом договариваться и проверять, что эти гарантии выполняются. Сложности начинаются там, где соприкасается код с GC и код, который управляеться borrow cheker'ом.
Во-вторых, если кому-то хочеться писать свои проекты с использованием GC, но при этом пользоваться теми приемущиствами, которые дают библиотеки Rust, то почему бы и нет? Главное, чтобы такое нововведение не помешало системному программированию, но я не думаю, что с этим будут хоть какие-то проблемы.
Особенность Rust в данном случае в том, что для него создать полноценный и опциональный GC гораздо сложнее, ведь Rust дает гораздо больше гарантий, чем C, а это значит, что компилятор и GC должны каким-то образом договариваться и проверять, что эти гарантии выполняются. Сложности начинаются там, где соприкасается код с GC и код, который управляеться borrow cheker'ом.
Если стандартная библиотека и заметное количество сторонних библиотек не будут использовать сборку мусора, то ни кого дополнительная возможность не отпугнет. Но может привлечь большое количество программистов, которым жесткие гарантии (по времени и памяти) требуются редко, а производительность и, особенно, надежность важны.
А в C++ есть сборка мусора? О_о
Для нормального (не консервативного) Gc от компилятора нужна метаинформация о типах — что бы знать, где указатели на управляемые Gc объекты, а где данные и прочие указатели. Иначе сборка мусора будет тормозить и может не все собрать.
Что бы проще было писать интерпретаторы языков с Gc.
Кроме того Gc во многих важных случаях эффективнее Rc. Если пытаться все сводить к borrow-checker, то Rc тоже надо бы выкинуть.
Кроме того Gc во многих важных случаях эффективнее Rc. Если пытаться все сводить к borrow-checker, то Rc тоже надо бы выкинуть.
github.com/glaebhoerl/rfcs/blob/trait-based-exception-handling/active/0000-trait-based-exception-handling.md — отстой!
Нужна do-нотация просто и монады.
Нужна do-нотация просто и монады.
Самое смешное, что как раз do-нотация есть в виде макроса. Проблема в том, что она недостаточно общая, нельзя её написать для всех монад сразу без HKT, нужно реализовать отдельно для каждого монадического типа. А HKT вводить не торопятся.
На самом деле этот RFC довольно спорный, есть разные мнения на его счёт. Мне самому он не очень нравится, но как решит core team, так в итоге и будет.
На самом деле этот RFC довольно спорный, есть разные мнения на его счёт. Мне самому он не очень нравится, но как решит core team, так в итоге и будет.
Это полный отстой: сейчас зафиксируют стремный синтаксис, а потом назад фиг вернешься: совместимость же. По мне так к черту, я не парюсь по поводу написания пары лишних строк для обработки ошибок: после Go вообще эта проблема не напрягает, а вот увидеть нормальный фикс в удаленном будущем без уродского C#-синтаксиса, который, конечно же, придется поддерживать, я хочу.
Я рекомендую перечитать обсуждение этого RFC, там все это горячо и глубоко обсуждается со всех возможных ракурсов. Меня тоже по-началу коробило от такого решения, но сейчас есть ощущение, что все-таки это наилучший вариант, хоть он и ломает немного систему координат тем, кто достаточно долго пишет на Rust.
использование Cargo для сборки rustc?
try!(использованиеCargoДляСборкиRustc())
Бессовестный самопиар: я опубликовал на Udemy курс по Rust.
Надеюсь, хоть IndexAssign (https://github.com/rust-lang/rust/pull/25628) скоро одобрят, а то с хештаблицами сейчас работать не слишком удобно.
Ну судя по тому, что в доках стабильного раста появились всякие AddAssign, оно уже там, дело за малым. Думаю, скоро стабилизируют.
Это не для индексов же. Я хочу возможность нормально писать `&mut map[key]` (по аналогии со сто лет как работающим `&map[key]`), а не `map.get_mut(key).expect(«TODO: добавить обработку ошибок по вкусу»)`. :(
Для этого ведь достаточно реализации IndexMut. Для меня загадка, почему он не реализован для мапов.
Реализацию IndexMut специально убрали когда-то, как раз в ожидании IndexAssign:
https://github.com/rust-lang/rust/pull/23559
https://github.com/rust-lang/rust/pull/23559
This commit removes the IndexMut impls on HashMap and BTreeMap, in order to future-proof the API against the eventual inclusion of an IndexSet trait.
Ideally, we would eventually be able to support:
map[owned_key] = val; map[borrowed_key].mutating_method(arguments); &mut map[borrowed_key];
but to keep the design space as unconstrained as possible, we do not currently want to support IndexMut, in case some other strategy will eventually be needed.
Code currently using mutating index notation can use get_mut instead.
Вроде бы этот RFC недавно был на стадии final comment period, так что наверняка добавят, не думаю что там что-то сложное.
Нихрена себе! Так какой-то Lua получается. Непривычно для меня, но выглядит классно!
Меньше чем за год «стабильности» они сломали 4% пакетов? Отличная стабильность, что тут скажешь
Речь идет о работоспособности кода, написанного конкретно под Rust 1.0, но скпомпилированного с помощью Rust 1.5, а не о поломке пакетов. Конечно, абсолютное большинство из этих 4% пакетов были обновлены и исправлены для работоспособности на старших версиях. И да, это отличный результат.
Отличный результат, говорите? 100% кода, написанного под Java 1.0 в 1996 году, компилируется с помощью Java 8.
Вы чушь говорите. Что, с 1996 года в java не зарезирвировали ни одного нового ключевого слова, которое в старых библиотеках могло использоваться как имя переменной? Или ни в один класс из стандартной библиотеки не добавили ни одного нового метода, которой мог быть объявлен в старых библиотеках в наследуемом классе без override? Или не добавили ни одного нового класа, который конфликтовал бы по имени с пользовательским класом при wild card import?
У меня вылезали проблемы совместимости oracle jdk7 vs oracle jdk8, чё уж там.
Простой пример — jboss as 7 не запускался на jdk8, но запускался на jdk7.
Другой пример — sbt, ant и maven (при использовании определенных плагинов) могут вести себя по разному на разных версиях jdk. Например, sbt 0.11 (если правильно помню) не работал при запуске на 8 jre. Плагины под ant и maven, использовавшие rhino в качестве ScriptingEngine падали под 8, т. к. у nashorn другая api (со стороны js).
Простой пример — jboss as 7 не запускался на jdk8, но запускался на jdk7.
Другой пример — sbt, ant и maven (при использовании определенных плагинов) могут вести себя по разному на разных версиях jdk. Например, sbt 0.11 (если правильно помню) не работал при запуске на 8 jre. Плагины под ant и maven, использовавшие rhino в качестве ScriptingEngine падали под 8, т. к. у nashorn другая api (со стороны js).
Мы говорим про совместимость компиляции, а не рантайма.
Тогда ок, я-то предполагал, что под работоспособностью выше имелась ввиду работоспособность полученного после компиляции, а не возможность просто скомпилировать.
Тогда в качестве примера скорее подойдёт scala, где использование новых нестабильных фич языка или хитрых приёмов с типами приводит к невозможности сборки новой версией компилятора.
Поглядев на libstd я отметил, что там пока ещё довольно много кода, отмеченного, как нестабильный, не говоря уже про libcore (который интересен в embedded). И те библиотеки, которые зависят от него вполне могут страдать. Язык-то активно развивается. С виду даже быстрее, чем скала между 2.9 и 2.10.
Тогда в качестве примера скорее подойдёт scala, где использование новых нестабильных фич языка или хитрых приёмов с типами приводит к невозможности сборки новой версией компилятора.
Поглядев на libstd я отметил, что там пока ещё довольно много кода, отмеченного, как нестабильный, не говоря уже про libcore (который интересен в embedded). И те библиотеки, которые зависят от него вполне могут страдать. Язык-то активно развивается. С виду даже быстрее, чем скала между 2.9 и 2.10.
Ок, формально не 100% совместимость…
С Java 1.0 было добавлено 3 ключевого слова: assert, enum и strictfp. Не очень распространенные слова для идентификаторов, мягко говоря.
Добавление метода без
Добавление методов таки может сломать совместимость, если появляется неоднозначность, например, был метод foo(Interface1), добавлен foo(Interface2), а где-то в коде вызывается foo(obj), где obj наследует и Interface1, и Interface2.
Но вероятности этого опять же очень-очень малы. Всяко меньше 4% пакетов за год
С Java 1.0 было добавлено 3 ключевого слова: assert, enum и strictfp. Не очень распространенные слова для идентификаторов, мягко говоря.
Добавление метода без
@Override (который сам по себе был добавлен в Java 6) разрешено (это только предупреждение, а не ошибка компиляции, опять же, до Java 6 даже предупреждения не было).Добавление методов таки может сломать совместимость, если появляется неоднозначность, например, был метод foo(Interface1), добавлен foo(Interface2), а где-то в коде вызывается foo(obj), где obj наследует и Interface1, и Interface2.
Но вероятности этого опять же очень-очень малы. Всяко меньше 4% пакетов за год
Может вы и говорите о совместимости компиляции, но Brian Anderson в своем посте говорил о совместимости всей инфраструктуры, включая компилятор, менеджер пакетов, стандартную библиотеку, и компилируемость всех зависимостей тестируемой библиотеки.
Всех этих причин достаточно, чтобы ломать совместимость серьезных библиотек. Я буду очень удивлен, если хотя бы половина полноценных библиотек, а не программ на 100 строк, неизменявшихся с Java 1.0 будет успешно скомпилирована и корректно работать в инфраструктуре Java 8. Я не удивлюсь, если тест провалят 90% библиотек.
Может быть 4% меньше чем за год – это действительно много, учитывая, скажем так, размеренность жизни в мире Java. Я рекумендую вам измерять такие вещи не временными промежутками, а количеством изменений, произошедших за это время. А то может получиться, что самым стабильным языком у нас будет COBOL.
С Java 1.0 было добавлено 3 ключевого слова: assert, enum и strictfp. Не очень распространенные слова для идентификаторов, мягко говоря.Но достаточная причина для того, чтобы сломать компиляцию, встретившись хотя бы один раз в исходном коде библиотеки или любой ее зависимости.
Добавление метода без Override (который сам по себе был добавлен в Java 6) разрешено (это только предупреждение, а не ошибка компиляции, опять же, до Java 6 даже предупреждения не было).Ок, я забыл что override в Java это не ключевое слово. Тем не менее, просто подумайте, как переопределение метода «в слепую» может повлиять на работу кода, который использует этот метод, в том числе на код из стандартной библиотеки.
Всех этих причин достаточно, чтобы ломать совместимость серьезных библиотек. Я буду очень удивлен, если хотя бы половина полноценных библиотек, а не программ на 100 строк, неизменявшихся с Java 1.0 будет успешно скомпилирована и корректно работать в инфраструктуре Java 8. Я не удивлюсь, если тест провалят 90% библиотек.
Может быть 4% меньше чем за год – это действительно много, учитывая, скажем так, размеренность жизни в мире Java. Я рекумендую вам измерять такие вещи не временными промежутками, а количеством изменений, произошедших за это время. А то может получиться, что самым стабильным языком у нас будет COBOL.
В конце концов, можете просто пролистать вот этот список.
Я не думаю, что разработчики только одной Java-библиотеки из 20 сделали хотя бы одно изменение только для того, что бы библиотека начала работать в новой версии Java.
Я не думаю, что разработчики только одной Java-библиотеки из 20 сделали хотя бы одно изменение только для того, что бы библиотека начала работать в новой версии Java.
Попадался унаследованный код под java 1.5, который не собирался под 1.6 и 1.7 из-за пропвыших пакетов из sun.*.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Rust в 2016 году