React native + go для андроид?

Question

[Артур Питеров]

Всем хеллоу. Хочу разработать красивый мессенджер, с плюшечками в виде анимации, и т.п. выбрал реакт, т.к. думаю, что в нем это более осуществимо, чем в java/kotlin. Бекенд выбрал go потому что быстрее всех, и лёгок. Такая связка осуществима? Если нет, то подскажите как лучше. Спасибо!

Comments

[Дмитрий Свиридов]

Бекенд выбрал go потому что быстрее всех, и лёгок

Легок? Попробуйте на нем легко написать полноценное API. С миграциями, валидаторами и т.п. - и чтобы при этом код был читабельным, а не помойкой.

А что касается скорости, то в реальных условиях (когда есть запросы в базу данных и прочие "узкие горлышки") преимущества go в плане скорости перед другими языками минимальны.

Не отговариваю писать на го (сам его кое-где использую), но те преимущества, что вы выделили, несколько неоднозначны.

[Папа Стифлера]

Легок? Попробуйте на нем легко написать полноценное API. С миграциями, валидаторами и т.п. - и чтобы при этом код был читабельным, а не помойкой.

Легко. На нем УЖЕ написано множество полноценных API. Читабельность и качество кода зависит не от языка, а от того, на сколько правильно разработчик спроектирует приложение.

А что касается скорости, то в реальных условиях (когда есть запросы в базу данных и прочие "узкие горлышки") преимущества go в плане скорости перед другими языками минимальны.

Го на некоторых синтетических бенчмарках проигрывает той же Java по скорости. Но при этом ресурсов потребляет на порядок(и) меньше. Плюс, приложения на Го - это статически скомпилированные бинарные файлы, не требующие вообще ни каких зависимостей. А вот приложение на той же Java будут требовать еще и установки, как минимум, JRE.

[Дмитрий Свиридов]

Папа Стифлера,

На нем УЖЕ написано множество полноценных API.

Ага, видел я эти API.

Читабельность и качество кода зависит не от языка, а от того, на сколько правильно разработчик спроектирует приложение.

И вот это в 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 есть недостатки, но вы их не коснулись. Зато коснулись работы сторонних библиотек, которые к языку отношения не имеют от слова совсем.

За сим разрешите откланяться. Творческих вам успехов и хорошего дня.