Comments 72
Почему бы не написать о недостатках? Заколебали уже, если честно, писать о Go как о серебряной пуле.
Самый большой недостаток Go — это ad-hoc полиморфизм.
Нафиг, только динамическая типизация или нормальные системы типов (как в F#, например).
К тому же (имхо) нет ниши, в которой Go был бы уникален. Контейнеры? А теперь почитайте что нагородили разработчики Kubernetes — фактически свою систему типов (с generics, да) поверх Go:
In short, Kubernetes has built a type naming & identification scheme and a type registry to store each GVK. It took me a long time to identify (pun intended!) this whole thing in the codebase; after I did, I was amazed and impressed.
The core team replaced a compile-time language feature that was missing (Generics) with their home-built runtime system. And given the tools at their disposal, they did a pretty good job.
К тому же (имхо) нет ниши, в которой Go был бы уникален.
Не то, чтобы уникален, но GC, CSP и компиляция в бинарник доступна очень для немногих, а именно в таком виде (все сразу и на уровне языка, а не библиотек), так и вообще в единственном экземпляре.
Думаю Go оседлал два тренда: минимизация окружения в рантайм и параллельность с минимальными паузами GC.
Я бы еще записал сюда очень простую кросс-компиляцию. Для одного из своих проектов я выбрал именно Golang, потому что нужно было написать утилитку для одного очень специфичного устройства на андроидолинуксе, где не то что Python или Perl, даже Bash не было.
GOARCH=arm GOOS=linux go build
Копируем бинарник через telnet и все работает.
А что сказать то хотели?
Я на работе использую в связке с vue.js и jQuery. Go умеет быть файловым сервером, пишется это в одну строчку. Далее пишется фронт на любом любимом фреймворке, и общение между фронтом и шоу по rest API. Приложения десктопные И такая связка реализуется в продукте быстрее чем на qt, при том что я ни вёрстку, ни веб разработку не умел и всё это с нуля учил в отличие от qt или c# с его winforms или ещё какой фиговиной
Для того, чтобы изучать любой язык есть две причины:
- деньги и спрос на рынке труда
- желание изучить этот язык
Остальное — вода
При этом "желание изучить этот язык" проистекает из денег и спроса на рынке труда
Правда, есть ещё категория энтузиастов, которые чисто из вредности решают задачи на не очень подходящим для них языке (те самые которые пишут веб-сервера на bash или редакторы текста на postscript) — они вряд-ли интересуются деньгами или спросом на рынке труда.
да просто посмотрите блог «ненормальное программирование»
Рискуя нарваться на минусы, все же попытаюсь разобраться и понять, о чем речь в статье. Со стороны звучит так, будто бы статья должна заинтересовать меня (некоего абстрактного разработчика) и разрекламировать мне Golang. Представим на минуту, что я ни разу не видел даже строчки кода на Go (это близко к правде). Какие у языка преимущества (судя по статье):
1) Простота. Собственно, это была основная цель создания языка, и ее удалось достичь. У Go достаточно простой синтаксис
Верю на слово, но т.к. рядом нет ни строчки кода, мне сравнить не с чем.
2) Большое количество библиотек. Если вам не хватает какой-либо возможности в Go, можно воспользоваться одной из множества библиотек и выполнить требуемую задачу. У Go есть еще одно преимущество — можно без проблем взаимодействовать с библиотеками языка Си. Есть даже мнение, что Go-библиотеки — это обертки для C-библиотек.
Сейчас только ленивый с C-библиотеками не взаимодействует. Ладно, запишем в плюс.
3) Чистота кода. Компилятор Go позволяет держать код «чистым».
Игнорируя тот факт, что упомянутая в этом абзаце ссылка — битая, я все-таки не очень понимаю, почему фичей языка являеся форматирование сторонней утилитой? Тогда любая тяжеловесная IDE в нагрузку к энтерпрайз-языку — это тоже "фича" языка? Из текста не ясно, насколько я не прав.
4) Статическая типизация.
Верю, что преимущество, но по сравнению с чем?
5) GoDoc.
Сторонняя утилита. Чем она проще чем аналоги для других стеков? Может пример есть?
6) Обслуживание кода. Его легко обслуживать именно благодаря простому и лаконичному синтаксису.
Я полностью согласен, осталось только увидеть этот "лаконичный" синтаксис в сравнении хоть с чем-то.
7) При этом в Golang нет классов (есть структуры, struct), нет поддержки наследования, что значительно упрощает изменение кода. Плюс нет исключений, аннотаций и т.п.
Окей, а чем это заменяется? Что вместо исключений, например?
8) Что можно написать на Go
Практически все, за исключением некоторых моментов (например, разработки, связанные с машинным обучением — здесь больше подходит все же Python с низкоуровневыми оптимизациями на C/C++ и CUDA).
Но у вас же обертки и C-библиотеки. С ними действительно можно написать что угодно.
9) Все остальное можно писать, особенно это актуально в отношении web-сервисов. Кроме того, на Go стоит разрабатывать приложения как для конечного пользователя, так и для разработки демонов, UI, он подходит для кроссплатформенных приложений и сервисов.
Ну вот хороший же пример — UI на Go. Я, например, не встречал (потому что мало интересовался). Пример приложения или упрощения рутинных задач по сравнения с более сложными языками был бы очень кстати. Но, как говорится, увы.
Я открыл статью, потому что захотел узнать, "Зачем мне учить Go", но так и не увидел никакого конкретного примера, почему я должен выкинуть свой древний и бесполезный язык и пересесть на Go, кроме зарплаты. Зарплаты, динамика которой (согласно данным по ссылке на Мой круг) находится на уровне с C# и Python, и катастрофически проигрывает Swift и Objective-C. И да, я не нашел в статье ничего по ключевому слову "инфляция", что, с учетом указанной валюты, мягко говоря превращает эту динамику в 0.
Ощущение, что написана статья только ради этого.
Вообще как для Mail статья слабовата, для меня была бы ОК, но не для Mail.
(ну это мой субъективный вывод от статьи)
Будет, он как одни ЯП от Гугла забыт и заброшен.
Или, например как Ангуляр, переделаны так, что версия 2 будет слабо совместима с версией 1? (Предпосылки к этому есть)
(Предпосылки к этому есть)
Что за предпосылки?
Добавлены генерики и обработка исключений.
Возможно что-то еще измениться.
В общем будет ка было с Ангуляр.
Как минимум во второй версии будет изменена система модулей.
Шо опять?! Я только приспособился к go mod («vgo»)… Можно пруф?
Добавлены генерики
Это не совсем и дженерики будут, но это лишь расширение языка, не нарушающее обратную совместимость.
и обработка исключений.
Серьезно? Можно пруф? Введение исключений в язык — это ведь фундаментальное изменение, которое не факт, что комьюнити примет.
Как минимум во второй версии будет изменена система модулей
Ну, собственно go modules есть и работает уже сейчас. Ничего из breaking changes не замечено.
Добавлены генерики
Первый вопрос: вы же внимательно читали, что по поводу дженериков авторы языка говорили. А то есть мнение, что дженерики могут оказаться достаточно специфичными.
Второй вопрос: а что из существующей экосистемы должны сломать дженерики? В чем поломается обратная совместимость?
обработка исключений
Вы это где прочитали? То, что должен появиться некоторый «сахар» для обработки ошибок — да, и не только должен появиться, но уже есть. Опять же ничего не сломалось. А по поводу исключений (специально перепроверил) позиция прежняя: ошибка — это значение, т.е. исключений нет и не предвидится.
Вы, в общем, хотя бы из оригинала golang-blob информацию брать попробуйте, что ли, а не из желтой прессы. Там вам прямо и расскажут: «так, мол, и так, развитие языка идет итеративно, в планах сахар для обработки ошибок, некоторые фичи обобщенного программирования, типа-дженерики, возможно на встроенной кодогенерации, а может что-то другое придумаем, пробуем разные подходы. Модули — можете уже пользоваться, это некоторая итерация чуточку более продвинутого вендоринга. Вторая версия — ну, вероятно, чтобы зафиксировать завершение этапа запланированных расширений синтаксиса, версию после 1.6 переименуем в 2.0. Но это так — поржать, по сути слома совместимости не планируется. Язык будем держать как можно более простым, ничего из того, что в планах, поломать что-то не должно».
Ну, в общем, Go не Swift, ломать что-то не собираются. Собственно, гуглу это не выгодно. У него на Go достаточно большая кодовая база, переписывать никто не хочет.
В таком случае вам больше ничего не мешает начать его изучать:
https://blog.golang.org/go-brand
Внесу немножко позитива :)
Лично мне Golang понравился своим вниманием к мелочам. Каждый преподносимый здесь плюс не тянет на киллер фитчу, будь то:
- Встроенные утилиты godoc, gofmt, go test, go generate, etc
- Установка пакетов из любых git репозиториев
- Распараллеливание одним ключевым словом
- Статическая кросс-компиляция из коробки
- WebAssembly опять же из коробки
- Очень простые и удобные стандартные пакеты, такие как rpc или flag
- И многое других мелочей, что сразу не приходит в голову.
По отдельности здесь нет ничего особенного. Например в других языках есть JavaDoc, PyDoc, LuaDoc и куча разных утилит к ним; Линтеров и форматоров вагон к любому языку — выбирай на вкус. Для кросс-компиляции достаточно банч пакетов через apt/yum/portage поставить, итп.
Но удобоство Golang в том, что: a) все это сразу доступно из коробки, скачал — и можно сразу работать; б) они очень удобные и продуманные; в) благодаря предыдущим пунктам, большинство пакетов используют единый подход, что сокращает зоопарк библиотек и подходов и очень сильно упрощает анализ чужого кода.
Так что в итоге: быстрый вход, быстрая разработка, быстрое развертывание. На мой взгляд, весьма хороший инструмент для всяких ботов, консольных утилит, API и не очень крупных сервисов.
Но если вы уже умеете все это делать на других языках и вам это не доставляет никаких неудобств, то, вероятно, Golang вам не нужен.
При этом в Golang нет классов (есть структуры, struct), нет поддержки наследования, что значительно упрощает изменение кода. Плюс нет исключений, аннотаций и т.п.
А это что, если не наследование?
package main
import "fmt"
type A struct {
x int
}
func (a *A) SetX(x int) {
a.x = x
}
type B struct {
y int
A
}
func (b *B) SetY(y int) {
b.y = y
}
func (b *B) GetResult() int {
return b.x * b.y
}
func main() {
f := B{}
f.SetX(2)
f.SetY(4)
fmt.Printf("2*4=%d\n", f.GetResult())
}fmt.Printf("%v\n", f.A.x)
По сути это встраивание полей и методов, связанных со структурой A, в структуру B.
Можете привести пример наследования на C++, который не реализуется в GO?
Суммируя, все-таки не стоит, работая с go, мыслить категориями и парадигмами иных языков. Ведя разработку на go, нужно руководствоваться философией go и только ей.
Как минимум, вы не сможете находясь в области видимости A вызвать функции B:
type A struct { x int }
func (a *A) GetX() int {
return a.x
}
func (a *A) Get() int {
return a.GetX()
}
type B struct {
y int
A
}
func (b *B) GetX() int {
return b.x + 1
}
func (b *B) Get() int {
return a.Get() + b.y
}
Если вызвать b.Get(), то, очевидно, вызовется a.GetX(), а не b.GetX().
В случае с C++ достаточно сделать так:
class A {
virtual int GetX();
}
При наследовании свойства родительского типа переходят к дочернему.
При композиции, которая в Go, происходит перекрытие свойств, который вы встраиваете в объект более высокого уровня.
Можете привести пример наследования на C++, который не реализуется в GO?
Ну, как бы, любое наследование в C++ будет ярчайшим примером того, что не реализуемо в Go… Нету в Go наследования, только композиция.
С плюсах есть virtual-семантика, например, которая в Go нереализуема в принципе.
Собственно, есть еще «фишка» с конструкторами, которые в C++ вполне наследуются, а в Go отсутствуют, что тоже «накладывает отпечаток». Т.е. «встроенное» поле структуры в Go всегда будет неинициализированным, констрактить вы его будете ручками.
Наследник в C++ скрывает детали реализации родителя, в Go — нет. Вы всегда можете «достучаться» до встроенного типа из «потомка».
Модификаторы доступа и области видимости достаточно чувствительно разнятся. В Go модификаторы доступа — уровня пакета, в плюсах — на уровне класса.
В общем, миллион вещей есть в C++, которые нельзя делать в Go. Это не хорошо и не плохо, это просто иногда нужно, а иногда не очень. Просто смешивать понятия не стоит, разные языки с очень различными парадигмами.
Композиция — это не наследование. Один из способов применения ООП, но не наследование.
А это что, если не наследование?
Встраивание, емнип.
(столкнулся в процессе обучения по туториалам)
Если «анмаршаллить из XML, маршаллить в XML» — есть, и даже в стандартной библиотеке есть.
Если вам SOAP нужен, xsd-схемы и все вот это — тогда да, ничего приличного нет, по большей части из соображений невысокой востребованности, имхо.
Учитывая, что оно висит уже больше года, видимо, сильно не в приоритете. Так что я не стал бы серьезно рассчитывать, что в мейнстрим-библиотеках появится что-то прорывное в этой области в обозримое время. XML — вотчина серьезных бизнес-приложений, там как царила Java, так и царит до сих пор.
У go есть перегрузка функций?
На go можно программировать микроконтроллеры?
Зачем вам учить Go