Средняя плотность - это как средняя плотность земли в сфере геостационарной орбиты..
Не кажется ли нелогичным, что когда звезда коллапсирует в нейтронную, то у нее ахренеть какая плотность, а у ЧД вдруг мы считаем среднюю по её горизонту событий? Да, свет не может убежать после этой черты, но что с того? Наше солнце держит в своем гравитационном поле всё в солнечной системе, но мы же не будем считать её среднюю плотность?
Большинство астрофизиков так и говорят: сингулярность - это неточность наших матемотических моделей, не более. Cкорее всего там просто какое-то ядро сверх высокой плотности.
На алгоритм сортировки «Индексацией Ранжирования» зарегистрированы авторские права. Но это никоим образом не ограничивает использование алгоритма любым образом. Это теперь общественное достояние.
Когда я последний раз заходил в книжный магазин, там на полках были тысячи и тысячи книг художественной литературы. Большая часть - неизвестных мне авторов, неизвестного качества, и, которые я никогда не прочитаю. А уж про интернет с его обилием текстов я и вообще не говорю. Написаны они людьми или ИИ - мне абсолютно не интересно и никак не влияет на мою жизнь.
Периодически смотрю ролики Семихатова и Сурдина, и буквально недавно они затрагивали эту тему. Сингулярность - это где наша математика "сходит с ума", они примерно так это назвали.
Действительно, математические модели - вещь такая.. они могут описывать как реальный мир, так и вымышленный со 105 измерениями..
В итоге я столкнулся с тем, что Rust не имеет аналогов Nginx, Lighttpd, Caddy, HAProxy, Apache, Tomcat, Jetty и т.д. Все эти веб-сервера написаны на C, Go, Java и т.д.
Есть River (замена Nginx, на ранней стадии разработки):
Имеются только веб-фреймворки: Actix, Axum, Rocket, Hyper и т.д.
Мне кажется не корректно Actix, Axum и тем более Hyper фреймворками называть. Это библиотеки. Последняя к тому же достаточно низкоуровневая, чтобы на ней строились другие (тот же Axum и Rocket используют Hyper).
Здоровая критика всегда полезна. И её в посте автора действительно много (например время компиляции, orphan-rule в конечном приложении и много другого). Такая критика должна, по идее,привести к улучшениям в языке.
Но в тоже время есть критика неверно выбранного инструмента. Автор целый раздел назвал: "Rust being great at big refactorings solves a largely self-inflicted issues with the borrow checker", в то время как этот "Self-infliced issue" получился из-за несовпадения приоритетов о которых я уже писал.
Т.е. можно сколько угодно критиковать borrow-checker, но если он является краеугольным камнем языка - это не конструктивно, т.к. он никуда не денется. Можно лишь частично его улучшить, но до определенного предела. Прийдется с ним жить.
Но тут человек именно что гвозди отверткой забивать хочет всю статью. У него везде прослеживается мысль, что ему не нужна ни безопасность, ни надежность, а нужны быстрое прототипирование, хот релоад и "just get things done".
ЯП невозможно сделать идеальным во всём. У Раст приоритеты обозначены. В рамках этих приоритетов язык улучшается, насколько это возможно. Но никто не будет перестраивать язык, отказываться от них, чтобы угодить какой-то одной сфере.
Всегда можно что-то придумать. Но кто этим должен заниматься за автора? У него 10 лет опыта иргостроения и несколько лет Раста. Сделал бы библиотеку упрощающую какие-то элементы разработки, пул реквесты в Bevy, придумал бы свои паттерны в конце концов.
Писать на Rust приятно если вам нравится разрабатывать софт и делать это максимально качественно: если вы кайфуете от того, что ваша программа потребляет мало памяти, работает быстро, а все её компоненты надёжно стыкуются и не ломаются при рефакторинге.
Если же вам важен именно продукт - быстро выкатывать новые фичи, экспериментировать и т.п. - вряд ли вы оцените Rust.
Тип задачи может лишь сгладить ситуацию. Чем более задача типовая - тем протореннее будет дорожка. Например, вряд ли у вас возникнут проблемы с каким-нибудь REST API.
Так ведь никто не создавал Rust с претензией, что он прямо на разработку игр заточен. С какой целью просить разработчиков\фанатов отверток признавать, что у отверток есть проблемы (ими трудно забивать гвозди)?
В корне GPT не поменялась - дает видимость успеха на поверхности, но как только дело доходит до деталей - галлюцинации. Вот пример картинки, которую я сделал когда-то для easter egg hunting: https://i.ibb.co/6ZWKmq5/r1.jpg
В ней в стиле бинарного кода Матрицы зашифровано слово. И человек и модель догадывается об этом без проблем. Но проблемы у GPT начинаются при попытке вытащить эти несчастные биты. Он выводит что угодно, но не правильные цифры.
"Make any value Send + Sync but only available on its original thread. Don't use on multi-threaded environments!" - что-то не похоже на "ровное место".
Проблема Unit of Work в том, что он не может быть реализован для абстрактных репозиториев. Он должен быть с ними тесно связан. В реальности всё чаще всего сводится к тому, что он просто скидывает все свои обязанности на реляционную БД.
Зачем мы вообще создаем абстракции/интерфейсы? Я делаю это ради двух целей:
Тестируемость в изоляции, т.к. можно легко сделать мок/фейк/стаб
Потенциальная замена реализации, если мне, например, потребуется хранить данные в другой БД
Сами по себе абстрактные репозитории - классная вещь. Хотим - храним в Postgres, а хотим - в каком-нибудь key-value хранилище. Но как только мы добавляем UoW - мы сразу привязываемся к реляционной БД с поддержкой транзакций. Смысл в абстрактности репозиториев теряется.
Я предпочитаю обходиться без UoW. Если нужна транзакционность, то можно сделать интерфейс с методом, который будет принимать параметры, описывающие совокупность тех изменений, которые нужно транзакционно выполнить. Такой интерфейс
лучше даст понять тем кто его реализует, что нужна транзакционность
позволит проще её реализовать
потенциально, сделает использующий код чище (менее императивным и более функциональным)
компилятор не жаловался..
Средняя плотность - это как средняя плотность земли в сфере геостационарной орбиты..
Не кажется ли нелогичным, что когда звезда коллапсирует в нейтронную, то у нее ахренеть какая плотность, а у ЧД вдруг мы считаем среднюю по её горизонту событий? Да, свет не может убежать после этой черты, но что с того? Наше солнце держит в своем гравитационном поле всё в солнечной системе, но мы же не будем считать её среднюю плотность?
Большинство астрофизиков так и говорят: сингулярность - это неточность наших матемотических моделей, не более. Cкорее всего там просто какое-то ядро сверх высокой плотности.
https://en.wikipedia.org/wiki/Bucket_sort
Как вы интеграционными тестами тестируете поведение приложения в нештатных условиях (сбой БД, сети, т.п.)?
Когда я последний раз заходил в книжный магазин, там на полках были тысячи и тысячи книг художественной литературы. Большая часть - неизвестных мне авторов, неизвестного качества, и, которые я никогда не прочитаю. А уж про интернет с его обилием текстов я и вообще не говорю. Написаны они людьми или ИИ - мне абсолютно не интересно и никак не влияет на мою жизнь.
Всё так.
Периодически смотрю ролики Семихатова и Сурдина, и буквально недавно они затрагивали эту тему. Сингулярность - это где наша математика "сходит с ума", они примерно так это назвали.
Действительно, математические модели - вещь такая.. они могут описывать как реальный мир, так и вымышленный со 105 измерениями..
Есть River (замена Nginx, на ранней стадии разработки):
https://www.memorysafety.org/initiative/reverse-proxy/
Есть G3:
https://github.com/bytedance/g3
Мне кажется не корректно Actix, Axum и тем более Hyper фреймворками называть. Это библиотеки. Последняя к тому же достаточно низкоуровневая, чтобы на ней строились другие (тот же Axum и Rocket используют Hyper).
+1. Я могу прекрасно читать код многих языков, которые не знаю.. но от синтаксиса Haskell мозг вскипает.
Лучше бы Scala использовали в примере. В ней как раз отлично уживается ООП и ФП.
Не надо гнать на пет-проекты. Они наоборот с любовью делаются.
Здоровая критика всегда полезна. И её в посте автора действительно много (например время компиляции, orphan-rule в конечном приложении и много другого). Такая критика должна, по идее,привести к улучшениям в языке.
Но в тоже время есть критика неверно выбранного инструмента. Автор целый раздел назвал: "Rust being great at big refactorings solves a largely self-inflicted issues with the borrow checker", в то время как этот "Self-infliced issue" получился из-за несовпадения приоритетов о которых я уже писал.
Т.е. можно сколько угодно критиковать borrow-checker, но если он является краеугольным камнем языка - это не конструктивно, т.к. он никуда не денется. Можно лишь частично его улучшить, но до определенного предела. Прийдется с ним жить.
Но тут человек именно что гвозди отверткой забивать хочет всю статью. У него везде прослеживается мысль, что ему не нужна ни безопасность, ни надежность, а нужны быстрое прототипирование, хот релоад и "just get things done".
ЯП невозможно сделать идеальным во всём. У Раст приоритеты обозначены. В рамках этих приоритетов язык улучшается, насколько это возможно. Но никто не будет перестраивать язык, отказываться от них, чтобы угодить какой-то одной сфере.
Всегда можно что-то придумать. Но кто этим должен заниматься за автора? У него 10 лет опыта иргостроения и несколько лет Раста. Сделал бы библиотеку упрощающую какие-то элементы разработки, пул реквесты в Bevy, придумал бы свои паттерны в конце концов.
Тут даже не в задаче дело.
Писать на Rust приятно если вам нравится разрабатывать софт и делать это максимально качественно: если вы кайфуете от того, что ваша программа потребляет мало памяти, работает быстро, а все её компоненты надёжно стыкуются и не ломаются при рефакторинге.
Если же вам важен именно продукт - быстро выкатывать новые фичи, экспериментировать и т.п. - вряд ли вы оцените Rust.
Тип задачи может лишь сгладить ситуацию. Чем более задача типовая - тем протореннее будет дорожка. Например, вряд ли у вас возникнут проблемы с каким-нибудь REST API.
А на питоне можно добавить за 10 секунд, зато потом спустя час обработки данных обнаружить, что где-то типы не сошлись..
Так ведь никто не создавал Rust с претензией, что он прямо на разработку игр заточен. С какой целью просить разработчиков\фанатов отверток признавать, что у отверток есть проблемы (ими трудно забивать гвозди)?
В корне GPT не поменялась - дает видимость успеха на поверхности, но как только дело доходит до деталей - галлюцинации. Вот пример картинки, которую я сделал когда-то для easter egg hunting: https://i.ibb.co/6ZWKmq5/r1.jpg
В ней в стиле бинарного кода Матрицы зашифровано слово. И человек и модель догадывается об этом без проблем. Но проблемы у GPT начинаются при попытке вытащить эти несчастные биты. Он выводит что угодно, но не правильные цифры.
На основании примера:
(Не критицизм кода) ORM - никогда их не любил, но как способ попрактиковаться - OK
Почему метод connect почему-то блокирующий, в то время как всё остальное асинхронное?
Prepared statement нет? В примере format и protect - есть гарантии что он корректно всё заэскейпит?
conn.query(query.as_str()) - можно использовать AsRef чтобы можно было передовать строки в разной форме
Очень много клонирования. Можно принимать и ссылки. Ну а лучше разрешить и то и то, опять же с помощью AsRef
А разве нет?
"Make any value Send + Sync but only available on its original thread. Don't use on multi-threaded environments!" - что-то не похоже на "ровное место".
В этих библиотеках даже беглым взглядо видно большое количество unsafe блоков. Авторы решили где-то обхитрить Rust, но просчитались, бывает.
Проблема Unit of Work в том, что он не может быть реализован для абстрактных репозиториев. Он должен быть с ними тесно связан. В реальности всё чаще всего сводится к тому, что он просто скидывает все свои обязанности на реляционную БД.
Зачем мы вообще создаем абстракции/интерфейсы? Я делаю это ради двух целей:
Тестируемость в изоляции, т.к. можно легко сделать мок/фейк/стаб
Потенциальная замена реализации, если мне, например, потребуется хранить данные в другой БД
Сами по себе абстрактные репозитории - классная вещь. Хотим - храним в Postgres, а хотим - в каком-нибудь key-value хранилище. Но как только мы добавляем UoW - мы сразу привязываемся к реляционной БД с поддержкой транзакций. Смысл в абстрактности репозиториев теряется.
Я предпочитаю обходиться без UoW. Если нужна транзакционность, то можно сделать интерфейс с методом, который будет принимать параметры, описывающие совокупность тех изменений, которые нужно транзакционно выполнить. Такой интерфейс
лучше даст понять тем кто его реализует, что нужна транзакционность
позволит проще её реализовать
потенциально, сделает использующий код чище (менее императивным и более функциональным)