Здоровая критика всегда полезна. И её в посте автора действительно много (например время компиляции, 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. Если нужна транзакционность, то можно сделать интерфейс с методом, который будет принимать параметры, описывающие совокупность тех изменений, которые нужно транзакционно выполнить. Такой интерфейс
лучше даст понять тем кто его реализует, что нужна транзакционность
позволит проще её реализовать
потенциально, сделает использующий код чище (менее императивным и более функциональным)
Я как-то столкнулся со сложным багом: джобина работала примерно год и вдруг зависла. Найти проблему удалось как раз изнутри контейнера. Доустановил всё необходимое для отладки и не только выяснил что было не так, но и оживил приложение (оказалось подвисшее сетевое соединение из-за бага в одной из либ).
А когда приложение не под рутом такое не проканает.
Т.е. получается безопаснее, да, но не отладить уже никак. А установить причину какого-то редкого бага другим способом может никак и не получится..
Может кто-нибудь объяснить: чем опасно запускать свое собственное приложение в контейнере под root? В особенности если к нему и доступа то нет из внешней сети.
Эх, если бы наш бывший дата-саентист следовал этим советам.. У меня даже отвращение к DataFrame выработалось, типа вам мало динамичности в Python - получайте ещё удар в пах.
Основные преимущества, которые микросервисы дают нам:
возможность использования наиболее оптимальных инструментов для конкретного сервиса, в том числе ЯП
полная независимость друг от друга
быстрое вхождение и рефакторинг
ownership
Микросервисы на одном языке, в одном репо попахивают:
Просто так поменять версию библиотеки не имея компетенции в других сервисах - рисковано. Нужно прогонять тесты на все остальные, а это долго и 100% покрытия не бывает.
Возникает риск использования общих модулей - антипаттерн в микросервисах. Теперь они у вас не самостоятельны, а часть так называемого distributed monolith.
Есть такое неписанное правило: работает - не трогай. Если у вас есть микросервис, который работает и никаких новых фич ему не нужно - его можно просто оставить в покое. В монолите такой опции нет.
У нас была монорепка в одной компании.. При попытке добавить одну библиотеку в одном из сервисов - ломались другие. Потому что она тянула новую версию Netty, ну а дальше можно представить.
Я уже не говорю про удовольствие работы с такой репой моего ноута.
Не надо гнать на пет-проекты. Они наоборот с любовью делаются.
Здоровая критика всегда полезна. И её в посте автора действительно много (например время компиляции, 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. Если нужна транзакционность, то можно сделать интерфейс с методом, который будет принимать параметры, описывающие совокупность тех изменений, которые нужно транзакционно выполнить. Такой интерфейс
лучше даст понять тем кто его реализует, что нужна транзакционность
позволит проще её реализовать
потенциально, сделает использующий код чище (менее императивным и более функциональным)
Кстати да. Но её почему-то нет у `kubectl exec`..
Меня это и смущает.
Я как-то столкнулся со сложным багом: джобина работала примерно год и вдруг зависла. Найти проблему удалось как раз изнутри контейнера. Доустановил всё необходимое для отладки и не только выяснил что было не так, но и оживил приложение (оказалось подвисшее сетевое соединение из-за бага в одной из либ).
А когда приложение не под рутом такое не проканает.
Т.е. получается безопаснее, да, но не отладить уже никак. А установить причину какого-то редкого бага другим способом может никак и не получится..
Может кто-нибудь объяснить: чем опасно запускать свое собственное приложение в контейнере под root? В особенности если к нему и доступа то нет из внешней сети.
Существует diesel_async. Sqlx тоже подошёл бы. А вот sea_orm - ну это для тех кто еще не прошел через ORM стадию.
Axum, действительно, предпочтительнее.
А что произойдет, если с одной стороны будет "..., дом 6, квартира 10", а с другой "..., дом 10, квартира 6"?
Эх, если бы наш бывший дата-саентист следовал этим советам.. У меня даже отвращение к DataFrame выработалось, типа вам мало динамичности в Python - получайте ещё удар в пах.
Если проекты типа https://github.com/cloudflare/pingora - "относительно неплохо", то что в вашем понимании "круто" тогда?
Основные преимущества, которые микросервисы дают нам:
возможность использования наиболее оптимальных инструментов для конкретного сервиса, в том числе ЯП
полная независимость друг от друга
быстрое вхождение и рефакторинг
ownership
Микросервисы на одном языке, в одном репо попахивают:
Просто так поменять версию библиотеки не имея компетенции в других сервисах - рисковано. Нужно прогонять тесты на все остальные, а это долго и 100% покрытия не бывает.
Возникает риск использования общих модулей - антипаттерн в микросервисах. Теперь они у вас не самостоятельны, а часть так называемого distributed monolith.
Есть такое неписанное правило: работает - не трогай. Если у вас есть микросервис, который работает и никаких новых фич ему не нужно - его можно просто оставить в покое. В монолите такой опции нет.
У нас была монорепка в одной компании.. При попытке добавить одну библиотеку в одном из сервисов - ломались другие. Потому что она тянула новую версию Netty, ну а дальше можно представить.
Я уже не говорю про удовольствие работы с такой репой моего ноута.
Вы про монолит что ли говорите? Так вы там тем более никакого рефакторинга не сделаете.