Бля. Ну забавно что все лезут в golang. Зачеем? Ну

из всего что есть крутого в го это многопоток. Всеее

По сравнению с чем?

после питона и пхп возможно типы

Да с тем же питоном

Ну среди php/python/ruby/js и т.п. Go всё же норм типизацией выделяется (не будем про interface{})

Пхп может типы ))

Пиши в питоне типы и юзай mypy. Все

Многопоток не повод перейти с питона?

Смотря в каких задачах. Если IO, то нет, не повод, ибо в питоне есть asyncio

Единственный повод. Но не перейти. А расширить

Что расширить?

Добавить go как микросервис чтоб нагрузку нужную на него кинуть и все

Посему все на гоу не печать, если нет ограничений?

Ну ответ прост. Скорость разработки

Скорость разработки чего?

Хм. Леденцов

Понятно.

Но может оказаться что леденцы быстрее делает на js чем на питоне.

А голанг тут каким местом?

Ну вы топите за питон. Что зачем переходить с него на гоу. Если переходить с него на js, то тоже будете убеждать, что смысла нет?

Речь шла о голанге

Простой, современный, кроссплатформенный, компилируемый язык, который не требует интерпретатора и добавочных библиотек на целевой платформе. Много таких?

Если убрать простой то rust

Раст сыроват и менее распространён.

для бекенда сойдет

В расте добавочные библиотеки все еще достаточно распространены, т.к. часто биндинги юзаются

Самое важное, что забыл добавить — сообщество. Это обламывает аргумент о rust, в контексте применения.

Но серверы разные на нем пишут. В опесорсе том же появляются.

а маленький STW? а грамотная реализация IO? а быстрая компиляция при достаточно высокой производительности? а компилятор не на LLVM, которые не тащит за собой проблемы с мискомпиляцией и свою поганую модель памяти?

Рантайм еще + M:N вытесняющая многозадачность.

Ну, учитывая, что Go многие юзают для написания REST API, всё это вообще не особо киллер-фичи

А что киллер-фича для написания REST API? Очередной монструозный фреймворк? ORM?

Причем у го есть свой ОРМ который в итоге чуть ли не лучше других в среднем

Нет, но как будто в Go в REST API ORM не юзают, ага

Для API никто монстров и не юзает. Какой-нибудь FastAPI питоновский или Slim4 пхпшный сложно монстрами назвать

вряд ли ent по фичам сильно выиграет у какого-нибудь Hibernate, вопрос только в том, на кой этот Hibernate нужен при современных трендах в разработке

я редко вступаю в языковые споры, но тут душа изволила не согласиться)

Ну аналог knex (квери-билдер, не orm) годный есть для Go? Не Squirrel, а прямо с широкими возможностями

это в котором надо обмазаться пидантиком, чтоб оно нормально работало?

да может и выиграет, т.к. в ent есть schema as code

а что вам не хватает в squirrel?

Ну то у Питонщиков надо узнать - возможно. Но почему бы пайдантик не заюзать для валидации пользовательских данных (с фронта прилетающих)

Если язык динамический, не обязательно везде это использовать. Тайп аннотейшн плюс линтер и в путь

А как это поможет валидировать данные, которые в API прилетают? Ну, чтобы ошибку кидать вроде {"email": "Not valid"}

Описать через опенапи схему и сгенерировать сервер, например

Ну конкретно сейчас на ум ничего не проходит (надо конкретные запросы смотреть). Но то, что Knex по функциональности сильно богаче - факт

Никак. Поищите либы для этого или используйте фреймворки, в них все есть

так пидантик работает именно так

Ну так пайдантик)))

Круто

Ну я knex'ом никогда не пользовался, у меня логичный вопрос — чем богаче-то?

Количеством поддерживаемых операторов? Squirrel умеет в рекурсивные запросы?

А зачем писать рекурсивные запросы билдером?

Это программист должен в них уметь. А squirrel их поддерживает, это факт

Странно, не видел ни единого примера ни на просторах Гитхаба, ни в тестах самого Squirrel

А в рекурсивных запросах не могут быть опциональные условия, которые удобно было бы делать билдером?

Что мешает собрать такой запрос и вызывать в рекурсивном контексте?

Goqu?

Спасибо. Слышал, но пока не юзал