Автор Nuxt.JS вперше в Україні на конференції JavaScript fwdays | 14 березня, Київ
×Закрыть

Back-end разработка и Go. Какие перспективы?

Изучаю Golang для разработки чистого бэкенда, т.к только эта сфера более интересна. Из языков выбрал Go. ТАкие языки как php, python, ruby... К другим языкам особого интереса нет, особенно к php.. Есть ли перспективы у данного языка именно в плане бэкенд разработки на будущие, есть ли смысл продолжать изучать его?

LinkedIn

Лучшие комментарии пропустить

Выскажу сугубо личное мнение: Я не совсем понимаю, откуда такая практика как «напишем все на XXX»
Golang — идеальный инструмент для решения высконагруженных задач, где требует высокая конкурентность и т.д.
Вот так его и надо использовать. К примеру сочетание Ruby( или PHP или Node.js и так далее) + Golang дает потрясающий эффект при грамотном проектировании.
Вы быстро пишите бизнес логику, а в ситуациях, когда необходимо что-то соот. задачам Golang, соот. участки выносятся как выделенные микросервисы.
Соот. Вам, как backend разработчику необходимо владеть не только Golang, но и как минимум + 1-м языком, на котором активно решают бизнес задачи.

Я писал больше 10 лет на c#/.net и перешел на Go. Пишу всего лишь год на нем и считаю что c#/.net как и джава — технологии прошлого тысячелетия по сравнению с Go. Многие вещи за вас решены создателями (как писать тесты, как форматировать код и т.д.). Сам язык очень простой и очень хорошо подходит для современной cloud-native microservice архитектуры. Сначала мне не хватало дженерик типов, но теперь мне кажется что они просто не нужны :)

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

Go это современный Си. достаточно низкоуровневый язык , не очень подходящий для моделирования сложных абстрактных типов данных . у него есть своя ниша (софт для управления сетевыми сервисами, девопс тулзы, контейнеры, низкоуровневая часть движка базы данных и тд ) но вряд ли он станет альтернативой языкам общего назначения (Java/Scala/Ruby/Python) на бэкенде. но это не страшно — если вам захочется написать что-нибудь на Го в рамках крупного ентерпрайз проекта, запилите его в микросервис

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
ТАкие языки как php, python, ruby... К другим языкам особого интереса нет, особенно к php.

Перспективы Go в Украине очень туманны. Вакансий мало и обычно все хотят сразу мидлов и сеньйоров. PHP это самый востребованный язык в нашей стране и , скорее всего, будет таким оставаться в ближайшие 10-20 лет, но если он на подсознательном уровне вызывает у вас отвращение, и вам важно чтоб все в интернете были без ума от языка на котором вы пишете, то ваш путь это Ruby. Не знаю ни одного рубиста, который бы не восторгался красотой Ruby и комьюнити там очень дружное.

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

С учетом того что с го обычно прицепом идёт кубернетис, яхз как можно на несложных проектах дома обучиться

Кубернетис — это тема для админов/девопсов, к разработке отношения не имеет. С тем же успехом можно требовать кофе заварить, в магазин сгонять.

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

И даже с бизнес логикой. Микросервис нужно деплоить в контейнер, понимать как он работает с другими микросервисами, писать для них спеки, понимать как дебажить и мониторить хотя бы на базовом уровне. Это все задача разработчика, у девопс (хотя девопс там уже нет, есть SRE, которые способны код писать) совсем другие задачи

В Швеции в стартапах часто есть только разработчики. Нет никаких девопсов. Разработчик должен сам уметь свой код запускать, тестировать, дебажить. И вообще: you built it — you run it. Когда компания становится достаточно большой (100+ инженеров) — тогда наверное есть смысл заводить SRE. Лично я не вижу в чем сложность запустить код в контейнере и снять оттуда логи/метрики. У нас даже джуны это умеют

То же самое в сша. Тут активно продвигается культура devops, когда разработчик сам отвечает за инфраструктуру в том числе. SRE нужны уже для более узких задач, когда кубернетис нужно тюнить и поддерживать для прода. И воообще вот это вот «это задача админа/девопс» я слышу только от украинских разрабов

ультура devops, когда разработчик сам отвечает за инфраструктуру в том числе

Это называется no-ops, наверное 🙂.

Ну например вот пишут:

DevOps culture stresses small, multidisciplinary teams, who work autonomously and take collective accountability for how actual users experience their software. For a DevOps team, there’s no place like production. Everything they do is about making customers’ live experience better.

DevOps teams apply agile practices and include operations in the team responsibility. Teams work in small batches, focus on improving the end-to-end delivery of customer value, and strive to eliminate waste and impediments along the way. There are no silos and no blame game, because the team is mutually accountable.

...

DevOps teams think in terms of competencies, not roles. While they include both developmental and operational skills and awareness, they share responsibility for running the live site. That means that developers on the team accept responsibility for the health of the running services and will rotate time on-call. The principle is, if you build it, you run it.

docs.microsoft.com/...​rn/what-is-devops-culture

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

То же самое в сша.

Ага, видал вакансии типа «scala, spark, big data, aws, kubernetis, javascript, angular».

Должен и танк уметь водить и школьный автобус, и камаз с тепловозом.

Это называеться попытка сэкономить на кадрах, которая обычно плохо заканчиваеться.

Та можешь хоть все слова вычеркнуть и Оставить один яп, потом только не жалуйся на маленькую зп

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

Интересно, я на sof не ходила уже сто лет... спасибо что напомнил как люди все ещё программируют

ПС: а сроки потому и срываешь, что решеное по инету ищешь

ПС: а сроки потому и срываешь, что решеное по инету ищешь

Ахаха, а у тебя все знания по всему зоопарку технологий с рождения встроены ? ИЛи ты когда видишь каждую новую технологию — берешь отпуск на 3 месяцо и в буткемп ?

нет, я просто не прыгаю с технологии на технологию

Для дава которвый еще девопсом занимаеццо ? Доу чушь такая доу чушь.

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

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

Хз, на всех проектах в штатах были девопс.

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

ты так гриш как будто это ядреная физика — любой дев, способный поставить себе линукс на компутер с этим всем быстро разбереться (особенно если таки есть девоп, который изначально покажет как это делать).

да нет, не говорю. Если ты проследишь, то поймешь что изначально ветка пошла от утверждения что миддл го девелопером можно стать дома на мелких проектиках за пол года. Мой пойнт был в том, что нельзя, т.к. разработка на го часто влечет за собой такой зоопарк, что ошизеть можно.
Линуксом тут, к сожалению, не обойдешься вообще ни разу. Стекоферфлоу тоже не поможет, потому что тупо не знаешь что гуглить.

ПС: а чо есть еще люди, называющие себя бекенд девелоперами и не умеющими в линукс?

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

А надо? У тебя софт увязан под конкретное апи ядра линукса?

у меня конкретно да

у меня конкретно да

И ты при этом по-прежнему также, как и вчера пишешь на Go?
Ладно, не парься, я тебе сам подскажу что говорить надо. Дело в том, что у тебя подключается либа на чистом C, написанная школьниками-говнокодерами под линукс, поскольку виндоус — мастдай.

все так, мой кусок, написанный на го использует другой кусок, который написан на С, и он компилится под ядро, используя системные библиотеки.
Про школьников хорошо что сказал, пойду передам коллегам пусть идут доучиваются. Думаю они очень сразу прислушаются к мнению недомиддла

А что системного он дёргает? Давай снова подскажу, там юзаются вычисления на видюхе под cuda.

Не угадал, видяха там вообще не при чем

Я даже прикидываться не стану что понимаю что там происходит, так что вопросы по тому куску мне задавать бесполезно

Я даже прикидываться не стану что понимаю что там происходит

А больше ничего там происходить не может. Там нет ничего ценного, чего не было бы в стандартной либе Go. Если скажут, что им нужна какая-то там особая оптимизация под сеть, которую только они одни могут сделать, тогда вопрос — а нафига под линукс, а не под виндоус IOCP, и что они собираются выиграть. Остальные либы, которые хоть что-то из себя представляют — кросплатформенные, и линукс там как бы не при делах.

Да не, рассказали. Я даже написала здесь, но стёрла. Хз могу ли говорить вслух

Да не, рассказали. Я даже написала здесь, но стёрла. Хз могу ли говорить вслух

Так, ну ладно, я опять могу сам тебе рассказать, что у тебя делает код под линукс в твоём проекте. Лет 10-15 назад было очень модно надрачивать на линукс, на всех форумах в специальном отведённом для любителей линукса разделе во всех вариациях обсуждался вопрос, что вот-вот, буквально на днях мастдай загнётся, и все перейдут на линукс, поскольку это самая надёжная в мире система. Ну или на мак в крайнем случае. В итоге загнулись линуксы форумы. Линуксоиды конечно же остались. Я пару раз заходил в конторы в плане устроиться на работу, а там сидят дяди, и во всю что-то строчат под линукс какие-то задачи, никак абсолютно не связанные с тем, за что контора получает деньги. На что у них естественно есть убедительные обоснования, ещё длиннее чем этот пост. Так что насчёт школьников-говнокодеров — это конечно не совсем корректно. 23-летние синьоры вообще не поймут в чём там прикол увязывать проекты чисто под какой-то линукс, и это им не объяснить с позиций здравого смысла.

чо? нет, ты что. Апп ранается деплоится как демонсет на каждой ноде в куб кластере и контролирует I/O на низком уровне, для чего нужна коммуникация с ядром. При чем тут мода и масдай?

Ну какие проблемы в целом это решает?

динамический провижнинг стореджей for stateful apps running in containers in clouds and onprem

А нативные решения в клаудах не подходят? Еще есть вот такая штука github.com/...​er/local-path-provisioner. Или вы не для себя, а продукт такой строите?

ты так гриш как будто это ядреная физика

Местами почти так и есть.

Например, хитрости, как писать Jenkins pipelines на groovy (чтобы максимально эффективно и гибко работало) — на это есть выделенный человек, который всё это знает и испытал (при документации, которая написала чуть лучше, чем полное отсутствие, но всё равно хрен без масла). Остальные, если им нужно туда лезть — комбинируют из готовых примеров, как на stackoverflow.

а не бегать к дядечке админу (где вы их вообще в последнее время видели то?)

ЛОЛ их уже давно в SRE переименовали:)

ЛОЛ их уже давно в SRE переименовали:)

Что-то работа у одминов какая-то нетолерантная. То они сначала были одминами, потом стали девопсами, а теперь срунами. Ну прям как негры, которые не негры, а чернокожие и афроамериканцы.

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

А на какие сайты гугл выдает ссылки по твоим запросам?

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

Да ну бред все это, никто в своём уме таких не ищет

Вообще забей что написано в вакансии. Вот просто совсем. Там может быть что угодно, но в итоге будешь сидеть писать фронт на jquery.

я общалсе с рекрутером, там именно был кейс «жлоб-стартап хочет все в одном за среднюю зп»

ну в стартапах так и есть, они не могут много платить. 200к бейз — это ты уже мультисиньором должен быть. Иди в фаанги, там норм насыпят

200к бейз — это ты уже мультисиньором

Ктото тут доказывал что 250 каждому джуну плотют, шото несходяться показания.

а кто-то говорил о стартапах?

С метриками и логами на самом деле не так все просто тоже. Для дев окружения да, но когда дело подходит к ягеру, промитиусу, графане и остальному зоопарку, тут с наскоку не разберёшься. И это все равно делает разрабочик, параллельно со своей основной работой

Можно использовать клауд тулы типа Datadog или Loggly. Тогда разбираться надо только в их API и как мышкой покликать чтобы дашборд сделать. Если конечно хочется самому хостить опенсорс тул (на самом деле несколько одновременно) — понятное дело это на порядок сложнее и возможно прийдется нанять специально обученых людей =)

С тем же датадогом начинаются пляски при добавлении кастомных метрик, но это и правда ничто по сравнению с опенсорсными тулами:)
Основная проблема мониторинга не в том как мониторить, а в том что нужно мониторить. А для этого в инфраструктуре и продукте нужно разбираться достаточно хорошо

Разработчик должен сам уметь свой код запускать, тестировать, дебажить.

Шо-то я не совсем понял увязку, как настраивание кубернетуса плавно переходит в умение дебажить код. Может его надо в контейнере как-то уметь дебажить? Или нет?

Лично я не вижу в чем сложность запустить код в контейнере и снять оттуда логи/метрики.

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

Шо-то я не совсем понял увязку, как настраивание кубернетуса плавно переходит в умение дебажить ко

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

Или в локальный файл в контейнере?

Какая база и файл в контейнере? Ты же имеешь представление куда логи с микросервиса идут?

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

А в чём собственно суть проблемы законектиться с локальной машины ко всему хозяйству?

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

Что там описывать вообще? Зачем? Кому?

Ты же имеешь представление куда логи с микросервиса идут?

Нет, расскажи. Давай начнём сначала, что такое лог?

А в чём собственно суть проблемы законектиться с локальной машины ко всему хозяйству?

В том, что твоя локальная машина не в кластере.

Что там описывать вообще? Зачем? Кому?

Деплоймент спецификацию как минимум.

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

В том, что твоя локальная машина не в кластере.

Ииии? Принципиальная невозможность заключается в... (закончи фразу)

Деплоймент спецификацию как минимум.

Речь о файлах deployment.yaml и dockerfile? Или всё сложно?

Возвращаюсь к изначальному тезису — за пол года дома на простых проектиках на голанге миддлом не стать

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

Ииии? Принципиальная невозможность заключается в... (закончи фразу)

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

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

Речь о файлах deployment.yaml и dockerfile? Или всё сложно?

Загуглил да не до конца. Один файл тут лишний. Какой?

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

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

Загуглил да не до конца. Один файл тут лишний. Какой?

Скорее одного не хватает, .rancher-pipeline.yml. Ну так что там со спецификацией?

Слушай, ты тут не выкручивайся, я тут у тебя выясняю

Фигасе ты дерзкий. Ну выкручивайся значит сам

Фигасе ты дерзкий. Ну выкручивайся значит сам

Подожди. Давай сначала определимся, кто из нас не миддл. Или может, оба?

Я не миддл

Ага. Значит оба. Это немного проясняет ситуацию. А опыт разработки на Go какой? Если не секрет конечно.

3+ года, если это ещё больше проясняет ситуацию =)

3+ года, если это ещё больше проясняет ситуацию =)

Девушка, можно у тебя взять автограф? А то я даже не подозревал, что выпадет удача общаться с разработчицей с таким богатым опытом. Ты наверное все эти 3+ года неуклонно повышала свои скилсы.

Да бери, жалко что ли

+

Скорее одного не хватает, .rancher-pipeline.yml. Ну так что там со спецификацией?

Фейс блин палм

Фейс блин палм

Ну я просто пытаюсь выяснить, какую спецификацию должен уметь пейсать разраб.

Погугли kubernetes resources. Нужна спецификация в зависимости от ресурса. Для обычного приложения это чаще всего deployment, service , configmap, secretmap

И всей настройкой деплоймента должен заниматься пейсатель бизнес-логики на Go, я правильно понимаю?

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

Я пока не встречала проектов где разработчик не касается инфраструктуры вообще.

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

В смысле забить болт?

В смысле забить болт?
Кубернетис — это тема для админов/девопсов, к разработке отношения не имеет. С тем же успехом можно требовать кофе заварить, в магазин сгонять.

Я кажется всё понял. Всё дело в проектах, просто в некоторых всю это хозяйство поднимают пейсатели на Go, а в некоторых одмины. Ну всё ясно. Фух, наконец-то разобрались.

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

Ооо, оказываеться в микросервисах тоже есть минусы — невероятно :-)

еще один, который про микросервисы только на доу читал

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

И даже с бизнес логикой. Микросервис нужно деплоить в контейнер, понимать как он работает с другими микросервисами, писать для них спеки, понимать как дебажить и мониторить хотя бы на базовом уровне.

Да ты что! Другие микросервисы дебажить и мониторить — тоже нужно?

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

Такое ощущение что о микросервисах тебе Рабинович на доу напел

Ну так на доу всегда собираются одарённые люди, можно подумать это новость

PHP это самый востребованный язык в нашей стране и , скорее всего, будет таким оставаться в ближайшие 10-20 лет,

Ага, аж два раза

Вот куча однотипных комментариев про проблемы с бизнес логикой на Go, и главное, вообще без аргументов.

Людям просто хочется сделать какой-то высер и показать, что они не очень умные, хотя не понятно зачем?

Единственная проблема Go — это рынок труда, но он потихоньку растет.

P.S. Вот с чем точно не было никаких вопросов, за год, так это с тем, как писать бизнес логику!

P.P.S. С отсутствием большого количества вакансий с Go на данный момент, просто с ужасом представляю после него писать на чем-то другом 😲.

Вот куча однотипных комментариев про проблемы с бизнес логикой на Go, и главное, вообще без аргументов.

Классы — это инструмент для типизации домена. Неважно выберите ли Rich или Anemic

В ЯП без классов, или с урезанными возможностями — сразу возникает проблема проектирования, описания домена.

Из Go они были убраны с конкретной и прагматичной целью — для бекенд сервисов которые можно отнести к разряду «микро» классы семантически избыточны, достаточно процедурного стиля.

Вот с чем точно не было никаких вопросов, за год, так это с тем, как писать бизнес логику!

о бизнес логике можно почитать в холиварах Rich vs Anemic

Или попытаться на Go писать по DDD.

Или одним предложением
Go беднее семантическими возможностями чем Java/C#/Python/PHP/Ruby и даже JavaScript’а (из-за наличия у JavaScript прототипного наследования)

Какой именно абстракции от классов Вам не хватает в Go?

Go — это очевидный язык, он в каждый момент времени дает программисту понимать, что он творит. И тем, что в Go — это структура, а не класс, показывают, что есть реальный кусок в памяти. Наследование в Go есть, при чем, когда человек включает одну структуру в другую, он тоже понимает, что это на самом деле. Поэтому Go позволяет писать вещи (не все), которые раньше писались на C++.

Вот DDD в Go реализуется просто прекрасно, при чем, как в виде модульного монолита, так и (микро)сервисов.

При чем Rich vs Anemic к данному вопросу, я вообще не понял.

DDD не имеет никакого отношения к ООП.
Многие успешно строят системы по DDD на функциональных языках типа Скалы или Эрланга без единого класса.
Собственно мы отлично справляемся на Go и строем необанк в соответсвии с DDD

DDD не имеет никакого отношения к ООП.

Скорее да, там идея о DSL

на функциональных языках типа Скалы или Эрланга

Одерски в интервью постоянно подчеркивает:
Scala мультипарадигменный язык, а не функциональный!
(потому что любая рафинированная парадигма — убога на практике, что функциональная, что объектная, как я понял его постоянное возражение)

А Эрланг взял не тем что он функциональный, а зелеными потоками и моделью акторов.

Собственно мы отлично справляемся на Go и строем необанк в соответсвии с DDD

понятия не имею, что вы и как строите :)

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

Вот куча однотипных комментариев про проблемы с бизнес логикой на Go, и главное, вообще без аргументов.

у меня обширный домен обьектов разных типов — пользователи, продукты, товары, пути доставки, платежи. Пример

users := []struct {
Id int
Name string
Country string
}

products := []struct {
Id int
Name string
GroupId Int
Price ???
}

basketItems := []struct {
Quantity: int,
ProductId: int
UserId: int
}
...

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

Проблематика

1. Какой точный тип данных взять для финансовых расчетов — в C# я возьму decimal (в стандартной библиотеке и операторы подерживаеются компилятором.
2. Как мне реализовать работу со структурами данных —
например, посчитать общую величину дисконта(10%) по корзине, дисконт предусмотрен на все товары в корзине общей стоимость больше или равно 100,3

В С# и т.д. это будет выглядеть так

basketItems
.Join(products, i => i.ProductId, j => j.Id, (i, j) => new {Cost = i.Price * i.Quantity})
.Where(i => i.Cost >= 100.3)
.Sum(i => i.Cost)

этот код пишется на основании стандартной библиотеки языка, выглядит декларативно и понятно для человека, который даже не может не знать синтаксиса языка

Я так понимаю в Go это будет выглядеть как минимум не хуже и не потребует написания много кода, можешь показать как это будет выглядеть на Golang?

Не апологет Go, но вы задаете странно простые вопросы.
1) Вам стоит почитать про миксирование структур, очень знаете полезная вещь, чтобы не писать по 100 раз одно и тоже
2) Вы не должны думать в технимах с-р, вам стоит оперировать интерфейсами и логику обработки строить на них. С-ра — это конкретный блок, который может реализовать соот. и-с
3) Decimal — godoc.org/...​ub.com/shopspring/decimal
4) кода будет малость побольше, разумеется

И как все-таки будет выглядеть решение? Для C# мне не понадобилось даже IDE — а хватило редактора местного, на Go ведь нет проблем с логикой и он не уступает другим языкам — значит это должно быть также просто.

1) Вам стоит почитать про миксирование структур, очень знаете полезная вещь, чтобы не писать по 100 раз одно и тоже

Мой домен смоделирован по DDD и будем максимально удобным для бизнесс операций с ним, если верить Эвансу. Если есть желание поспорить с этим — welcome.

2) Вы не должны думать в технимах с-р, вам стоит оперировать интерфейсами и логику обработки строить на них. С-ра — это конкретный блок, который может реализовать соот. и-с

Я взял структуры потому, что нет классов. Ближайшая альтернатива для моделирования обьектов домена. Замените структуры на интерфейс, если это упростит задачу для go и go не может эффективно обрабатывать в структурах данных структурный тип.

3) Decimal — godoc.org/...​ub.com/shopspring/decimal

Я так понимаю это пример того что go неудобен для работы с точными числами и у него нет поддержи операций для типа данных точных вычислений на уровне компилятора?

Я так понимаю это пример того что go неудобен для работы с точными числами и у него нет поддержи операций для типа данных точных вычислений на уровне компилятора?

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

1. Вот то, что этот код понятен — это слишком громкое заявление.
"

.Join(products, i => i.ProductId, j => j.Id, (i, j) => new {Cost = i.Price * i.Quantity})

"
Что происходит вот в этой строчке, написанной на древне-эльфийском, вообще не понятно. Не спорю, возможно это стандартный паттерн в C# и все его знают. Но он вообще не очевиден.

Если говорить о красивом решении, то тут скорее map/reduce, а не эта непонятная хрень.

2. По сути, на Go, тут все равно будет два цикла с двумя if и тогда будет точно код, понятный всем, кто хоть что-то понимает в программировании. Из больших плюсов, тут реально будет видно, что это полный перебор двух массивов. А в Вашем варианте, если потом окажется, что хоть одна коллекция большая, то придется долго думать, в чем проблема.

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

4. Вот Go приносит именно уровни абстракции (рутины, утиную типизацию), а также кучу инфраструктурных плюшек.

пункты 1-3 можно свести к
«вам это не надо», и «а нубам будет все понятно»

за Go аж обидно, от такой его «рекламы». Не так уж он и плох, как подразумевается в пп 1-3.

по 4 — аргумент про «кучу инфраструктурных плюшек» конечно да, относится к дизайну ЯП :)
ладно что само наличие этой кучи подразумевается очевидным, в отличие от других ЯП, где конечно нет «куч инфраструктурных плюшек»

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

Go — это инструмент, при чем, очень хороший инструмент.

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

Go — это инструмент, при чем, очень хороший инструмент.

молоток — хороший инструмент
и отвертка — хороший инструмент

Но очевидно, что есть задачи,

адепты Go строят свою рекламу так — что молоток лучше отвертки.

когда им указываешь на задачи где молоток хуже отвертки — в ответ:
НЕ хуже! Я и молотком шурупы вбиваю!

правда, иногда прибегает функциональщик, с гаечным ключем, и с улыбкой постигшего дзен утверждает что лучше молотка и отвертки — гаечный ключ!
в этой теме еще не было, встречал в других :)

Еще раз
Go преднамеренно, специально — семантически обеднен. Не случайно, а целенаправлено.
А раз обеднен, то значит за это нужно — платить.
И за сложность ЯП, типа С++, Scala — тоже нужно платить.

Аргументы же адептов Go — нет! Go так обеднен, что это его обогатило! (не абсурд ли?)
И — бесплатно обеднен! (еще один. везде и всегда «надо платить», но Go исключение?)

Он обеднен для того, чтобы код читался нормально. Иногда хочется написать что-то с ?:, но потом понимаешь, плата осутствия ?: — это неврзможность написать говнокод из кучи таких операторов.

Вы можете привести конкретный пример, который легко решается на всех языках из списка, который Вы оглашали (C#, Java, PHP, Python, можно без JS, раз Вы его отделили), но решается с костялями на Go, именно для написания бизнес логики?

P.S. Отсутствие дженериков доказывать не нужно, я понимаю, что это проблема для языка со статической типизацией.

неврзможность написать говнокод из кучи таких операторов

Всегда есть 100500 других более красивых вариантов)

Он обеднен для того, чтобы код читался нормально.

ну да, никто раньше при разработке ЯП об этом не думал.
все брали пример с Brainfuck

И вот, ВПЕРВЫЕ, ЧУДО! Появился наконец ЯП код которого читается нормально.

Вы можете привести конкретный пример, который легко решается на всех языках из списка

в смысле забивать гвозди и шурупы гаечным ключем?
так это на любом тьюринг полном языке можно

Отсутствие дженериков доказывать не нужно

там классов нормальных нет. дженерики — то уже вишенка на торте.

и убраны они Пайком — специально
потому что — ниасилаторы сплошные, по мнению Пайка.

даже не могут понять зачем Go обеднен.
Подите и Пайку расскажите, зачем он сделал такой ЯП. с какой целью И для какого класса задач.

Подите и Пайку расскажите, зачем он сделал такой ЯП. с какой целью И для какого класса задач.

PHP по тем же самым причинам и принципам начинал строиться, и именно поэтому получил такую большую популярность. Входной порог был очень низким. И как следствие, он в итоге используется во многих крупных проектах, FB тому пример, а scala/haskell — так широко нигде не используются. Кто здесь выигрывает — совершенно очевидно, ну и в чём тогда смысл запудривания мозгов?

PHP по тем же самым причинам и принципам начинал строиться

не по тем же. что и отражено в аббревиатуре PHP.

и именно поэтому получил такую большую популярность

да, и потому стал — популярным. Популярный не синоним лучший.

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

нет, не потому.
Ему, из-за этой простоты пророчили скорую смерть. Особенно рубисты.

Есть два PHP. тот который стал популярным, и тот, который вобрал с себя наработки из всех C++/Java/C#, и продолжает вбирать. Уже лямбды начали завозить, и возможности контроля типов усиливаются, и просто операторов добавляют.

И в итоге, тот, второй, энтерпрайзный PHP, сейчас по выразительным возможностям обошел Джаву.

В то время как лозунг у адептов Go в этой теме — «да здравствует примитивизм языка!», «любой дурак должен смочь прочитать код!» PHP двигается в сторону усложнения начиная с версии 5 — 2004го года.

Сейчас нанять программиста на энтерпрайзном PHP ничуть не проще чем программиста на Java. и низкий входной порог не дает ему в этом преимуществ.
Для крупных проектов нужно понимать и знать все то же самое что и программисту на Java/C#

Так что пример ваш не туда :)

Так что пример ваш не туда :)

А начиналось всё с чего? С personal home page, что и отражено в названии, и набрал популярность благодаря простоте.

примените свой аргумент к MySQL. как и почему он стал популярным.

и начните везде доказывать что постгресы с ораклом — гуано.

может тогда поймете почему так нелепо выглядит апологетика Go в этой теме.

PHP будет жить пока живет wordpress и magento
Но за последние лет 5 я слышал про ровно ноль стартапов которые начинали писать какой-либо бекенд на PHP

PHP будет жить пока живет wordpress и magento

Вы о PHP знаете из разговоров в курилке какой-то.

Его применяют уже нередко на проектах где лет 7-10 тому только Джаву применяли.

А в списке забыли упомянуть Laravel и Symfony.

Но за последние лет 5 я слышал про ровно ноль стартапов

угу, как на медиуме недавно статейка была, которая так и называлась

«Java убьет ваш стартап. PHP!»

В ваших «знаниях» у меня и не было сомнений :D

basketItems
.Join(products, i => i.ProductId, j => j.Id, (i, j) => new {Cost = i.Price * i.Quantity})
.Where(i => i.Cost >= 100.3)
.Sum(i => i.Cost)

Это типичный говнокод. Выглядит модно и молодежно, но его сложно читать и расширять. Для того чтобы его понять нужно приличное когнитивное усилие. Код должен быть очень простой для чтения.

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

Сделай на гоу лучше, тогда поговорим. Кроме трепаться языком вы — гоубои , мало на что годны, ситуация во всех топиках одинакова — ниодной строчки кода на хваленом голанге.

Вот нашел свой старый комент как мы фиксили OutOfMemoryException в чьем-то LINQ коде который пару лет работал и внезапно начал падать =)
dou.ua/...​et-for-beginners/#1329780

Могу вам код на Go за деньги написать. Что-то доказывать кому-то в интернете не вижу смысла

спасибо за предложение, мне «достоинства» голанга уже известны. свои услуги можешь попробовать продавать другим вместе со своей лапшой — кто знает персонажи, что поверят в безальтернативность голанга, может даже будут тебе благодарны.

Это еще ничего. Можно читать. Тошнит когда есть куски кода с до 20 разных проекций + везде DefaultIfEmpty, который автор не разобрался как работает и сунул. А если там еще ORM везде дергается в этой функциональной простыне. Вобщем LINQ хорош, но он хорош вмеру, как и лямбды. Если надо что-то писать, чтобы быстро работало, то лучше писать циклами вручную, так как LINQ на больших коллекциях очень гробит производительность.

Если надо что-то писать, чтобы быстро работало, то лучше писать циклами

основная оптимизация перформанса редко сталкивается с коллекциями в памяти настолько большими, что они могут стать существенной проблемой в контексте linq. для c# стека и типичных зада куда быстрее будет стоять проблема I/o, а соотвественно трафика, сериализации, компрессии — что чаще всего ещё и на процессор жмет больше всего. Говоря проще вам сперва эту большую коллекцию надо persist или прочитать откуда-то быстро, сам Linq не будет требовать много тюнинга даже на незамысловатом 4х-8ми ядерном железе , если не надо держать на нем реального много rps и если понимать базовые структуры данных , алгоритмы и работу аллокатора.

основная оптимизация перформанса редко сталкивается с коллекциями в памяти настолько большими, что они могут стать существенной проблемой в контексте linq.

Есть таланты, что вытаскивают кучу разных чудовищных по размеру коллекций из базы (что уже очень плохо), начинают их множить их с помощью линк и проекций и строят таким образом репорт. Все это валится через раз с OutOfMemoryException ну и вообще доставляет много слез.

Ну так просто не разобрались когда и как работать с технологией, а винят ее.
При всем при этом семантика linq очень красивая, хоть и медленная, да.
В типичных запросах куча излишних аллокаций для анонимных классов, делегатов. Часто linq не знает с коллекцией какого размера работает, соответственно дополнительные выделения памяти проводит, что может провоцировать GC
Кроме того диспатчинг методов через интерфейс всегда значительно медленней, чем диспатчинг через конкретный класс.
Проводил замеры c BenchmarkDotNet на типичных запросах, производительность linq по сравнению с циклами может быть хуже в 10-20 раз.
Но говорят, что в .NET Core все стало лучше значительно, еще не проверял.
В любом случае в своей практике не встречался с ситуациями, где тормоза от linq имели какое-либо значение.

Для того чтобы его понять нужно приличное когнитивное усилие.

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

Да и компьютеру тоже нифига не понятно, он хочет видеть for и goto ))))

Я писал больше 10 лет на c#/.net и перешел на Go. Пишу всего лишь год на нем и считаю что c#/.net как и джава — технологии прошлого тысячелетия по сравнению с Go. Многие вещи за вас решены создателями (как писать тесты, как форматировать код и т.д.). Сам язык очень простой и очень хорошо подходит для современной cloud-native microservice архитектуры. Сначала мне не хватало дженерик типов, но теперь мне кажется что они просто не нужны :)

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

Люто плюсую! ;))

Если все так, как вы говорите, почему TIOBE индекс дает Java 1-е место с 16%, а Go — 14-е с 1% ?

TIOBE индекс дает Java 1-е место с 16%

А ещё лет 5 назад у java было около 25%.

Если не ошибаюсь, Go был выпущен в 2009 году. Что помешало ему за 10 лет влезть на первое место, раз он такой крутой ?

Аргумент из серии «электрические машины изобрели 50 лет назад — почему до сих пор мы все не ездим на электрических машинах?»

Так никто и не говорит, что все остальные виды транспорта не конкуренты электрическим машинам. У электрических машин есть существенные недостатки.
Так, что отмазка не катит..

намекаете на то, что у Go нет достаточно инфраструктуры(зарядные станции с быстрым режимом зарядки) и технологические ограничения(емкость аккумов)?

Безудержно плюсую.

Насколько нужна математика в низкоуровневом программирование?
Что делать если уровен математики 7-го класса? Есть ли шанс попасть в эту сферу?
Какие перспективы низкоуровневой разработки в Украине?

Го в основном любят в микросервисах, всяких утилитах, и простых сервисах типа мониторинговых системах. Спрос на него есть, т.к. он достачно силен в своих нишах, где не нужно жирное ООП и тащить миллион пакаг или рантайм джавы. Проектов на нем мало, но есть и достаточно сильные и серьезные вещи. Не нужно его рассматиривать, как панацею и переписывать все на Го, потому что это стильно, модно, молодежно. В некоторых нишах он уделывает лапшу на JS, пыху и джаву, т.к. сам язык очень простой и без зубодробительных конструкций и магии «как это работает».
Как правило вместе с Го нужно знать брокеры типа Kafka/RabbitMq, docker, понимать что такое кубернетес ну и кучу пачку остального, что относится к контейнеризации/микросервисам. Понимать что есть колоночные БД/nosql. В зависимости от уровня знаний уровень вашей з/п будет существенно отличаться, т.к. чистый Го будет недостаточно для вхождения на проекты

знать брокеры типа Kafka/RabbitMq, docker, понимать что такое кубернетес ну и кучу пачку остального, что относится к контейнеризации/микросервисам. Понимать что есть колоночные БД/nosql.

Это ща практически в любой распределенной системе

Го в основном любят в микросервисах,

Тойже джавы в микросервисах полно (там где нету надобности экономить мегабайты оперативки).

Go это современный Си. достаточно низкоуровневый язык , не очень подходящий для моделирования сложных абстрактных типов данных . у него есть своя ниша (софт для управления сетевыми сервисами, девопс тулзы, контейнеры, низкоуровневая часть движка базы данных и тд ) но вряд ли он станет альтернативой языкам общего назначения (Java/Scala/Ruby/Python) на бэкенде. но это не страшно — если вам захочется написать что-нибудь на Го в рамках крупного ентерпрайз проекта, запилите его в микросервис

1. не современный
2. не С
3. Ваш вариант?

Да супер все. Но проектов на Go — маловато. В крупных компаниях так вообще почти нет. Так что только в стартапы идти.

в таких как amazon, google, и тп есть :-)

Если бы они еще и в Украине были...

Там еще есть Java, Python и даже больше, чем Go. В MS тоже есть Go, но только в команде, которая поддерживает K8S для Azure. В целом не так уж и много, а в Украине наверно и того хуже. Uber правда полностью пишет все на Go.

ты в Убере?

Нет — ходил к ним на интервью до того, как у них начались увольнения. Ну и на meet-up общался часто с ними.

интересные там ребята я их на конференции слушал, про микросервисную архитектуру рассказывали

Если честно, мне кажется у них бардак. Ну 3500 сервисов и это не считая масштабирования. Они сейчас пытаются перейти на моно-репу и как по мне, это как раз и результат вот такой бездумной архитектуры. Но в целом они делали неплохие вещи — многие контербьютили в Go, тот же cadence под Go. Вообщем был хайп и много хорошего народу к ним пришло, ну и деньги лелись реками :))

А скільки в них розробників, щоб таку купу сервісів підтримувати?

Не знаю — в 2016 если верить интернету было 2000. Как я сказал — денег было много :)) А не могу понять зачем им столько сервисов — это по сути одно приложение, но пусть есть какие-то имплементации под отдельный рынок. Написать много сервисов — ума много не нужно, а потом это как-то поддерживать, внедрять, интегрировать ? Это же не Amazon — у которого сам бизнес просто огромен с точки зрение всего, что они делают. И как-то чуваки справляются.

Не Убером единым ) . У Monzo 1.5K микросервисов monzo.com/...​lation-for-1-500-services )

В каждой непонятной ситуации пили новый микросервис)

To start we wrote a tool called rpcmap. This would read all the Go code in our platform, and attempt to find code that looked like it was making a request to another service. In doing so, the tool maps out the connections between our services and the services they call. This wasn’t perfect, but it was good enough to build a list of services that need to call the ledger. We then manually checked this list to make sure it was accurate.

да, мне тоже это место понравилось.

видя что они лишаются возможностей статической проверки типов, линковки (и даже общего рантайма, как в ЯП с дин типизацией) они написали свой аналогичный инструмент.

Ну и естественно под него пришлось добавлять
special comment in the code that told rpcmap about the link

Как-то и не верится что одной строчкой обошлись.
По идее надо нечто вроде WSDL было изобрести.

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

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

Я бы ще додав, що більшість проектів на Го це лютий отстой, в якому ковирятися так само приємно як і в класичному 20-ти річному ентерпрайзі. Пишуть їх в більшості люди які з того Го вивчили лише синтаксис і пишуть на ньому в Java/PHP/ect-стилі, з фабриками сервісів, з іменуванням в дусі і т. д.
В стартапах на Го люблять писати лише тому, що це звучить модно, стильно, молодіжно. Там де можна обійтися ледве не однострочником на Пітоні, крутять якусь люту неідеоматичну лапшу на Го.
Для мене це головне розчарування сегменту, що зайняв Го на масовому ринку.

тоже самое можно сказать за пыху и за джаву, всегда будет проект с говнокодом. Да, неприятно, что простые проекты на Го начинают раздувать жирными либами и говнофреймворками, которые имитируют DI и ООП, и все это работает через адовую мешанину кода из reflect. Примеры — beego, gorm, uber fx...

gorm

зашел на главную страницу и увидел
Associations (Has One, Has Many, Belongs To, Many To Many, Polymorphism)
Hooks (Before/After Create/Save/Update/Delete/Find)
Preloading (eager loading)
потом зашел посмотреть бегло сигнатуры
godoc.org/github.com/jinzhu/gorm
и понял что это конец. из го городят джаву. это надо умудрится было все эти раковые идеи притащить в го.

которые имитируют DI и ООП, и все это работает через адовую мешанину кода из reflect.
и понял что это конец. из го городят джав

это оттого что стали применять для таких задач и так, как он не задумывался.

и тут-то оказалось — а слаб. ну вот и берут пример с более мощных ЯП

ну и ладно, не удивлюсь если не только дженерики, а и классы в нем появятся :)
а потом и эксепшены подвезут.

как выше PHP помянули. Как нужно стало писать приложения посерьезней — так и стали в язык добавлять — серьезные возможности.

ну и ладно, не удивлюсь если не только дженерики, а и классы в нем появятся :)
а потом и эксепшены подвезут.

Есть драфт касательно контрактов на Go, как аналог дженериков. Ексепшены в Go и так есть изначально в виде механизма panic-recover, а классы не нужны, поскольку концептуально другая реализация ООП. Кроме того, есть также драфт по упрощению обработки ошибок, в общем-то все об этом уже читали, кто на Go пишет, причём этот драфт самый эффективный.

Есть драфт касательно контрактов на Go, как аналог дженериков.

еще раз.
на любом тьюринг полном языке можно написать что угодно.

я начинал свою карьеру с С
и мы там вполне эмулировали и классы.

но это не значит что это
нужно делать
что это делать — удобно.

а классы не нужны, поскольку концептуально другая реализация ООП

у той, другой — дооолгая история развития.

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

Для каких задач задумывался — такой и дизайн у ЯП.

У Джавы поэтому тоже, так себе. Для кофеварок же.

Начиная с 5ой версии конечно — она стала окончательно языком для других задач.

Go задумывался для быстрого написания микросервисов?
ну вот поэтому он такой простой и сделан

а не потому что Пайк и Ко думали о каких-то нубах, которым видите ли сложно код читать.
Тролил конечно :)

я начинал свою карьеру с С
и мы там вполне эмулировали и классы.

Это в каком году было? И зачем? Раньше был всем известный тогда VC++98, до этого Borland C++, Watcom C++

И в этом vc++98 была проблема, которая просто бесила и которой не было в Borland C++:
for(int i = 0; i < 10; i++){} обьявляло i во внешнем скоупе, а не в скоупе for, т.е. после for она существовала. В след версиях микрософт исправила это.)))

Так вас никто не заставляет использовать ORM. В микросервисах вообще 1-3 таблицы максимум в базе должно быть — зачем там орм? Я в последнее несколько лет на .net/c# использовал dapper.net и не нужно было никаких EntityFramework который майкрософт так везде пиарит

Так вас никто не заставляет использовать ORM.

Да меня также и никто не заставляет на го писать. Если мне понадобится я смогу написать микросервис и на C#, и о ужас! он будет работать также само быстро и клево как и на го.

В микросервисах вообще 1-3 таблицы максимум в базе должно быть — зачем там орм?

микросервисы вообще не нужны, но это другая тема. у меня в базе около 1000 таблиц и там какой-никакой орм нужен.

Я в последнее несколько лет на .net/c# использовал dapper.net и не нужно было никаких EntityFramework который майкрософт так везде пиарит

Тут вообще не мне решать, я ж не лабораторку взял кому то делать. У нас своя самописная орм на адо.нет, которой уже больше 10 лет и многостраничная дока о том как писать код запрещает мне где-то слева прикрутить к проекту EntityFramework или еще что-то, что мне зачесалось.

Це тільки мені здається, що автор справляє стійке враження невігласа, який не написав жодного рядка коду, і натякає які погані і недолугі php, python, ruby?.. і особливо php?

Покажіть мені де я написав що php, python, ruby недолугі? Ви самі щось таке видумали, аби за щось зачепитися

Най Бог боронить! Нікого обмовляти не хочу, я ж пишу що мені «здається». І здалося конкретно після того як прочитав цю фразу:

ТАкие языки как php, python, ruby... К другим языкам особого интереса нет, особенно к php..

Після читання таких фраз мимоволі з*являється думка, про те що в клубі безпітставного хейтінга php прибуло.. :)

Php поважаю та не хейтю, просто він мені не дуже сподобався, от і все

А то начбето підстав мало, ге?

в такому разі, цікаво почитати Ваші аргументи? бо поки що, аргументація відверто слабка.

В Украине перспектив нет, инновационные проекты родную гавань (страны 1 мира) не покидают. Сюда заказчики приходят потому что их устраивает соотношение рисков/качества к цене. Гениев забирают довольно быстро к себе и бережно растят для великих дел.

Выскажу сугубо личное мнение: Я не совсем понимаю, откуда такая практика как «напишем все на XXX»
Golang — идеальный инструмент для решения высконагруженных задач, где требует высокая конкурентность и т.д.
Вот так его и надо использовать. К примеру сочетание Ruby( или PHP или Node.js и так далее) + Golang дает потрясающий эффект при грамотном проектировании.
Вы быстро пишите бизнес логику, а в ситуациях, когда необходимо что-то соот. задачам Golang, соот. участки выносятся как выделенные микросервисы.
Соот. Вам, как backend разработчику необходимо владеть не только Golang, но и как минимум + 1-м языком, на котором активно решают бизнес задачи.

Потрясающий эффект скорее может дать правильное проектирование архитектуры с разделением, или наоборот объединением функционала в 1 сервис. На чём он будет написан — это уже другой вопрос. Но писать на сегодняшний день лучше на Go.

правильное проектирование архитектуры

то есть потребуется ЯП и подходы применяемые в энтерпрайзе

объединением функционала в 1 сервис

то есть — монолит

Но писать на сегодняшний день лучше на Go.

и Go как раз имеет слабости, как ЯП в обоих случаях

Его применять нужно как раз когда выбран микросервисный подход.

И дает он эффект в связках

Ruby( или PHP или Node.js и так далее)

когда выделяется отдельный микросервис

Я не совсем понимаю, откуда такая практика как «напишем все на XXX»

объясню одним словом — джуны

объясню одним словом — джуны

... верующие в серебрянную пулю

Я не совсем понимаю, откуда такая практика как «напишем все на XXX»

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

Знания разных стеков — это еще и владение разными подходами, иногда очень помогает.

пишите на скале — 10 подходов в одном языке (да еще и джава изподнизу) — вин вин :-)

у меня муж на скале пишет. Говорит все хорошо, пока не начитает лезть в кусок, который писал не он

чем это отличаеться от того, что ты пишешь на ГО, но вдруг нужно лезть в кусок написанный на дотнете ?

тем что скала там и тут != го тут и дотнет там?

Вот в этом и крутость Go! Что сложнее написать говнокод на уровне синтаксиса.

при грамотном проектировании.

При грамотном проектировании даже джава дает потрясающий результат, другое дело что «грамотное проектирование» — какаято несуществующая утопия.

Есть кто на Golang под Docker пишет или нет тут таких?

Є, щоб ще додатково C бібліотеки підключати

да не докер вроде на го и написан.Зачем?

Так Docker написаний на Go, запускаєш Go в контейнері бо так зручніше, встановити потрібні ENV, версію Go, підключити сертифікати та додаткові apt бібліотеки

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

Go еще долго догонять на бекенде: Java, PHP, C#, и даже JS/TypeScript на Ноде.
при всех его уникальных достоинствах — на нем неудобно писать бизнес логику. а она и есть в основном на бекенде.

но. нравится? начинайте с него. как первый ЯП — вполне. потом разберетесь.

Но ведь перспективы у этого языка видны во многом только в бэкенде.. И мне кажется что гугл сделает в будущем его удобным для написания бизнес логики и всех таких проектов...

кому видны?
мне, в основном бекендеру, в области бизнес ПО — не видны.
а гугл — не может сделать с «русского» — «английский», без того чтобы уничтожить «русский»

Если же Go сделать как Java/C# - то зачем он тогда нужен?
Вам нужно погуглить выступления Пайка, где он указал причины появления Go, таким каким он есть. Таким — каким его любят использовать.

Просто, главное преимущество — и есть главный недостаток. и наоборот: главный недостаток и есть главное преимущество.
Это касается и Java, и PHP, и Go

На Go сложно писать бизнес логику. Так это ж прекрасно, это означает что с него выброшены возможности для этого! А бекенд — это не только бизнес приложения, хотя и в основном.

гуглите Роберта Пайка

А переписують з PHP на Go, щоб бути в тренді?
А з Java на Go бо Oracle судилась з Google?

з PHP на Go переписувати ще менше сенсу аніж з Java на Go

наприклад автори RoadRunner зробили його для себе. І використовують і PHP і Go у своїх проектах.
а на питання з залу — а чому ж повністю на Go не перейшли відповідають
Поки наша команда на Go закінчує реліз № 1, наша команда на PHP вже здала замовнику реліз 3
Для мене очевидно чому :) Як думаю вже не потребує доказів теза — розробка на Java швидша аніж на C++

Швидкість розробки — ось фактор який постійно забувається у холіварах про мови програмування
А для бізнесу — це чи не найголовніший параметр технології.
Другий, звісно — надійність, передбачуванність розробки.

Але Go не має переваг по цих обох параметрах, коли мова про — «бізнес-логіку»

Але якщо тра штуку тіпа RoadRunner написати, або Centrifugo — то на зараз думаю найкращий. По цих обох параметрах — швидкість написання, та надійність роботи, та передбачуванність розвитку такого класу програмного забезпечення.

В нас розробка на Go йде швидше ніж у команди на PHP, задачі звісно різні, Go для бізнес логіки та збереження статистики, PHP для адмінки та виводу статистики

Швидкість розробки окрім мови залежить і від досвіду і від задач і від процесів в проекті

тобто ви набрали джунів на php, та вони пишуть як заманеться, без процесів? ;)

Команда на PHP вже з досвідом, але на Go додаємо швидше

тобто досвідченні программісти поступаються швидкістю розробки менш досвідченним?

Обидві команди і Go і PHP досвідчені, але останню задачу можна було зробити і на PHP і на Go, вибрали Go, бо так швидше і ще й швидше працюватиме код

не знаю усіх подробиць, та і ви самі додали що задачі — різні, а це означає що порівняння — неможливе :)

але — буде швидше працювати — це взагалі з іншої опери, і ніякого відношення не має до питання — на чому швидше розробляти.

та навіть коли й брати цей параметр, то зазвичай вузьким місцем у бізнес проектах стає персистенте сховище, а не аплікація.

можливо у вас якийсь нетиповий для бізнесу проект, коли чомусь швидкодія у топ параметрах.
а для купи проектів заважка для php транслятора Magento — найкращий вибір — для бізнесу.
...колись JVM була набагато гіршою аніж зараз. та й як мова, так собі, у порівнянні з Обероном. Але чомусь ані більша швидкодія аплікацій на С++, ані більш розвинена мова, С++. не завадилі Джаві вийти на головну мову для бекенд розробки — ПЗ для бізнесу.

довго пояснювати, та й нещодавна пояснював у двох темах.
а тільки після цього можна переходити на порівняння — мов программування, а не реалізації їх трансляторів.

Хіба так не усюди?
Джунам ще цікаво програмувати, а сіньорам давно все одно, треба 8 годин відсидіти в ютюбі.

джуни ще не вміють програмувати. вони кодери. тому й — джуни.

а сіньори яки сидять по 8 годин в ютьюбі — то якийсь мабуть жарт :)

та й натяк що синьорам не цікава їх робота — теж дивний.
у тому що нецікаво — вкрай важко досягти професіоналізму.

при всех его уникальных достоинствах — на нем неудобно писать бизнес логику. а она и есть в основном на бекенде

С чего бы вдруг, на js вы же считаете удобно писать бизнес-логику? Вот и на Go логика пишется по тем же самым принципам, плюс там строгая статическая типизация как в C#. Реально Go на самом деле всех перегнал по простоте и скорости написания кода, и при этом выигрывает ещё по производительности. Комьюнити и набор либ уже накопился достаточно большой.

С чего бы вдруг, на js вы же считаете удобно писать бизнес-логику?

вполне.
Но конечно лучше тогда брать TypeScript :)

Вот и на Go логика пишется по тем же самым принципам,

писать можно и на Brainfuck

речь об удобстве для классов задач

там строгая статическая типизация как в

строгая типизация не является удобством или неудобством для написания бизнес-логики

Реально Go на самом деле всех перегнал по простоте и скорости написания кода,

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

Комьюнити и набор либ уже накопился достаточно большой.

покажите мне электронный магазин на Go :)

и как меряете — «достаточно большой»? с какими ЯП сравниваете его комьюнити?

С чего бы вдруг, на js вы же считаете удобно писать бизнес-логику?
вполне.
Но конечно лучше тогда брать TypeScript :)

тогда таки лучше брать другой язык если статическая типизация критична — тот же котлин

берите, кто ж запрещает. Обычно Джавы хватает :)

а TypeScript берут нередко потому что у него — опциальный метод типизации.

но конечно его берут чаще для целостности экосистемы: бекенд+фронтенд.
или для сложных SPA

И. статическая типизация нередко неудобна при программировании бизнес-логики. В силу изменчивости и нелогичности этой самой бизнес-логики.

строгая статическая типизация как в C#

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

Но мы ушли от темы.
От голословного тезиса:

Реально Go на самом деле всех перегнал по простоте и скорости написания кода

На bash’е код еще быстрее писать.

Ну эта тема уже размусолена сотни раз, в чём преимущества Go перед старыми промышленными языками. Такими, как java/C#/C++. Авторы Go о них не знают? Прекрасно знают, и именно благодаря накопленному опыту и сделали новый язык для промышленной разработки.

Мне кажется, или го писался гуглом для гугла?

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

для промышленной разработки — чего именно?

Авторы Go о них не знают?

Конечно знают.

Адепты Go только не знают о преимуществах Java/C#/C++ перед Go, от которых авторы Go отказались по вполне конкретным и прагматичным причинам

для промышленной разработки — чего именно?

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

Адепты Go только не знают о преимуществах Java/C#/C++ перед Go, от которых авторы Go отказались по вполне конкретным и прагматичным причинам

Это всё потому, что адепты Go раньше писали на Java/C#/C++, после чего перешли на Go, и положили болт она все эти преимущества.

даже в гугле адепты С++ с него не соскочили

С крестов вообще нет смысла соскакивать ни на что!

адепты Go раньше писали на Java/C#/C++, после чего перешли на Go

Цитата
Так для чего же он был создан таким простым? Вот пара цитат Роба Пайка:

Ключевой момент здесь, что наши программисты (прим.пер.: гуглеры) не исследователи. Они, как правило, весьма молоды, идут к нам после учебы, возможно изучали Java, или C/C++, или Python. Они не в состоянии понять выдающийся язык(a brilliant language в оригинале), но в то же время мы хотим, чтобы они создавали хорошее ПО. Именно поэтому их язык должен прост им для понимания и изучения.

Почему дизайн Go плох для умных программистов
habr.com/ru/post/344356

Пайк потролил конечно и Джаву, но и указал что Go для ниасилаторов :)

Давайте ещё раз перечитаем цитату:

Они не в состоянии понять выдающийся язык(a brilliant language в оригинале), но в то же время мы хотим, чтобы они создавали хорошее ПО.

Что это значит? Это значит, что при одинаковых затраченных усилиях одного и того же человека, качество кода на Go будет выше. Или другими словами, стоимость создания хорошего ПО на Go будет ниже, чем на другом языке. Вот и всё.

А что касается статьи на хабре — там чувак во-первых не до конца разобрался в сути, и практически каждый пункт можно оспорить.
«Культурный багаж из Си» — только на 1-й взгляд, в отличии от C там есть замыкания и свои коротины, что кардинально меняет подходы.
«Горе управления зависимостями» — это в C++ горе управления зависимостями, причём не в переносном смысле, а в прямом большая беда.
«Ад копирования», «Простой обход системы типов» — пусть лучше вникает где и как юзается утиная типизация.

Это значит, что при одинаковых затраченных усилиях одного и того же человека, качество кода на Go будет выше

никак не значит.

вы помянули PHP — так там быстрее писать код как на старом PHP.
но если надо качественный — то надо на энтерпрайзном.
При этом большинство программистов на PHP не могут писать на энтрепрайзном PHP. несмотря на стаж 3+ лет. Он даже вредит :)

вот Пайк и сделал ЯП, как ранний PHP.

Или другими словами, стоимость создания хорошего ПО на Go будет ниже, чем на другом языке. Вот и всё.

не могут нубы делать хорошее ПО.
какой им язык не дай.

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

при этом эти сервисы обычно — простые, но работающие с высокими многопоточными нагрузками.

Поэтому — выбрана непривычная для мейнстрим ЯП многопоточная парадигма — попроще, и одновременно — с меньшим оверхедом, с с своим, легковестным управлением горутинами.
И поэтому выброшено из Go то, что нужно для разработки сложного ПО — он проектировался НЕ для сложного бизнес ПО.
Даже системы управления пакетами не было. Зачем она, если микросервис нужно будет писать весь с нуля?
тоже и с пошаговой отладкой — зачем она, для простого приложения?

но адепты теперь рассказывают о какой-то более высокой читабельности, и почему-то нубами, и прочем.
Будто ломанувшиеся на Go нубы — это великая ценность, и наконец-то нубы начнут писать качественное ПО!

А Go — это COBOL для клаудного софта.
не больше.

но и не меньше.
Очень хороший инструмент.
Мне даже странно что столько на Джаве написано было, вместо того чтобы изобрести «COBOL для клаудного софта», и писать на более подходящем ЯП.

При этом, еще о PHP
другая корпорация с подобного масштаба потребностями пошла другим путем
на основе PHP изобрела ЯП Hack. Пострадал ли бизнес FB от этого? что они создали ЯП со всеми привычными, «С++», концепциями?
Упала ли продуктивность программистов в FB, а в Гугле выросла — в разы?

отсутствие статической типизации не всегда плохо. на фронтенде как раз хорошо

Да писать с любой типизацией можно. При динамической разве что надо помнить о том, что может быть неочевидное преобразование типов строка<=>число, и в качестве аргумента функции могут впарить что угодно. Статическая позволила бы устранить ряд ошибок на том же фронтэнде на этапе компиляции в байткод например. Дальше сами понимаете, какие преимущества из этого вытекают.

Дальше сами понимаете, какие преимущества из этого вытекают

Да никаких. В реальности % проблем со скармливанием чего то не того это мизер и долго грабли не ищешь, обычно это очевидные косяки, которые IDE хинтят давно + инлайновые доки еще делают их умнее. В любом случае сборка по файлватничнгу на тестах упадет при первых же изменениях кода, даже с поверхностным покрытием, что по сути даже раньше всяких там компиляций :)

Да можно писать с любой типизацией в Notepad и деплоить сразу в PROD. Все можно, но долго, нудно и больно. А нормальные пацаны почему-то пользуются TypeScript, где как раз эта типизация и есть.

А нормальные пацаны почему-то пользуются TypeScript, где как раз эта типизация и есть.

Тут доказывают, что динамическая типизация сильно удобна на фронтэнде, а вы о ts вспомнили, единственный смысл которого в статической типизации. Пусть объяснят MS, что они фигнёй маются, и ts не нужен. А заодно и гуглу, а то они порывались вообще кардинально фронтэнд изменить со своим Dart.

ТС — булшит от микрософта. В нем смысла нет, т.к. все равно в npm_modules лежит 1000 пакетов где на ТС просто положили и все равно в самом ТС все прокинуто через any и в рантайме не отследишь, прилетит с бэкенда «100» строкой или числом, т.к. вся типизация проверяется лишь на этапе компиляции

ТС все прокинуто через any и в рантайме не отследишь, прилетит с бэкенда «100» строкой или числом, т.к. вся типизация проверяется лишь на этапе компиляции

:facepalm:

А что вы хотите. TypeScript «компилирует» все в JS. Все что вы сказали должно покрываться UI тестами.

для фронтенда да, для бэка — нет. Как раз куча проблем вылазит из-за отсутствия строгой типизации. Преимущество строгой, что большинство тупых ошибок типа «1.01» != 1.01 отбрасывается на этапе компиляиции, а не в проде

начинайте с него. как первый ЯП — вполне

а что-то говорят продукты Docker, Kubernetes, CockroachDB, InfluxDB, Nats, Vault, Consul, Terraform, Nomad — все это написано на Го и многое из этого сейчас индустриальный стандарт во многоих компаниях и продуктах.

знаю только о Docker, Kubernetes. Остальные названия мне ни о чем не говорят.

многое из этого сейчас индустриальный стандарт

список серверного ПО написанного на Java — приводить?

на С/С++ конечно уже вообще никто не пишет ПО этого класса.

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

Остальные названия мне ни о чем не говорят.

если ниче не говорят, то не надо спорить о бесполезности Го в теме про Го. Для общего развития надо знать что это такое

Для общего развития надо знать что это такое

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

о бесполезности Го в теме про Го

о «бесполезности Го» — это у адептов галлюцинации :)

Скажите, а что почитать для разработки под Docker на Golang?

Что значит под докер? Для проекта докер или для запуска в докере?

Хочу купить книгу по Golang, ранее с программированиям не был знаком, но в душу впала сфера back end и язык Golang. Такие языки как руби, пхп, питоне не интересуют. ДАйте отзыв о книге «Язык программирования Go. Алан А. А. Донован Брайан У. Керниган». Стоит ли ее читать, для разработки под бэкенд, да и вообще книга подходит для новичка?

Читав, книга зрозуміла, для початківців під питанням, ось мій набір для вивчення STUDY.md

Я посмотрел Ваш набор, в принципе неплохо, но я только что нашел сайт Метанит, что можете сказать по нему?

По Go його пропустив, але бачив на цьому форумі його рекомендували з C#

Есть ли смысл пробовать на метаните? Некоторые люди говорят что метанит плохо влияет на новичков

Лучше Head First Golang. Приведенная вами сильно сложнее для новичка

Серія Head First дійсно докладно і якісно описана, але про те, що в них вже є і Go дізнався тут вперше

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

очень рекомендую видеокурс от William Kennedy www.oreilly.com/...​rogramming/9780135261651

Предполагается что вы уже имеете опыт программирования на другом языке
Курс платный, но если нет денег — можно просто несколько раз start free trial ;)

Для розробки API дуже комфортний і тести простіші ніж в PHP, але адмінку скоріше будеш робити на PHP чи Python чи Ruby бо вже багато готових

Скрапер DOU теж робив на Go, але постійно дивлюсь в сторону Rust-у

Вот как раз для разработки какого-то публичного REST API Go очень неудобный, особенно если сравнивать его с руби. Например Swagger надо писать руками, сгенерировать документацию нельзя, плюс кучу всего надо писать ручками. Например валидации, есть govalidator, но с ActiveRecord::Validator его даже не смешно сравнивать.

Да, есть, он относительно новый и довольно популярный.
Когда появится следующий перспективный язык — спокойно перескочите.

Подписаться на комментарии