LINUX.ORG.RU

golang в бизнесе

 


0

2

Прочитал пару дней назад учебник по golang, и с первого взгляда вроде норм язык. Но часто слышу его обсирание(сложно в бизнес логику). Собственно вопрос что не так с Go, кроме того что там нету enum-ов и generic? Я так понимаю проблемы с батарейками?

★★
Ответ на: комментарий от hbee

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

Чтобы делать работу над ошибками, надо хотя бы немного разбираться в вопросе. Роб Пайк и ко просто не в курсе того, что происходило в PLT с середины 80х, ООП в Go нет не потому, что они его преодолели, как Haskell и Rust например, а потому, что они до него еще не доросли. Go - это попытка вернуть все взад.

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

Да есть там исключения, причём интенсивно используются в стандартной библиотеке. Просто их, видимо, спрятали от школьников. Была уже (моя) тема «хочу паниковать», там приведены все пруфы.

den73 ★★★★★
()

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

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

Java это не весь мир. В С++, если нет виртуальных методов, наследование строго бесплатно.

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

В С++, если нет виртуальных методов, наследование строго бесплатно.

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

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

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

Нет, panic — это не исключение. Когда в другом языке ты бросаешь исключение, ты делаешь его проблемой вызывающего (и запутываешь программу хуже любого количества goto). Тогда как panic — проблема приложения в целом, настолько серьёзная, что должна завершить процесс. Обработка паник добавлена только для библиотек, потому что библиотеки не должны рушить процесс. В прикладном же коде не нужно ни вызывать, ни обрабатывать panic. Именно поэтому она намеренно сделана весьма ограниченной. Если тебе хочется рутинно использовать panic, то это признак серьёзных проблем с пониманием языка.

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

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

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

Ты путаешь сам механизм и рекомендации по его применению. Паника не исключения только по названию. По сути это то же самое. Можно сказать: 2*2 численно равно 4, но это не 4. Примерно то же, что сказать «паника - не исключения». Чистое богословие. Давай не будем тратить время, уже обсуждалось неоднократно, и контрпример gin приводили, который перехватывает панику (и процесс не завершается).

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

Если тебе хочется рутинно использовать panic, то это признак серьёзных проблем с пониманием языка.

Поставь в отладчике брекпойнт на функцию gopanic, запусти любую свою программу и удивись. Оказывается, авторы го не знают языка. Также читай https://hackernoon.com/panic-like-a-pro-89044d5a2d35

+-------------+-----------------+
| name        | count of panics |
+-------------+-----------------+
| go          |            4050 |
| kubernetes  |            4087 |
| gin         |              46 |
| prometheus  |             693 |
| terraform   |            1161 |
| echo        |              14 |
| dep         |             157 |
| gorilla mux |               9 |
| mysql       |               5 |
| pq          |              46 |
+-------------+-----------------+

Авторы всех этих проектов не знают языка.

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

Тогда как panic — проблема приложения в целом, настолько серьёзная, что должна завершить процесс.

Серьёзная проблема решается с помощью log.Fatal, который есть os.Exit. Это тоже подробно обсуждалось в теме «хочу паниковать». Потому что defer-ы могут зависнуть и у тебя нет гарантии, что процесс завершиться. Т.е. как раз для серьёзных проблем, требующих немедленного завершения, паника не годится. И с другой стороны, в gin паника не завершает процесс. Т.е. то, что ты пишешь, никак не соотносится ни с практикой, ни со здравым смыслом. Тебе промыли мозги. Оставь свои мозги промытыми, другим людям хотя бы не промывай.

Ну зачем это повторять?

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

Именно поэтому она намеренно сделана весьма ограниченной

Она ничем не ограничена. Напротив, она едва ли не более мощная, чем исключения в C++.

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

Так и рождаются глючные программы.

den73 ★★★★★
()

В go нет ни одной orm, нужно писать простыни текста чтобы отдать простой json.

  • быстрый
  • меньше жрет оперативки чем Java
  • кода писать меньше по сравнению с другими «низкоуровневыми» языками
  • встроенная асинхронность
  • нет шаблонов и макросов, которые делают код на C++ полностью нечитаемым
  • иногда проигрывает в скорости той же яве
  • сосет с заглотом у божественной сишечки
  • ни разу не ООП
  • сложнее реализовывать стандартные паттерны (следует из предыдущего пункта)
  • асинхронный код сложнее понимать
  • нет нормальных фреймворков
  • на Python схожее по функционалу приложение пишется в 3-5 раз быстрее, что делает использование Go не рациональным, проще держать в штате 1 питонщика чем 3 гошников, железо единожды дешевле купить чем пару лет платить зарплату лишним людям (а зп у программистов в Питере - это тыс 100 в среднем)
tz4678 ★★
()
Ответ на: комментарий от tz4678

ну и главный минус - неудобная обработка ошибок (тут уже упоминали). вместо try/catch нужно постоянно извращаться data, err := someFunc(); if err != nil { ... }. это боль.

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

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

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

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

Покажите на кукле где вас трогали сишники.

по стечению обстоятельств имеет две начальные буквы из любимой фекальной темы линуксоидов

Я, как линкусоид, крайне заинтригован, что за тема такая?

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

Динамический диспатчинг в плюсах — это одно дополнительное обращение к памяти. Кастинг, если не используется virtual base — то это прибавление константы к регистру; если используется — тоже одно обращение к памяти.

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

Покажите на кукле где вас трогали сишники.

Постоянно дешёвые понты как в школе летят здесь от таких.

Я, как линкусоид, крайне заинтригован, что за тема такая?

Ну, любят здесь ассоциировать всё, что можно и нельзя с говном.

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

нужно писать простыни текста чтобы отдать простой json.

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

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

Постоянно дешёвые понты как в школе летят здесь от таких.

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

Ну, любят здесь ассоциировать всё, что можно и нельзя с говном.

Аа, теперь понятно.

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

т.е. такая параша:

type Tree struct {
    Value int   `json:"value"`
    Left  *Tree `json:"left"`
    Right *Tree `json:"right"`
}

это не оверкилл когда на питоне ты можешь просто сделать json.dumps(dict(foo=‘bar’)) и т.п. без описания моделей? тут еще костыли в синтаксисе придумали чтобы в нижний регистр поля переводить, потому что это такая «классная» идея, что у нас все что начинается с нижнего регистра приватное и не сериализуется. у меня следующие мысли:

  1. PascalCase - самый ублюдский стиль. В IDE я ввожу пару первых букв, потом жму таб и стрелочками выбираю нужное, а тут мне еще лишнюю кнопку нажимать (вместо 10 нажатий клавиш у меня 11, а это считай дополнительный месяц работы (ну неделя-другая точно)); Табы вместо пробелов - вообще охеренное решение, теперь форматирования кода в разных редакторах выглядит по-разному (а где-то таб 8 пробелов);
  2. Где нормальная обработка исключений?
  3. Что в Go есть нового? Callback-hell я уже видел в яваскрипте;
  4. Возвращение функциями нескольких значений (распаковку тупла) - в Python;
  5. await/async есть в куче языков, defer не видел, но в других языках это эмулируется через:
function bar() { console.log('bar') }
function foo() { try { return bar() } finally { console.log('foo') }
foo() 
tz4678 ★★
()
Ответ на: комментарий от tz4678

Go - мертворожденный высер как Dart. Лучше бы какой-нить SugarScript придумали, а не это байтобство и елю с типами.

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

Вот почему второй вариант лучше?

Split(ToLower(s), sep) s.ToLower().Split(sep)

  • Потому как мы пишем s, нажимаем точку и в IDE у нас вываливается список методов строки. Удобно? - Очень! А в go нужно в глобальной области видимости что-то искать. Это недостаток процедурных языков.
tz4678 ★★
()
Ответ на: комментарий от anonymous

Java это не весь мир. В С++, если нет виртуальных методов, наследование строго бесплатно.

ага еще и бесполезно

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

Наследование поведения, а значит — полноценный ООП, есть в Go.

Трижды плюсую. Переключение на c++ с его ООП и классами дикая боль после go. Как минимум go ничем не хуже в этом плане.

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

это не оверкилл когда на питоне ты можешь просто сделать json.dumps(dict(foo=‘bar’)) и т.п. без описания моделей? т

Я в голанге вообще-то нуб, но вроде тоже так можно:

https://play.golang.org/p/iVUiuO3FgtW

package main

import (
	"encoding/json"
	"fmt"
)

func main() {
	a := map[string]interface{}{"value": 5, "left": map[string]interface{}{"value": 6}}
	b, _ := json.Marshal(a)
	fmt.Println(string(b))
}
Печатает
{"left":{"value":6},"value":5}
Но не нужно. Json без контроля - это путь, усеянный граблями. Когда у тебя запись типизирована, можно контролировать опечатки. ПММЛ это оправдывается в долговременном разрезе. Во-первых, тебя обматерят при попытке зачитать неверный json, во-вторых, глядя на исходник, сразу точно понятно, что в конфиге должно быть.

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

что у нас все что начинается с нижнего регистра приватное и не сериализуется

Да, это плохое решение. Но в этом плане все Си-образные языки одинаково плохи. Как только надо представить в программе любую сущность из css, где принято писать через чёрточку, сразу становится бобо. Но ведь о лиспе или тикле сегодня вообще речь не идёт. Т.е. голанг - это всего лишь чуть более невкусный сорт говна из всего доступного меню.

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

Где нормальная обработка исключений?

Паника - это и есть исключения. Но это эзотерическое знание, которое от простых адептов секты тщательно и успешно скрывается.

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

Go - мертворожденный высер как Dart.

Глядя на Dart, можно сразу понять, что это отстой. Голанг достаточно хорош.

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

Что в Go есть нового?

По сути, нового нет ничего. Хороша комбинация - AOT машинный код, статическая и динамическая типизация, сборка мусора. Просто в своё время жадные люди создали и распиарили жабу, а зачем создали С++ - я вообще не знаю. Хорошее вообще обычно стоит дорого и не всем доступно. Сегодня и автомобили плохие, и еда искусственная. В этом мире надо радоваться и голангу.

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

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

defer + panic + recover = finally + throw + except

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

А в go нужно в глобальной области видимости что-то искать.

Это не совсем недостаток и это не совсем так. Там часть вещей в глобальной области видимости, а часть - в области видимости типов.

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

От исключений больше вреда, чем пользы (и намного).

Нет. Исключения это единственно правильное поведение. То, что его используют не всегда верно это не то, на что надо смотреть.

dem ★★
()

С ним все хорошо в продакшене.
См. K8s и все вокруг него.

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

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

на Python схожее по функционалу приложение пишется в 3-5 раз быстрее

пруф? я много раз слышал «на языке X приложение пишется в N раз быстрее, чем на языке Y», но пруфов так никто и не дал

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

Только от опыта зависит. Я знавал чуваков, которые выдавали немыслимое количество кода на плюсах, который я даже прочитать толком не мог. Т.е. они писали быстрее, чем я читал. Ну я мог бы наверно их уделать на перле, но пришлось бы писать 5 строк тестов на каждую строку кода, чтобы не так страшно было это запускать. Скриптовые языки по сути требуют TDD (иначе будет ад и израиль), что сильно замедляет работу на начальном этапе.

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

Хорошо что можешь паниковать, а обработать эту панику сможешь? А понять откуда она пришла? Строчки будешь сравнивать?

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

В go нет никакой реализации Data Mapper для отображения реляционных структур БД в объектную модель.

Да это же просто счастье какое-то.

// FIXED

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

Обработать смогу. Узнать откуда пришла - видимо тоже смогу, раз gin стек печатает при панике. Строчки сравнивать не обязательно. Как паникуемое значение, так и error - это interface{}, отличие только в одном методе. Принимай любое соглашение в рамках своего проекта и получай структурированную инфу. Используй switch, когда известна только часть инфы.

Я вот делаю уже третий учебный проект и, соответственно, пробую третий подход к тому, как структурировать инфу в ошибках. У меня есть два тестовых задания и один свой проект. В своём проекте я внутри себя почти всё делаю через панику, если код вызывается из обработчика http запроса. В первом тестовом задании я делал через errors.Wrapf, но это мало что даёт - ты получаешь просто список строк по сути. А теперь придумал свой тип errorWithCode{Code: <enum>, Message: string} для своих сообщений. Но пока всё это ещё не особо совершенно, и паника всё равно удобнее.

При обработке паникой я завёл свой тип. В gin я подменяю обработчик паники (или свой внутри пишу, не помню уже) и, если паника мне известна (имеет мой тип), то обрабатываю её. Если неизвестна - то log.Fatal, а дальше уже дело systemd перезапустить сервис. В продакшене это не использовал и не знаю, хорошо ли это работало бы, но перехватывать любую панику и делать вид, что приложение не сломалось - это просто глупость и авантюризм - от такого потом самолёты падают и АЭС взрываются. Т.е. то, что делает gin по умолчанию - это просто отстой.

Далее, если заменяем err на panic, то разница между error и interface{} совершенно минимальна, потому что printf %#v превращает в строку что угодно. В целом решение сделать error настолько простым представляется мне одним из самых неудачных решений в языке, которое превращает программы в помойку. Нужно было сделать хотя бы error и числовой код, как это сделано в SQL. Или, ещё лучше, error, строка - глобальное имя модуля вместе со всеми этими github.com, и число, назначаемое разработчиком модуля.

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

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

Я, кстати, понял, зачем они так сделали. Они это сделали, чтобы оставить себе свободу потом переделать механизм исключений. Всё-таки гениально. Когда что-то названо паникой, людям уже трудно начать о нём думать. Потом сверху они добавляют рекомендаций этим не пользоваться, тут на них работает, конечно, доминирование в информационном пространстве. В итоге они получают степень свободы. Если в каком-нибудь го 2.5 они захотят сделать по-другому, они скажут мне и другим «умным»: мы же говорили - не используй панику. Ты нас не послушал. Сам виноват.

Для меня, как человека, который разрабатывал свой язык программирования, трюк, который они провернули с паникой, выглядит как магия 80-го уровня. Да это она и есть. Больше я не буду злиться на эту тему, наверное, а буду смеяться. Разве только мне надоест писать через строчку if err != nil.

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

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

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

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

т.е. такая параша

Эта «параша» называется статической типизацией. Покалеченым JS-ом, конечно, сложно понять, что это и зачем, но ты постарайся.

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