Pull to refresh
3
0
Андрей Кутейко @andy128k

User

Send message

Всё же лучше использовать более "всеядный" `Result<T, Box<dyn Error>>` или Error из крейта anyhow. Он больше похож на джавовский RuntimeException.

Строка может быть преобразована в `Box<dyn std::error::Error>` и поэтому можно писать `Err("Division by zero".into())`.

Вовсе нет. TypeScript это основной язык AWS CDK. При этом использование TypeScript и/или JavaScript в serverless архитектуре оказывается очень даже уместным.

Поэтому мы передаём аллокатор методу init, но не передаём его циклу событий.

Что мешает методу init сохранить аллокатор в объекте?

Ждать следующий пост про саундбары для бабушек?

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/>`. Но в обоих случаях браузеру нужно загружать все стили.

Разве для тех же CSS-модулей ситуация не такая же?

В польском языке есть такое же слово -- dziadkowie. От слова dziadek -- дед.

Не один. Когда я в очередной раз разломал свой покетбук, то следующий брал намеренно без сенсорного экрана.

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

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

Потому что Rust это практичный компромисс между полным отсутствием проверок (С/С++) и слишком сложными и медленными системами доказательств.


И, как показывает опыт, компромисс вполне удачный. Этого самого unsafe кода исчезающе мало по сравнению с остальным кодом.

Ну можно впасть в крайность и разметить весь код как unsafe. И даже в этом случае получится язык более безопасный чем C/C++.


Процитирую мануал. В unsafe коде можно дополнительно делать:


  • разыменовывать указатель
  • вызывать другой unsafe код
  • обращаться к глобальным переменным
  • реализовывать unsafe traits
  • использовать union-ы

Всё! Все остальные инварианты и проверки сохраняются, в том числе и пресловутый borrow checker.

https://www.areweguiyet.com/ — вот тут собирают информацию о состоянии GUI в Rust.


Из личных наблюдений — есть очень приличный 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) это вообще не проблема. А в статических обходятся рефлексией и кодогенерацией, если нужно.


Можно ещё было бы вспомнить экзотику вроде комбинаторов методов. Но не будем :)

Information

Rating
Does not participate
Location
Донецк, Донецкая обл., Украина
Date of birth
Registered
Activity