Comments 26
Несмотря на некоторый хейт Golang на Хабре, наш внештатный автор решил рискнуть продолжить серию статей
Может все-таки хейт не Golang, а вашего автора/компании/качества статей? Лично я хейта на Golang не заметил.
Функции первого класса (high order function)
Какая-то каша из англоязычных терминов first class citizen и high(er) order functions. Это не одно и то же.
ООП в языке реализуется, пускай и достаточно непривычным способом, через систему структов и интерфейсов
Было бы интересно, если бы автор (преподаватель языка?) пояснил вот это предложение некоторыми примерами или просто текстом. Что имелось в виду? (Без подвоха — действительно интересно)
Какая-то каша из англоязычных терминов first class citizen и high(er) order functions. Это не одно и то же.
Ну, это, конечно же, не одно и то же — но вот одно без другого в нормальных языках существовать не может. Если функция — first class citizen, то её автоматически можно принять как параметр или вернуть как результат, т.е. сделать high order function. В обратную сторону это "автоматически" не работает (можно представить язык с HOF, но с особыми функциями), но напрашивается.
Дальше у вас стандартные вопросы-претензии к языку: «а можно ли в Go так и эдак».
Отвечаю как разработчик Go: так нельзя и эдак не выйдет. Такой язык, не всем нравится.
Кстати, интересно, стандартность претензий их скорее легитимизирует или же обесценивает, но то такое.
Претензии сообщества принимаются к сведению и обобщённое программирование обещают сделать. Однако, в смысле направления развития языка, Go — очень волюнтаристский проект. Всё на усмотрение авторов, их мнение перевешивает всё сообщество вместе взятое.
дальнейшее — ответ на вопрос о том, почему Go нравится не всем, и что дело не в отсутствии классов.
А в вашем комментарии нет ответа на вопрос — есть только ещё вопросы к языку. Таких можно придумать к какому угодно языку.
В Go мало языковых возможностей — «Неудобно, приходится переизобретать велосипеды!»
В JavaScript реализованы все парадигмы и куча возможностей — «Помойка, как их вообще запомнить!?»
Ну и так далее.
Я пишу на Go — в моём случае задачи решаются на этом языке легко и эффективно. Обобщённого программирования иногда не хватает, а так — всё нормально.
А вот Go или JS — не оправдывает.
У Go два оправдания: простая многопоточность из коробки на CSP и компилируемость в бинарник. Да, это можно сделать например на C++, но желающих не так много.
В единый бинарник?
Можно и в статический и в динамически линкуемый. Тут все как в C/C++.
Для микросервисов размеры важны. Статически скомпилированный бинарник занимает очень мало места. Как следствие время старта того же контейнера на непрогретой ноде очень малое. Аналогичный по функционалу контейнер на Python или Java будет занимать на порядки больше места. Да, понятно, что после первого запуска слои окажутся на ноде и все будет хорошо, но сам первый запуск может быть сложен по io. Особенно это заметно на ad-hoc запусках в разных PaaS средах, типа Heroku, Yarn и подобных.
Это в теории можно реализовать, через unsafePointer. Но ни о каких гарантиях типобезопасности речи и не будет, естественно. Как и о гарантииях отсуствия сегфолтов =)
Вот про json думал. Но там же структура известна. Зачем там interface{}?
В Go вся работа с JSON идёт с помощью интерфейсов.
rv := reflect.ValueOf(v)
if rv.Kind() != reflect.Ptr || rv.IsNil() {
return &InvalidUnmarshalError{reflect.TypeOf(v)}
}Это — кусок функции десериализации (Unmarshal) пакета json. Вызывается пакет reflect — а там всё на пустых интерфейсах.
Добрый день, опечатка: >_Но вы можете обратиться к другим решениЯ_
Функциональная парадигма на Go: основные техники