LINUX.ORG.RU
ФорумTalks

В чём прикол использования go в качестве серверов (высоконагруженных)?

 , , ,


3

5

Я прочитал статью " Создатель Node.js: «Для серверов я не могу представить другой язык кроме Go» " ( https://habrahabr.ru/post/337098/ ), и у меня создалось ощущение, что чувак умом тронулся. Go - хипстерский язык, на который вообще нет никаких стандартов (в отличии от XEP явы), на котором пишут обычно просто мелкие сервисы и утилиты.

Каким образом на go можно писать нормальные сервера, если:
1. это развивающийся язык => никакого энтерпрайза
2. либы отвратительного качества (и количества) => никакого энтерпрайза
3. go изначально проталкивался одним человеком, который упоролся, а гугл выделил ему ресурсы на создание языка.
4. зачем, если есть java для бизнес-логики?
5. зачем, если есть nodejs для вебни? Причём не знаю, почему автор гонит на производительность, на том же хабре была статья, где на nodejs делали http/https-балансер (прокси с ssl-терминацией и оркестрацией виртуалок в облаке, запуская и останавливая их в зависимости от нагрузки).
6. зачем, если есть rust для быстроты и низкого уровня?
7. зачем, если есть python для админских скриптов с кууууучей либ?

Также язык:
1. Не асинхронен.
2. Не предназначен для энтерпрайза.
3. Бинарный (но при этом нельзя использовать для системного программирования, как rust).
4. Неудобный перехват эксепшенов.
5. Плохо документирован.
6. Нету каких-то киллер-фитч, типа (как в той же nodejs) простая организация очереди, тредов (причём нормальных, а не green), позволяя быстро делать многотредовые прилоежния). Или специализация на определенных задачах (например, как php и nodejs на вебне).

В чём соль? Очередной хипстерский хайп или я, как обычно, не догоняю за современной модой, предпочитая классические решения (типа J2EE на IBM i)?

No trolling.

Перемещено beastie из development



Последнее исправление: ktulhu6662 (всего исправлений: 1)
Ответ на: комментарий от Shadow

JS не считается - он популярен не из-за, а вопреки - другого-то нет

В общем-то да, но удивляет именно взлёт популярности на бэкенде. Всё же, разработчики фронтенда и бэкенда обычно весьма разные и популярность языка в первом не должна приводить к такому росту популярности во втором.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

Shadow ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

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

Shadow ★★★★★
()
Ответ на: комментарий от Shadow

Зато модно, молодежно и инновационно. И без смузи^Wработы не останешься.

Oxdeadbeef ★★★
()
Последнее исправление: Oxdeadbeef (всего исправлений: 1)
Ответ на: комментарий от slovazap

Мне не нужен аудит. Мне нужно чтобы все использовали то же что и я. Это даёт какую-то уверенность. А ЭЦП можно только подтереться.

Часто ментейнеры накладывают свои невнятные патчи.

Большая часть людей для продакшн использует библиотеки из pypi/rubygems/npm. А библиотеки из репозитория используется только поделиями из него же.

redvicka
()
Ответ на: комментарий от Deleted

Полы - мраморные, стол - стеклянный. Ты никогда на работу не ходил, что ли?

anonymous
()
Ответ на: комментарий от Gargamel

Думаю через пару лет Go себя покажет, а пока конечно не для энтерпрайза.

Я думаю, что через пару лет у создателя Go просто также поедет крыша. Или гугл прекратит его так активно продвигать. Потому что нафиг не надо.

anonymous
()
Ответ на: комментарий от KRoN73

В общем-то да, но удивляет именно взлёт популярности на бэкенде. Всё же, разработчики фронтенда и бэкенда обычно весьма разные и популярность языка в первом не должна приводить к такому росту популярности во втором.

Не понимаю, чего тут непонятного: вебня во втором десятилетии 21-о века считалась один из самых непрестижных (хотя и очень востребованных) тем программирования. Туда полезли всяки рукожопы, которые даже толком архитектуру не знаю. После чего нормальные программисты открестились от веба, и сказали, что у нас теперь будет отдельно - серверная вебня (и к нам с ней вообще не приходите, а то клава в голову прилетит), а бизнес-логику мы будем писать на нормальном языке (типа явы). Вот вам от неё REST-API, трахайтесь с ним со своими PHP/NodeJS/чёртовой матерью как хотите.

И да: NodeJS также взлетел потому, что всё-таки он лучше php, а почти каждый бекендщик более-менее знает фронтенд, движок тот же, язык и основная часть либ заточены под классические веб-задачи, шаблоны архитектур прямо в связке с фронтедном. Почему бы этому не взлететь?

anonymous
()
Ответ на: комментарий от Oxdeadbeef

А еще на этом говне пишут и впаривают «десктопный» говнософт.

А вот это действительно проблема.

anonymous
()
Ответ на: комментарий от Shadow

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

Эрланг? Шутишь? Мёртв давно.

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

anonymous
()

В чём соль? Очередной хипстерский хайп или я, как обычно, не догоняю
хипстерский хайп или я, как обычно, не догоняю
хайп или я, как обычно, не догоняю
я, как обычно, не догоняю

Поздравляю, ты догнал.

SuoiCat
()
Ответ на: комментарий от anonymous

Эрланг? Шутишь? Мёртв давно.

Нет. Его второе дыхание это Elixir.

abc
()
Ответ на: комментарий от anonymous

И да: NodeJS также взлетел потому, что всё-таки он лучше php

Странное сравнение двух инвалидов - один без левой ноги, второй без правой.

nihirash ★★★
()
Ответ на: комментарий от menangen

Не пробовал профайлер запускать? Flask под pypy может не то, что сотню - тыщ пятьдесят за секунду ссылок вставить.

Нихрена он не может. Профайлер пробовал, всё время тратится в url_for() в недрах werkzeug, вот тут:

https://github.com/pallets/werkzeug/blob/master/werkzeug/urls.py#L473

Тут-то я и понял что с питона надо валить.

К тому же есть быстрые шаблонизаторы типа Mako, и JSON + Vue.

На клиенте, да никогда в жизни, сайт должен работать с выключенным JS, и поисковиками нормально индексироваться. А если менять шаблонизатор, то почему бы сразу не язык?

slovazap ★★★★★
()
Ответ на: комментарий от anonymous

Я не про дельфи, я про редакторы форм со свойствами и обработчиками. Сам на питоне в BoaConstructor рисую, когда припрет. Но ваять это на электроне - это пипец...

Shadow ★★★★★
()

самое лучшее что есть в js это json. жаль что в go работа с json сделана очень криво, кривей чем в php... но может это исправят? кто знает?

quester ★★
()
Ответ на: комментарий от quester

самое лучшее что есть в js это json. жаль что в go работа с json сделана очень криво, кривей чем в php... но может это исправят? кто знает?

Написанием нормальной XML-библиотеки?

ktulhu6662
() автор топика
Ответ на: комментарий от ktulhu6662

Чтобы товарищи, которым нужен именно JSON сидели и завидовали? Или это должно вдохновить их на создание нормальной поддержки JSON?

anonymous
()
Ответ на: комментарий от slovazap

сайт должен работать с выключенным JS

И под IE6

zolden ★★★★★
()
Ответ на: комментарий от redvicka

Часто ментейнеры накладывают свои невнятные патчи.

Сам придумал? Отвечу в том же духе: «а ещё чаще внятные».

Большая часть людей для продакшн использует библиотеки из pypi/rubygems/npm. А библиотеки из репозитория используется только поделиями из него же.

Никто так не делает. Во-первых, без репозитория некуда - оттуда тянутся сотни «поделий» помимо модулей. Во-вторых, оттуда тянутся нативные библиотеки, без которых соответствующие модули не собрать. В третьих, продакшну нужна стабильная экосистема, а не рандомный набор версий меняющийся при каждой установке, может совместимых, а может нет. Потом, по зависимостям уже притягивается куча модулей, по крайней мере питоновских. Только профнепригодный студент сверху стабильной системы намешает дерьмеца из pip.

Но есть проблема у некоторых дистрибутивов, не будем показывать пальцем, где в репозиториях не хватает опакеченных модулей. Это да, проблема, и только из-за этого во многих случаях люди мучаются с пипом.

slovazap ★★★★★
()
Ответ на: комментарий от ktulhu6662

Написанием нормальной XML-библиотеки?

Написанием нормальных функций по типу json_decode/json_encode из php которые прямо типы в типы преобразуют

quester ★★
()
Ответ на: комментарий от slovazap

Что мешает подтягивать из pip определённую версию библиотеки?

anonymous
()
Ответ на: комментарий от slovazap

Сам придумал? Отвечу в том же духе: «а ещё чаще внятные».

Они меняют поведение библиотек, это уже плохо.

В третьих, продакшну нужна стабильная экосистема, а не рандомный набор версий меняющийся при каждой установке, может совместимых, а может нет.

Поэтому в requirements.txt и аналогах прописываются версии всех зависимостей, а не только используемых напрямую.

redvicka
()
Ответ на: комментарий от redvicka

Они меняют поведение библиотек, это уже плохо

Сам придумал? Хинт: чтобы ослом не выглядеть, принято приводить примеры и аргументы.

Поэтому в requirements.txt и аналогах прописываются версии всех зависимостей, а не только используемых напрямую.

Ага, чтобы уязвимость в каком-нибудь модуле осталась в системе навсегда. А использовани репозитория даёт консистентную, проверенную и заточенную под дистрибутив среду, при этом позволяя её гладко обновлять. За тебя половину работы сделали - пользуйся, нет - хочу pip'ом обмазаться.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

Сам придумал? Хинт: чтобы ослом не выглядеть, принято приводить примеры и аргументы.

python3-pexpect был кривой в ubuntu 14.04. Были проблемы с репликацией mysql из репозитория.

Ага, чтобы уязвимость в каком-нибудь модуле осталась в системе навсегда.

А за этим нужно следить. В репозитории фикс для какой-нибудь непопулярной библотеки волшебным образом тоже не появится.

redvicka
()
Ответ на: комментарий от anonymous

и сказали, что у нас теперь будет отдельно - серверная вебня (и к нам с ней вообще не приходите, а то клава в голову прилетит), а бизнес-логику мы будем писать на нормальном языке (типа явы). Вот вам от неё REST-API, трахайтесь с ним со своими PHP/NodeJS/чёртовой матерью как хотите.

То есть у нас теперь бизнес-логика и серверная вебня раздельно? REST-API это как бы тоже серверная сторона. Да и бэкенд на джаве пилить можно, если PHP, NodeJS, Python и т.д. не нравится.

NodeJS также взлетел потому, что всё-таки он лучше php

Да-да-да, конечно) Они практически одинаковы

Gargamel
()
Ответ на: комментарий от anonymous

А еще на этом говне пишут и впаривают «десктопный» говнософт.

А вот это действительно проблема.

Нормальный декстопный софт на JS не будут писать никогда - если проект большой, то очень медленно работать будет. Вспомним тот же Atom, созданный на Electron - изначально он не мог файлы больше 2 Мб открыть вообще, пока на C++ некоторые вещи не переписали. Да и к тому же декстопный софт на JS вообще не защищён от реверс инжиринга, так что нормально JS можно юзать лишь в вебе.

Gargamel
()
Ответ на: комментарий от anonymous

Я думаю, что через пару лет у создателя Go просто также поедет крыша. Или гугл прекратит его так активно продвигать. Потому что нафиг не надо.

А модет и допилят до чего-нибудь достойного.

Gargamel
()
Ответ на: комментарий от slovazap

Только профнепригодный студент сверху стабильной системы намешает дерьмеца из pip.

А что тогда использовать для того же Питона?

Gargamel
()
Ответ на: комментарий от slovazap

Всё-таки репозитории не полная замена pip, вполне может случится что дистростроители не добавят в репозиторий какую-то либу, специфичную для Питона.

Gargamel
()

" Создатель Node.js: «Для серверов я не могу представить другой язык кроме Go» "

Представляю как у нодохипстеров бомбит =) Но можно смело заявить, что создатель нодыжс весьма адекватный человек, который не имеет синдрома утенка, а выбирает лучшее решение

Siado ★★★★★
()

4. зачем, если есть java для бизнес-логики?

Затем, что джава тормозит и жрет память

5. зачем, если есть nodejs для вебни?

Затем, что нода еще хуже чем руби. И тормозит и жрет память еще больше жавы. Типичные программисты ноды - это те, кто на коленке освоил JS в браузере и лезут в бэкэнд, где их скудной логике не место.

6. зачем, если есть rust для быстроты и низкого уровня?

Затем, что раст писали марсиане. Вместо нормального языка сделали нечитаемую ерунду.

7. зачем, если есть python для админских скриптов с кууууучей либ?

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

Siado ★★★★★
()
Ответ на: комментарий от Siado

ну как я понимаю при декодировании из json во внутреннюю структуру в языке, в go нужно эту структуру досконально описывать, а в том же php просто вызываем json_decode который выдает структуру с нужными полями и типами. по мне так это на порядок удобней. может и в go есть такое в сторонней библиотеке какой?

quester ★★
()
Ответ на: комментарий от Siado

Затем, что раст писали марсиане. Вместо нормального языка сделали нечитаемую ерунду.

Поначалу тяжко: есть всякое странное - ломает мозг, но потом въезжаешь и понятно становится. Я правда не много с ним дела имел.

staring_frog
()
Ответ на: комментарий от staring_frog

Поначалу тяжко: есть всякое странное - ломает мозг, но потом въезжаешь и понятно становится.

Ага, ты сначала в свою писанину въезжаешь, а потом еще вьезжаешь в писанину других таких же писак. Таких языков, которых создавали любители марсианского языка, овердохрена. Тот же перл попробуй, пройдет время и сможешь в однострочниках километровых разбираться, но зачем оно надо?.

Вопрос в другом: если можно сделать синтаксис адекватным - то откуда берутся любители городить подобную ерунду? И, что более странно, находятся любители этот кактус грызть =)

Siado ★★★★★
()
Ответ на: комментарий от quester

ну как я понимаю при декодировании из json во внутреннюю структуру в языке, в go нужно эту структуру досконально описывать

Все правильно. Ты получаешь их json данные, ты знаешь какие данные должны прийти - подготовь под них структуру. Если ты не знаешь какие данные должны прийти из json - то что ты вообще с этим собрался делать?

а в том же php просто вызываем json_decode который выдает структуру с нужными полями и типами.

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

Siado ★★★★★
()
Ответ на: комментарий от Siado

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

Ну мозгами то я знаю что я декодирую, кроме того возможно еще ранее применил json schema к json и точно знаю что он соответствует моим ожиданиям, вызываю json_decode и из полученной стутктуры тупо выбираю нужные значения полей. А в go нужно делать лишнее действие и подробно описывать эту структуру.

Типичный пример - json на back поставляет front, он же описал json schemа, мне в коде нужно значения из пары полей из сотен полей чтобы что-то посчитать. В go же мне ручками придется расписывать все это в коде. В этом use case это точно overhead

quester ★★
()
Ответ на: комментарий от quester

А потом еще front что-то добавит, что-то изменит и даст для back новую json schema. В php оно сразу заведется, а в go потребует доработки в коде. Надеюсь в go появится возможность так же получать структуру с полями с правильными типами без создания это структуры в коде заранее. Может конечно я еще не настолько хорошо знаю go и там это не покатит по каким то другим причинам. Было бы интересно так же узнать как собираются дальше развивать go?

quester ★★
()
Ответ на: комментарий от quester

Может конечно я еще не настолько хорошо знаю go и там это не покатит по каким то другим причинам.

Если у тебя задача в go вытянуть только часть данных из json - то это легко можно сделать через map. Ты бы перед тем как говорить «нельзя» лучше бы в вопросе разобрался.

Держи пример:

https://play.golang.org/p/-8NYGLt3vw

Siado ★★★★★
()
Ответ на: комментарий от Siado

Чот не видал неадекватного синтаксиса в Rust в таком смысле как оно есть в Perl. Вроде норм. Вот странные загогулины в логическом смысле - есть такое. Но они и нужны там для более глубокой статической проверки. И, блин, работают!

staring_frog
()
Ответ на: комментарий от quester

Скажу как диванный эксперт. Go же со статической типизацией, ну так и логично что JSON обрабатывается в такой же манере. А ты чего-то ждешь реализации в динамической манере, с чего бы это?

staring_frog
()
Ответ на: комментарий от KRoN73

Ruby плохо годится под говнокодеров, быстро лапшу на нем разводят.

Как-то так прочиталось ¯ \ _ (ツ) _ / ¯

staring_frog
()
Ответ на: комментарий от Virtuos86

Твой хэйт похож на синдром утенка. Ты кроме питона какой еще язык используешь?

Мимо. К питону я пришел попробовав много разных ЯП.

Siado ★★★★★
()
Последнее исправление: Siado (всего исправлений: 1)
Ответ на: комментарий от KRoN73

JS ещё хуже, чем Ruby в плане строгости и читаемости, но вон как взлетел :)

Он взлетел из-за безальтернативности. Это единственный язык, которых работает во всех браузерах. А браузеры есть у всех.

Siado ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.