Всем хеллоу. Хочу разработать красивый мессенджер, с плюшечками в виде анимации, и т.п. выбрал реакт, т.к. думаю, что в нем это более осуществимо, чем в java/kotlin. Бекенд выбрал go потому что быстрее всех, и лёгок. Такая связка осуществима? Если нет, то подскажите как лучше. Спасибо!
Легок? Попробуйте на нем легко написать полноценное API. С миграциями, валидаторами и т.п. - и чтобы при этом код был читабельным, а не помойкой.
А что касается скорости, то в реальных условиях (когда есть запросы в базу данных и прочие "узкие горлышки") преимущества go в плане скорости перед другими языками минимальны.
Не отговариваю писать на го (сам его кое-где использую), но те преимущества, что вы выделили, несколько неоднозначны.
Легок? Попробуйте на нем легко написать полноценное API. С миграциями, валидаторами и т.п. - и чтобы при этом код был читабельным, а не помойкой.
Легко. На нем УЖЕ написано множество полноценных API. Читабельность и качество кода зависит не от языка, а от того, на сколько правильно разработчик спроектирует приложение.
А что касается скорости, то в реальных условиях (когда есть запросы в базу данных и прочие "узкие горлышки") преимущества go в плане скорости перед другими языками минимальны.
Го на некоторых синтетических бенчмарках проигрывает той же Java по скорости. Но при этом ресурсов потребляет на порядок(и) меньше. Плюс, приложения на Го - это статически скомпилированные бинарные файлы, не требующие вообще ни каких зависимостей. А вот приложение на той же Java будут требовать еще и установки, как минимум, JRE.
Читабельность и качество кода зависит не от языка, а от того, на сколько правильно разработчик спроектирует приложение.
И вот это в Go как раз не легко.
Го на некоторых синтетических бенчмарках проигрывает той же Java по скорости
Сравнивать GO и Java - ну, такое себе. На Go не получится писать такие проекты, как пишут на Java, сохраняя качество кода, пригодное к поддержке и дальнейшему сопровождению. По крайней мере, это гораздо сложнее в силу синтаксиса языка и его особенностей.
Плюс, приложения на Го - это статически скомпилированные бинарные файлы, не требующие вообще ни каких зависимостей.
Плюс для чего? В любом случае при сборке бинаря зависимости подтягиваются из Гитхаба - по сути разницы никакой. Что зависимости рядом в папке лежат, что вшиты в бинарь.
Плюс для чего? В любом случае при сборке бинаря зависимости подтягиваются из Гитхаба - по сути разницы никакой. Что зависимости рядом в папке лежат, что вшиты в бинарь.
Для деплоя в контейнеры, например. Контейнеры можно создавать FROM scratch. Чем не плюс?
Папа Стифлера, это плюс, конечно, но он никак не делает написание на Go более приятным. Многопоточность, один бинарь, высокая скорость, экономный расход памяти - все это классно. Но когда тебе требуется вытащить из СУБД данные из нескольких таблиц с кучей условий фильтрации (которые попадают из get-параметров, которые нужно валидировать и отдать текст ошибки на нужном языке), а потом это все замаппить на структуры и сериализовать в JSON, код на Go в любом случае начинает выглядеть как помойка - и все эти плюсы просто перечеркиваются.
Вот сколько проектов я видел, сделанных совершенно разными людьми с разным стажем, никакие sqlx, squirell, gorm и прочие пакеты не делают эту часть проекта более удобной. Та же sqlalchemy в питоне, doctrine в php и typeorm в ноде выглядят куда более серьезно, юзерфрендли и удобно.
Тем более если речь идет о конкретно API на Go, то в плане скорости та же нода достает данные из базы и формирует из них jsonчик примерно с той же скоростью плюс-минус. Тем более, что в API на Go у тебя потоки юзаться не будут, потому что все сводится к строго последовательным операциям, которые невозможно выполнять параллельно. Да, та же нода или питон держат меньше коннектов, но никто не мешает горизонтально масштабировать приложение. Стоимость памяти и прочих ресурсов куда ниже, чем стоимость разработки. Но Go она более ресурсозатратная, а код впоследствии поддерживать очень сложно. И дело тут не в квалификации.
Тем более, что в API на Go у тебя потоки юзаться не будут, потому что все сводится к строго последовательным операциям, которые невозможно выполнять параллельно.
Да ну? Вы серьезно? А мужики то и не знали, что API нельзя писать как многопоточное приложение...
Папа Стифлера, вы не правильно поняли. Я имею в виду, что невозможно распараллелить в рамках обработки ОДНОГО http-запроса к этому API. Потому что по сути логика работа большинства эндпоинтов сводится к запросу к базе и последующему запихиванию в кеш. И параллельно в двух потоках эти операции никак не сделать, потому что пока не вернется результат запроса к СУБД, в кеш класть нечего. То, что на каждый http-запрос к API выделяется горутина, я в курсе.
Дмитрий Свиридов, хм, а что вам мешает распараллелить сборку достаточно сложного объекта из множества таблиц и со множеством условий, который вы описали выше? Но это к языку отношения не имеет.
Подытожу эту увлекательную полемику со своей стороны: за 20+ лет в разработке я писал на многих языках, в том числе на Java, PHP, Ruby, C#, Go, Rust. Кода различного качества видел массу. Так вот, по моему субъективному мнению, количество говнокода от языка не зависит, но очень сильно зависит от понимания разработчиком что такое архитектура приложения и вообще фундаментальных знаний безотносительно языка. Если вы умеете писать чистый, понятный, тестируемый код на Java или PHP, то вам не составит ни какого труда писать такой же код и на Go. Да, в Go есть недостатки, но вы их не коснулись. Зато коснулись работы сторонних библиотек, которые к языку отношения не имеют от слова совсем.
За сим разрешите откланяться. Творческих вам успехов и хорошего дня.
