Да, возможно я действительно отстал от жизни, что-то в экосистеме Java сильно поменялось и теперь все пишут без фреймворков. Тут буду рад референсам.
В моей (альтернативной) реальности:
Быстрый старт веб-сервиса на Go без каких-либо зависимостей может продолжать развиваться дальше без какой-то существенной переработки написанного.
Быстрый старт веб-сервиса с Java без фреймворка — это то что мне потом придется выбросить и переписать заново уже на Spring/Quarkus/Micronaut. То есть это тогда и не старт вовсе, просто какой-то PoC на выброс.
Поэтому сравнение с plain Java мне просто не интересно, так как не решает мою проблему как "пользователя". В конечном счете я все равно буду работать с одним из фреймворков.
Да, сильных гарантий Go не дает. Есть race detector, который помогает отлавливать в гонки в рантайме и в тестах. Но это опция, не панацея, и точно не гарантия отсутствия проблем.
На самом деле сама философия Go не совместима с желанием иметь сильные гарантии. Go с сильными гарантиями перестанет быть Go и станет уже чем-то другим. Чем-то ближе к Scala и Rust-у.
Классическая история про то что достоинства обусловлены и неотделимы от недостатков.
Если оценивать Go с точки зрения того насколько он красиво спроектирован и реализован — то да, он кажется где-то устаревшим и где-то непривлекательным.
Но если смотреть на него как на продукт и инструмент, который ты применяешь для решения конкретных задач (написание утилит и веб-сервисов) — то тут он дает очень приятный по моему мнению экспириенс.
Частично ответил про это в комментарии из другого треда:
Подход Go — концептуально иной. Здесь достаточно простых строительных блоков и интерфейсов из стандартной библиотеки. То, что в других экосистемах требует интегрированного фреймворка (HTTP-роутеры, middleware, логгеры, драйверы БД) — в Go реализуется как лёгкие библиотеки, которые реализуют стандартные интерфейсы (http.Handler, io.Writer, sql.DB). Так что если на определенном этапе и требуется подключение внешних библиотек, то оно при этом не требует изменения архитектуры приложения, построенной вокруг стандартных интерфейсов.
Ну и на качество опыта конечно влияют быстрота старта нового сервиса, скорость компиляции и запуска, более простая отладка за счет "тонкого" технологического стека.
По моему мнению, это ровно то что позволяет снижать когнитивную нагрузку на разработчика: сервисы на Go будут очень похожи друг на друга вне зависимости от конкретного набора библиотек.
Бэкенды сайта бронирования отелей (тут все будет максимально похоже на любой другой e-com): ETL-джобы, консьюмеры-продьюсеры, REST-сервисы, scheduler-ы и воркеры для state-машин.
Несколько команд из 30 человек поддерживает порядка 170 джоб/воркеров/сервисов.
Из всего могу сказать что конкретно в области процессинга данных (ETL/ELT/etc) и стримминговой обработки потоков данных на Kafka Go уступает в зрелости экосистеме на базе JVM.
Здесь ключевой момент в том что сравнение идет именно с моим опытом коммерческой разработки :)
С переменным успехом я немного пользовался Pharo в режиме "поиграться". В этом отношении у меня больше опыта в Lisp (Clojure) + REPL. (Не будем воевать на тему того является ли Clojure Lisp-ом)
К сожалению (или к счастью), в своем текущем контексте не могу представить себе Smalltalk или Lisp как основной инструмент для работы команды.
вот вы говорите го не дает адекватные concurrency примитивы - это разве хороший опыт?
А тут как раз штука в том что сталкиваться со сложностями реализации concurrency в Go не приходится в тех пресловутых 80% случаев. Это связано с тем, что Go предоставляет синхронный и понятный API, скрывая под капотом сложный асинхронный рантайм.
А так для написания микросервисов сейчас почти все есть “из-коробки”: стандартный HTTP-стек с поддержкой middleware; request-scoped context для контроля над исполнением запроса и передачи чего-либо вниз по стеку; парсинг json; логирование. Для всего есть простые и стандартные интерфейсы, которые легко интегрировать друг с другом или заменять.
Ну и на качество опыта конечно влияют быстрота старта нового сервиса, скорость компиляции и запуска, более простая отладка за счет "тонкого" технологического стека.
кстати микрофреймворков под java/kotlin целая гора и там будет быстрый фидбек и лайврелоад и все что угодно
Согласен, Micronaut, Quarkus, Ktor — действительно хорошие примеры "продуктов", которые бьют в ту же нишу. У каждого уже есть богатая экосистема с хорошей функциональностью. Но нюанс в том что каждый из них выстраивает свою собственную ментальную модель и абстракции. Каждый надо изучать по-отдельности.
Подход Go — концептуально иной. Здесь достаточро простых строительных блоков и интерфейсов из стандартной библиотеки. То, что в других экосистемах требует интегрированного фреймворка (HTTP-роутеры, middleware, логгеры, драйверы БД) — в Go реализуется как лёгкие библиотеки, которые реализуют стандартные интерфейсы (http.Handler, io.Writer, sql.DB). Так что если на определенном этапе и требуется подключение внешних библиотек, то оно при этом не требует изменения архитектуры приложения, построенной вокруг стандартных интерфейсов.
По моему мнению, это ровно то что позволяет снижать когнитивную нагрузку на разработчика: сервисы на Go будут очень похожи друг на друга вне зависимости от конкретного набора библиотек.
Я сравниваю свой "пользовательский" опыт. У меня есть конкретная проблема и я хочу ее решить. Мой субъективный опыт в этом случае говорит о преимуществах Go. А каким образом оно там конкретно под капотом — это уже совсем другой разговор.
А упомянутые Haskell, Erlang, Smalltalk и Lisp вас не смутили? :)
обычный человек так не будет делать.
Позволю себе попытаться разубедить вас в своей "необычности": с Java работал года с 2010, с 2014 подключилась Scala и BigData, после 2021 переключился на Go и покинул JVM-стек. Не думаю что это какой-то уникальный опыт: сам знаю много подобных моей историй.
Rust в проде не применял, но писал "для души". Так же как и на Hasekell и Clojure. Вообще очень люблю всякие философские и концептуальные штуки.
Но вообще конечно это теперь новый вид челленджа: написать так, чтобы не сойти за ИИ :)
Эмоциональную составляющую полностью понимаю и разделяю :) Заходил в Go 3-4 раза и разворачивался в полном отвращении от происходящего. Но как приперло — просто втянулся и нашел свой coping-механизм. Теперь не болит.
Да, возможно я действительно отстал от жизни, что-то в экосистеме Java сильно поменялось и теперь все пишут без фреймворков. Тут буду рад референсам.
В моей (альтернативной) реальности:
Быстрый старт веб-сервиса на Go без каких-либо зависимостей может продолжать развиваться дальше без какой-то существенной переработки написанного.
Быстрый старт веб-сервиса с Java без фреймворка — это то что мне потом придется выбросить и переписать заново уже на Spring/Quarkus/Micronaut. То есть это тогда и не старт вовсе, просто какой-то PoC на выброс.
Поэтому сравнение с plain Java мне просто не интересно, так как не решает мою проблему как "пользователя". В конечном счете я все равно буду работать с одним из фреймворков.
Да, сильных гарантий Go не дает. Есть race detector, который помогает отлавливать в гонки в рантайме и в тестах. Но это опция, не панацея, и точно не гарантия отсутствия проблем.
На самом деле сама философия Go не совместима с желанием иметь сильные гарантии. Go с сильными гарантиями перестанет быть Go и станет уже чем-то другим. Чем-то ближе к Scala и Rust-у.
Классическая история про то что достоинства обусловлены и неотделимы от недостатков.
Если оценивать Go с точки зрения того насколько он красиво спроектирован и реализован — то да, он кажется где-то устаревшим и где-то непривлекательным.
Но если смотреть на него как на продукт и инструмент, который ты применяешь для решения конкретных задач (написание утилит и веб-сервисов) — то тут он дает очень приятный по моему мнению экспириенс.
Частично ответил про это в комментарии из другого треда:
Бэкенды сайта бронирования отелей (тут все будет максимально похоже на любой другой e-com): ETL-джобы, консьюмеры-продьюсеры, REST-сервисы, scheduler-ы и воркеры для state-машин.
Несколько команд из 30 человек поддерживает порядка 170 джоб/воркеров/сервисов.
Из всего могу сказать что конкретно в области процессинга данных (ETL/ELT/etc) и стримминговой обработки потоков данных на Kafka Go уступает в зрелости экосистеме на базе JVM.
Тут мне сложно говорить про точные значения, могу приблизительно прикинуть.
Scala - порядка 15 человек
go - порядка 80 человек
Здесь ключевой момент в том что сравнение идет именно с моим опытом коммерческой разработки :)
С переменным успехом я немного пользовался Pharo в режиме "поиграться". В этом отношении у меня больше опыта в Lisp (Clojure) + REPL. (Не будем воевать на тему того является ли Clojure Lisp-ом)
К сожалению (или к счастью), в своем текущем контексте не могу представить себе Smalltalk или Lisp как основной инструмент для работы команды.
А тут как раз штука в том что сталкиваться со сложностями реализации concurrency в Go не приходится в тех пресловутых 80% случаев. Это связано с тем, что Go предоставляет синхронный и понятный API, скрывая под капотом сложный асинхронный рантайм.
А так для написания микросервисов сейчас почти все есть “из-коробки”: стандартный HTTP-стек с поддержкой middleware; request-scoped context для контроля над исполнением запроса и передачи чего-либо вниз по стеку; парсинг json; логирование. Для всего есть простые и стандартные интерфейсы, которые легко интегрировать друг с другом или заменять.
Ну и на качество опыта конечно влияют быстрота старта нового сервиса, скорость компиляции и запуска, более простая отладка за счет "тонкого" технологического стека.
Согласен, Micronaut, Quarkus, Ktor — действительно хорошие примеры "продуктов", которые бьют в ту же нишу. У каждого уже есть богатая экосистема с хорошей функциональностью. Но нюанс в том что каждый из них выстраивает свою собственную ментальную модель и абстракции. Каждый надо изучать по-отдельности.
Подход Go — концептуально иной. Здесь достаточро простых строительных блоков и интерфейсов из стандартной библиотеки. То, что в других экосистемах требует интегрированного фреймворка (HTTP-роутеры, middleware, логгеры, драйверы БД) — в Go реализуется как лёгкие библиотеки, которые реализуют стандартные интерфейсы (http.Handler, io.Writer, sql.DB). Так что если на определенном этапе и требуется подключение внешних библиотек, то оно при этом не требует изменения архитектуры приложения, построенной вокруг стандартных интерфейсов.
По моему мнению, это ровно то что позволяет снижать когнитивную нагрузку на разработчика: сервисы на Go будут очень похожи друг на друга вне зависимости от конкретного набора библиотек.
Я сравниваю свой "пользовательский" опыт. У меня есть конкретная проблема и я хочу ее решить. Мой субъективный опыт в этом случае говорит о преимуществах Go. А каким образом оно там конкретно под капотом — это уже совсем другой разговор.
А упомянутые Haskell, Erlang, Smalltalk и Lisp вас не смутили? :)
Позволю себе попытаться разубедить вас в своей "необычности": с Java работал года с 2010, с 2014 подключилась Scala и BigData, после 2021 переключился на Go и покинул JVM-стек. Не думаю что это какой-то уникальный опыт: сам знаю много подобных моей историй.
Rust в проде не применял, но писал "для души". Так же как и на Hasekell и Clojure. Вообще очень люблю всякие философские и концептуальные штуки.
Но вообще конечно это теперь новый вид челленджа: написать так, чтобы не сойти за ИИ :)
Эмоциональную составляющую полностью понимаю и разделяю :) Заходил в Go 3-4 раза и разворачивался в полном отвращении от происходящего. Но как приперло — просто втянулся и нашел свой coping-механизм. Теперь не болит.
Согласен, назвать Go именно простым языком у меня язык не провернется :) Он субъективно оказался легким для многих в освоении, но не простым.
Тут под просто/легко имею в виду то что имел в виду Rich Hickey в Simple Made Easy.
Просто — объективное и структурное понятие, противоположное комплексному и переплетенному
Легко — субъективное отношение, насколько что то нам знакомо и близко, противоположное трудному