Основная проблема ORM в том, что это лишняя абстракция, нюансы работы которой нужно знать. И SQL тоже нужно знать обязательно. В итоге получается, что эту абстракцию можно выкинуть и не ухудшать свой developer expirience. Проблема мапперов на мой взгляд переоценена.
По моему мнению, это ровно то что позволяет снижать когнитивную нагрузку на разработчика: сервисы на Go будут очень похожи друг на друга вне зависимости от конкретного набора библиотек.
С одной стороны это плюс, но с другой стороны это является ограничением для создателей библиотек и не очень способствует конкуренции, имхо.
Я довольно подробно объяснил, почему строгая типизация без завтипов
Обратимся к тексту:
Типы могут принести очень много пользы, если они «граждане первого сорта». Ни в одном более-менее распространенном языке, кроме авангарда типа Coq/Rocq, Agda и Lean, и не покидающего стадию пре-альфа Idris, — нет зависимых типов. Строгая типизация без завтипов — детская игрушка.
SQL не является моей основной специализацией поэтому я уже делаю почти так же. Сначала говорю нейронке структуру базы, а потом что надо найти. Получаю почти всегда правильный SQL и иногда немного его правлю. Имхо, так и будет работать, вряд ли в бэкенд приложение будут вставлять непредсказуемый запрос на русском, вместо отлаженного надёжного SQL.
чтобы оно не зависло навсегда и не тормозило при наличии хотя бы 2 юзеров
добавляя по 0.5-1 секунде к задержке ответа
Это откровенная неправда. Сам знаком с людьми, которые пишут довольно популярных ботов и на JS, и на .NET, и на JVM. Поэтому претензия к блокирующим вызовам выглядит скорее вкусовщиной.
Скорее всего мои боты пока не дошли до того, что это является проблемой (да и вряд ли дойдут).
Сам пишу ботов на Java с использованием TelegramBots и проблем у меня с библиотекой примерно никаких. Всё апи поддерживается, если чего-то мне не хватает, то это косяк апи телеграма, а не библиотеки.
В общем, интересно узнать, что за требования такие к библиотекам.
если вы захотите написать телеграм бота, то вы (были) вынуждены делать это на python. Библиотеки на других языках непопулярны и зачастую не выполняют даже минимальных требований
Только данное утверждение выглядит крайне безосновательно, а по личному опыту даже не является правдой.
Как правило стараемся закрывать функциональность фича флагами, чтобы не тормозить другие команды. Но если что-то падает есть два варианта. Первый - реверт коммита. Второй, если никому сейчас сервис не нужен и можно быстро пофиксить, то сразу фиксим.
В целом, выше написали, история похожая. Разработчик делает фичу, пишет на неё тесты, если необходимо закрывает фича флагом. Далее мерж в мастер, прогонка e2e тестов, по необходимости ручное тестирование. После релиза, мониторинг ситуации на проде, по необходимости доп. тест на проде, иногда сразу на всех раскатываем иногда на часть. За факапы у нас отвечает команда, которая пилит фичу.
JdbcTemplate/NamedParametersJdbcTemplate и в последнее время JdbcClient. Используются чистые sql запросы и именованные параметры внутри них.
Уже много лет использую только jdbcTemplate и его производные
Основная проблема ORM в том, что это лишняя абстракция, нюансы работы которой нужно знать. И SQL тоже нужно знать обязательно. В итоге получается, что эту абстракцию можно выкинуть и не ухудшать свой developer expirience. Проблема мапперов на мой взгляд переоценена.
Развивать надо, но они форки, и JB оказывает на них сильное влияние. Отсюда и разбор новостей.
Java сделал очень большой шаг в развитии, частые итерации, много полезных фичей, язык открытый насколько это возможно. Не пониманию претензии
А на чём основывается авторитет? Почему именно эти университеты? Звучит сомнительно.
он даже на обычный линукс тригерится
С одной стороны это плюс, но с другой стороны это является ограничением для создателей библиотек и не очень способствует конкуренции, имхо.
Обратимся к тексту:
Подробного объяснения нет, один наброс.
SQL не является моей основной специализацией поэтому я уже делаю почти так же. Сначала говорю нейронке структуру базы, а потом что надо найти. Получаю почти всегда правильный SQL и иногда немного его правлю. Имхо, так и будет работать, вряд ли в бэкенд приложение будут вставлять непредсказуемый запрос на русском, вместо отлаженного надёжного SQL.
Потихоньку пилю бота с игрой для чатов https://github.com/Homyakin/project-seeker
Это откровенная неправда. Сам знаком с людьми, которые пишут довольно популярных ботов и на JS, и на .NET, и на JVM. Поэтому претензия к блокирующим вызовам выглядит скорее вкусовщиной.
Скорее всего мои боты пока не дошли до того, что это является проблемой (да и вряд ли дойдут).
Сам пишу ботов на Java с использованием TelegramBots и проблем у меня с библиотекой примерно никаких. Всё апи поддерживается, если чего-то мне не хватает, то это косяк апи телеграма, а не библиотеки.
В общем, интересно узнать, что за требования такие к библиотекам.
За старания, конечно, лайк.
Только данное утверждение выглядит крайне безосновательно, а по личному опыту даже не является правдой.
Насколько знаю, многие сидят на Java версии, в том числе из-за модов.
Не используем ORM
Если процесс построен правильно, то менторство - это такая же рабочая задача. И других задач должно становиться пропорционально меньше.
Начинание очень классное! Сам вот в процессе создания игры и open-source вселенной к ней, но этапы очень ранние
Как правило стараемся закрывать функциональность фича флагами, чтобы не тормозить другие команды. Но если что-то падает есть два варианта. Первый - реверт коммита. Второй, если никому сейчас сервис не нужен и можно быстро пофиксить, то сразу фиксим.
В целом, выше написали, история похожая. Разработчик делает фичу, пишет на неё тесты, если необходимо закрывает фича флагом. Далее мерж в мастер, прогонка e2e тестов, по необходимости ручное тестирование. После релиза, мониторинг ситуации на проде, по необходимости доп. тест на проде, иногда сразу на всех раскатываем иногда на часть. За факапы у нас отвечает команда, которая пилит фичу.