Комментарии 22
А как дела с фреймворками? Есть ли полноценные каркасы приложений уровня Spring, Django?
Здесь так не принято.
Не надо, пожалуста
На Go не очень правильно писать приложения требующие тяжёлые каркасы. Скажем так, если вам надо написать не микросервис/тулу на Go, то вы должны это очень грамотно архитектурно обосновать прежде чем начинать писать.
Даже бекенд сайта в котором будет чуть больше чем просто API уже начинает вызывать боль, если вы писали подобное до этого на "динамических языках".
с некоторым вдохновением от Pascal, Modula и Oberon для деклараций и пакетов.
Вся идея структур с привязкой методов с помощью приемников/ресиверов (receiver) в их объявлениях кажется цельнотянутой с Оберона(2). Ну один в один.
Не только оператор присваивания ":="
Если уже созданный язык доводить до ума и исправлять ляпы, то это будет уже новый язык (с новыми ляпами). Да и сообщество как правило очень болезненно воспринимает любые изменения, т.к. к старым косякам и ляпам привыкают и их начинают считать за преимущества.
К Go это тоже относится. Язык вроде новый, но упорно косит под древность какую то. Хотя имеет задел стать современным и удобным, но динозавры, которые его создавали нелепые костыли из старых языков перенесли в него, просто потому что они за годы своей жизни так привыкли к тем костылям, что без них уже не могут. Дженерики недавно добавили, но тоже как то криво и убого. Ну как то не тянет то, что называется дженериками в Go на полноценные современные дженерики. Интерфейсы в Go тоже какие то карикатурные.
Но то, что создатели Go послали лесом ООП, за это им огромный плюс в карму.
Что именно в Go вы считаете "нелепыми костылями из старых языков"?
Про ООП согласен. Про дженерики тоже.
Ну например брать аргумент функции в скобочки это просто дань неудобной традиции. Практического смысла в этом нет. Но это так, мелочь. А что серьезная проблема, это то, что функции имеют побочные эффекты. Так не принято делать в математике, но так было принято в старых ЯП и это перетащили и в Go. Иногда это удобно, но сильно мешает рефакторингу. Если бы можно было объявлять часть функций чистыми и часть с побочками, это вывело бы язык совсем на новый уровень.
Рассказать про golang и не рассказать про limbo? хмхм..
Ясно, понятно - опять все взято из «си», ок.
А мб стоило посмотреть доклад от одного из создателей Go, чтобы понять что почти все было взято из Modula/Pascal/Oberon, ну, а из «си» элементы синтаксиса, чтобы меньше «воняли».
Я думаю(и знаю что всем по барабану), что сравнивать интерфейсы с java не очень корректно тк по большей части все с С взяли, вроде структур и как раз интерфейсы
Я дилетант в Go. Меня удивляет и огорчает, что в Go нет алгебраического типа данных. Язык создан профессионалами, он сравнительно новый. Можно было ожидать, что всё продумано, всё сделано как надо.
Понятно, что язык пытались сделать максимально простым. Это сомнительный путь. Java тоже хотели сделать максимальной простой, но позже язык стал развиваться и усложняться.
Алгебраический тип данных (тип сумма) – это очень важная возможность, она изначально должна быть в языке.
От C до Go. Как Golang объединил лучшие черты своих предшественников