Rust накладывает на программиста больше ограничений чем C++. И компилятору вроде как "проще" от этого.
Сишный компилятор тут как эталон. Rust сделан как фронтенд к LLVM. Точно так же сделан и Clang. И значит их можно как-то сравнивать в этом поле. Гипотеза (и вроде есть примеры) в том что Rust может передать тому же LLVM больше информации о коде чем Сlang.
Чаще всего за уверенностью в надёжности кода стоит недоинформированность. Тесты может и не единственный способ и даже может не самый лучший, но единственный измеримый.
Чтобы CSS был отдельным файлом тот же webpack нужно отдельно настраивать. По-умолчанию стандартная связка style-loader/css-loader помещают стили в JS бандл.
> css in js это просто неоправданно срать в коде
Когда-то так же говорили про JSX, якобы это "html in js"
> срать в бандле итоговом.
Не уверен что это недостаток. С помощью того же url-loader картинки бандлят. Иногда может быть удобно иметь приложение в виде одного файла, например для встраивания.
Не знаю деталей про styled components, но вроде бы есть аналогичные библиотеки которые позволяют извлечь CSS (google подсказывает linaria и astroturf, может есть и другие). Так что я бы не стал обобщать на весь "css in js".
Ну а разве styled components делает что-то другое? Вроде как он тоже генерирует CSS и классы для селекторов, и так же генерирует `<style/>` узел в `<head/>`. Ну разве что в случае модулей это будет `<link/>`. Но в обоих случаях браузеру нужно загружать все стили.
Во многих местах хорошей практикой (а иногда и обязательной) является указание ссылки на тикет в той же Jira в комментарии к коммиту. Это помогает понять не только сам код, но и причины его написания.
Из личных наблюдений — есть очень приличный gtk-rs (привязка к gtk3), куча обвязок вокруг WebView, и написанные с нуля библиотеки со скупыми наборами виджетов.
Так в том и дело, что весь код проверять и не надо. Только unsafe блоки. В них обычно пишут больше всевозможных проверок и покрывают их тестами.
Я уже года 4 пишу на расте и за всё время мне unsafe понадобился всего пару раз. Это были переписывания с C/C++ на раст и такой код был временным клеем. Как только последняя функция была переписана на расте — он удалялся. И в чистом коде на расте никакого unsafe уже не было.
Ну и важно понимать, что даже unsafe раст намного безопаснее C/C++. У компилятора есть проверки которые он выполняет всегда (safe и unsafe) и проверки которые доступны только в safe. Это всего лишь означает, что компилятор не может сделать это сам и требуется помощь человека (обычно это означает, что нужны тесты для этого куска кода).
Вот это точно не про Common Lisp. Язык, который появился в результате слияния разных диалектов от разных вендоров. При этом каждый вендор тащил туда свою специфику.
REPL Driven Development выбивается из современной практики ведения истории кода в VCS. Дампы состояния интерпретатора (ну или лисп-машины) на роль версий не подходят никак. А уж про коллективную разработку и речи нет.
Хотрелоад есть много где. Erlang, JRebel для Java, Spring gem в Ruby on Rails, Webpack dev server для JS-а.
Компиляция в бинарник с рантаймом? Это скорее похоже на выдачу единственного что лиспы умеют за преимущество. А вот нормального tree shaking не завезли. Но если уж так хочется всё запаковать, то тот же докер-контейнер с любым интерпретатором вполне на эту роль подойдёт.
Про макросы я уже написал выше, там где они нужны, они есть (Rust, Scala), а в динамических языках и без них обходятся. Даже в Clojure макросы хоть и есть, их используют крайне редко.
Разные парадигмы в одном языке. Разве этим хоть кого-то можно удивить? Все более-менее популярные языки такие. Если же взять избитый лисперами пример про Prolog внутри лиспа, то вот пожалуйста — http://minikanren.org/ реализации на любой вкус.
Про рестарты тоже уже написал выше. Они необычные, но вот полезные ли? То что они делают достигается простой передачей замыкания.
Из перечисленного только макросы интересны и они (или другие инструменты кодогенерации) появились в других языках (макросы в Rust, Sweet.js/Babel в JS, и, простите, Lombok в Java).
Рестарты это сомнительная вещь сама по себе. Она запутывает поток выполнения и не известно как будет работать и будет ли вообще в многопоточных приложениях.
MOP переоценён. В любом динамическом языке (Python, Ruby, JS) это вообще не проблема. А в статических обходятся рефлексией и кодогенерацией, если нужно.
Можно ещё было бы вспомнить экзотику вроде комбинаторов методов. Но не будем :)
С Лиспом всё так. Вот только ему нечего предложить в современном мире по сравнению с другими языками. Он уже давно не "элегантное супероружие джедая". Многие языки впитали из него достаточное количество свойств. А те что остались, либо не сильно нужны, либо и вовсе вредны. А та же гомоиконность оказалась переоценённой.
ТВ для «любимой бабули» или куда смотреть, если нужен хороший вариант
Ждать следующий пост про саундбары для бабушек?
«Rust – не Си на стероидах. Чтобы его изучить, нужно избавиться от предрассудков»
Rust накладывает на программиста больше ограничений чем C++. И компилятору вроде как "проще" от этого.
Сишный компилятор тут как эталон. Rust сделан как фронтенд к LLVM. Точно так же сделан и Clang. И значит их можно как-то сравнивать в этом поле. Гипотеза (и вроде есть примеры) в том что Rust может передать тому же LLVM больше информации о коде чем Сlang.
Есть ли жизнь без тестов?
Чаще всего за уверенностью в надёжности кода стоит недоинформированность. Тесты может и не единственный способ и даже может не самый лучший, но единственный измеримый.
Оживляем картинку шейдерами или программирование абстрактного текста
Вот она какая, прикладная каббала! Интересно было бы разобраться в коде.
Styled Components — идеальная стилизация React-приложения
Чтобы CSS был отдельным файлом тот же webpack нужно отдельно настраивать. По-умолчанию стандартная связка style-loader/css-loader помещают стили в JS бандл.
> css in js это просто неоправданно срать в коде
Когда-то так же говорили про JSX, якобы это "html in js"
> срать в бандле итоговом.
Не уверен что это недостаток. С помощью того же url-loader картинки бандлят. Иногда может быть удобно иметь приложение в виде одного файла, например для встраивания.
Не знаю деталей про styled components, но вроде бы есть аналогичные библиотеки которые позволяют извлечь CSS (google подсказывает linaria и astroturf, может есть и другие). Так что я бы не стал обобщать на весь "css in js".
Styled Components — идеальная стилизация React-приложения
Ну а разве styled components делает что-то другое? Вроде как он тоже генерирует CSS и классы для селекторов, и так же генерирует `<style/>` узел в `<head/>`. Ну разве что в случае модулей это будет `<link/>`. Но в обоих случаях браузеру нужно загружать все стили.
Styled Components — идеальная стилизация React-приложения
Разве для тех же CSS-модулей ситуация не такая же?
Непереводимые английские слова, которых нам реально не хватает
В польском языке есть такое же слово -- dziadkowie. От слова dziadek -- дед.
Обзор Onyx Boox Volta 3: электронная книга с сенсорным экраном E-Ink-Carta, Wi-Fi и Bluetooth
Не один. Когда я в очередной раз разломал свой покетбук, то следующий брал намеренно без сенсорного экрана.
Очень сильно раздражало то что случайные касания воспринимались как жесты и, например, менялся размер шрифта.
Уходим с Mercurial на Git
Во многих местах хорошей практикой (а иногда и обязательной) является указание ссылки на тикет в той же Jira в комментарии к коммиту. Это помогает понять не только сам код, но и причины его написания.
Почему вы должны попробовать Rust
Потому что Rust это практичный компромисс между полным отсутствием проверок (С/С++) и слишком сложными и медленными системами доказательств.
И, как показывает опыт, компромисс вполне удачный. Этого самого unsafe кода исчезающе мало по сравнению с остальным кодом.
Почему вы должны попробовать Rust
Ну можно впасть в крайность и разметить весь код как unsafe. И даже в этом случае получится язык более безопасный чем C/C++.
Процитирую мануал. В unsafe коде можно дополнительно делать:
Всё! Все остальные инварианты и проверки сохраняются, в том числе и пресловутый borrow checker.
Почему вы должны попробовать Rust
https://www.areweguiyet.com/ — вот тут собирают информацию о состоянии GUI в Rust.
Из личных наблюдений — есть очень приличный gtk-rs (привязка к gtk3), куча обвязок вокруг WebView, и написанные с нуля библиотеки со скупыми наборами виджетов.
Почему вы должны попробовать Rust
Так в том и дело, что весь код проверять и не надо. Только
unsafeблоки. В них обычно пишут больше всевозможных проверок и покрывают их тестами.Я уже года 4 пишу на расте и за всё время мне unsafe понадобился всего пару раз. Это были переписывания с C/C++ на раст и такой код был временным клеем. Как только последняя функция была переписана на расте — он удалялся. И в чистом коде на расте никакого unsafe уже не было.
Ну и важно понимать, что даже unsafe раст намного безопаснее C/C++. У компилятора есть проверки которые он выполняет всегда (safe и unsafe) и проверки которые доступны только в safe. Это всего лишь означает, что компилятор не может сделать это сам и требуется помощь человека (обычно это означает, что нужны тесты для этого куска кода).
Что не так с Лиспом?
Вот это точно не про Common Lisp. Язык, который появился в результате слияния разных диалектов от разных вендоров. При этом каждый вендор тащил туда свою специфику.
Что не так с Лиспом?
Перенимать всё же стоит полезные и уместные фичи.
Что не так с Лиспом?
Из перечисленного только макросы интересны и они (или другие инструменты кодогенерации) появились в других языках (макросы в Rust, Sweet.js/Babel в JS, и, простите, Lombok в Java).
Рестарты это сомнительная вещь сама по себе. Она запутывает поток выполнения и не известно как будет работать и будет ли вообще в многопоточных приложениях.
MOP переоценён. В любом динамическом языке (Python, Ruby, JS) это вообще не проблема. А в статических обходятся рефлексией и кодогенерацией, если нужно.
Можно ещё было бы вспомнить экзотику вроде комбинаторов методов. Но не будем :)
Что не так с Лиспом?
С Лиспом всё так. Вот только ему нечего предложить в современном мире по сравнению с другими языками. Он уже давно не "элегантное супероружие джедая". Многие языки впитали из него достаточное количество свойств. А те что остались, либо не сильно нужны, либо и вовсе вредны. А та же гомоиконность оказалась переоценённой.
Что не так с Лиспом?
Статья ссылается на Debian Woody, который вышел в 2002-ом и был актуален до 2006-го.
Размышления о Rust
Пока
!не стабилизирован, но его можно либо определить самостоятельно (как пустой enum) либо воспользоваться крейтом never.