Pull to refresh

Comments 26

Несмотря на некоторый хейт Golang на Хабре, наш внештатный автор решил рискнуть продолжить серию статей

Может все-таки хейт не Golang, а вашего автора/компании/качества статей? Лично я хейта на Golang не заметил.
Возможно наш читатель действительно ждет чего-то более хардкорного от нашего блога. Мы не исключаем этого и в принципе готовим на будущее более «инженерный» материал. ЧТо касается хейта, вот, например, очень яркий пример habr.com/ru/company/netologyru/blog/471782
Функции первого класса (high order function)

Какая-то каша из англоязычных терминов first class citizen и high(er) order functions. Это не одно и то же.

ООП в языке реализуется, пускай и достаточно непривычным способом, через систему структов и интерфейсов

Было бы интересно, если бы автор (преподаватель языка?) пояснил вот это предложение некоторыми примерами или просто текстом. Что имелось в виду? (Без подвоха — действительно интересно)
Какая-то каша из англоязычных терминов first class citizen и high(er) order functions. Это не одно и то же.

Ну, это, конечно же, не одно и то же — но вот одно без другого в нормальных языках существовать не может. Если функция — first class citizen, то её автоматически можно принять как параметр или вернуть как результат, т.е. сделать high order function. В обратную сторону это "автоматически" не работает (можно представить язык с HOF, но с особыми функциями), но напрашивается.

лучше за меня ответит вот эта статья, только она конечно давненько вышло, но ничего особенно с того момента не поменялось. habr.com/ru/post/225907
UFO just landed and posted this here
Писать в функциональном стиле на Go — либо развлечение для ума, либо глупость. Всем желающим можно ознакомиться с видео Франсеска Кампоя на эту (и другие похожие) тему.
Дальше у вас стандартные вопросы-претензии к языку: «а можно ли в Go так и эдак».
Отвечаю как разработчик Go: так нельзя и эдак не выйдет. Такой язык, не всем нравится.
UFO just landed and posted this here
Кстати, интересно, стандартность претензий их скорее легитимизирует или же обесценивает, но то такое.

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

А в вашем комментарии нет ответа на вопрос — есть только ещё вопросы к языку. Таких можно придумать к какому угодно языку.
В Go мало языковых возможностей — «Неудобно, приходится переизобретать велосипеды!»
В JavaScript реализованы все парадигмы и куча возможностей — «Помойка, как их вообще запомнить!?»
Ну и так далее.
Я пишу на Go — в моём случае задачи решаются на этом языке легко и эффективно. Обобщённого программирования иногда не хватает, а так — всё нормально.
UFO just landed and posted this here
А вот Go или JS — не оправдывает.

У Go два оправдания: простая многопоточность из коробки на CSP и компилируемость в бинарник. Да, это можно сделать например на C++, но желающих не так много.

UFO just landed and posted this here
В единый бинарник?

Можно и в статический и в динамически линкуемый. Тут все как в C/C++.


Для микросервисов размеры важны. Статически скомпилированный бинарник занимает очень мало места. Как следствие время старта того же контейнера на непрогретой ноде очень малое. Аналогичный по функционалу контейнер на Python или Java будет занимать на порядки больше места. Да, понятно, что после первого запуска слои окажутся на ноде и все будет хорошо, но сам первый запуск может быть сложен по io. Особенно это заметно на ad-hoc запусках в разных PaaS средах, типа Heroku, Yarn и подобных.

UFO just landed and posted this here
UFO just landed and posted this here
и говорить, что у Go строгая типизация, как-то странно

Уточнение: и говорить, что у Go статическая типизация, как-то странно. Строгой (сильной) типизации никакой interface {} не мешает.

> придумать [для Go] такой map, который бы работал со списками с произвольными типами

Это в теории можно реализовать, через unsafePointer. Но ни о каких гарантиях типобезопасности речи и не будет, естественно. Как и о гарантииях отсуствия сегфолтов =)
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Можно подключить внешний кодогенератор. Чем макросы в плюсах и являются, в принципе.

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

Вот про json думал. Но там же структура известна. Зачем там interface{}?

В Go вся работа с JSON идёт с помощью интерфейсов.

	rv := reflect.ValueOf(v)
	if rv.Kind() != reflect.Ptr || rv.IsNil() {
		return &InvalidUnmarshalError{reflect.TypeOf(v)}
	}


Это — кусок функции десериализации (Unmarshal) пакета json. Вызывается пакет reflect — а там всё на пустых интерфейсах.
Почти каждая статья подобного рода скатывается в срачи на тему «почему в го нет дженериков»

Добрый день, опечатка: >_Но вы можете обратиться к другим решениЯ_

Sign up to leave a comment.