LINUX.ORG.RU

Чем плох Go?

 , ,


4

14

Отчего многие его так не любят, что с ним не так? Ну кроме того, что:

  1. Нет дженериков, укуренные решения вроде sync.Map interface{} в stdlib как следствие;
  2. Базилион способов объявить переменную;
  3. Магические функции new() и make(), которые работают только с некоторыми типами;
  4. Выбивающиеся из общего стиля ЯП iota вместо enum, <- и ->;
  5. Сильно ограниченные константы, пригодные только для базовых типов данных;
  6. Кастрированные кортежи;
  7. Бесполезность поддержки unicode в коде ввиду того, что экспортированы могут быть только элементы, начинающиеся на символ из ограниченного подмножества;
  8. Unicode code point'ы можно складывать как числа;
  9. Впиндюренные в сам ЯП, а не в библиотеку «горутины»;
  10. Невозможность форка проекта с сабпакетами (он не скомпилируется с помощью go get/go install, официальная рекоммендация - использовать sed);
  11. Сообщество, которое в каждом объективном дефекте видит глубокий смысл и большой плюс;
  12. Go 2, который не пофиксит ничего из этого, кроме дженериков.

Вроде, не критично всё это, жить можно же?



Последнее исправление: cetjs2 (всего исправлений: 1)

что с ним не так? Ну кроме

Толстишь.

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

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

И как часто тебе нужны обобщенные структуры данных?

Я смотрю ты достиг чрезвычайно высокой скорости написания функции max в секунду для всех комбинаций типов. А потом min не забудь

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

Я смотрю ты достиг больших успехов в чтении. Если постараешься еще немного, сможешь прочитать, что это как раз подходящий случай для go generate (дженерики для бедных, да).

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

А среди проблем ты забыл указать обработку ошибок - надо было постараться придумать что-то хуже, чем исключения, но у Пайка получилось.

Точно. Собирался и за лесом пунктов пропустил. Исправим ситуацию.

Вместо того, чтобы возвращать или результат, или ошибку, пользователи вынуждены одновременно создавать и возвращать невалидное значение и ошибку или валидное значение и пустую ошибку в виде недокортежа:

func todo() (string, error) {
	...
	if ... {
		return "", fmt.Errorf("some error")
	}
	return value, nil
}
Как будто этого было недостаточно, fmt.Errorf(...) и errors.New(...) - в разных пакетах.

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

SwiftRocks
() автор топика
Ответ на: комментарий от vertexua

А какие дженерики ты имеешь ввиду? Серебряной пули нет: плюсовые шаблоны увеличивают время компиляции, джавовские дженерики - время исполнения. Бесплатного решения не существует.

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

увеличивают время компиляции

Таки меньшее зло. В плюсах из-за легаси там же реально ворох проблем, но по похожему базовому принципу можно сделать нормально.

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

Нафига max/min делать как функция, если это — элементарный макрос:

#define max(a,b)  (a < b ? b : a)
#define min(a,b)  (a < b ? a : b)

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

Серебряной пули нет: плюсовые шаблоны увеличивают время компиляции, джавовские дженерики - время исполнения. Бесплатного решения не существует.

А как же D? Тамошние шаблоны разве увеличивают время компиляции или время исполнения?

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

ЯП развивается же, новые версии стабильно выходят. Откуда я знаю, может с 1.7, который я смотрел последний раз, уже все проблемы пофиксили. В других ЯП (Swift, наверное, Rust, даже JS) гляди сколько за это время чего поменялось. Закидываю гоферам удочку, ан нет: «I've never used generics and I've never missed them», «brutally practical», «generics are overrated», «webscale features».

SwiftRocks
() автор топика
Ответ на: комментарий от vertexua

Быстрая компиляция один из базовых принципов и одно из преимуществ над крестами. Сгенерировать код, добавить его в систему контроля версий и использовать как отдельный модуль не будет стоить времени при каждой сборке и не будет стоить времени в рантайме при условии генерации типизированного кода. При условии наличия хорошего тулинга такой подход меня лично вполне устраивает.

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

Плюсовые шаблоны увеличивают время компиляции только из-за того, что находятся в хидерах и парсятся каждый раз заново. В том же Haskell, Rust и .NET >=2.0 дженерики компилируются в промежуточное бинарное представление из которого потом мономорфизируются, не влияя на время компиляции.

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

Обычно при разработке проблемы при свежей рекопиляции. В языках где нету портянки с 10 мегабайт, которая получается из-за хедеров - это быстро. Вон запусти какой-то фреймворк на расте пожирнее, rocket например, собери один раз. А потом поменяй main и собери второй раз. Там реально все быстро - очень быстрая компиляция, а потом линковка. А линковка уже должна быть на уровне go

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

Речь шла про шаблоны. Которые в D прекрасно показывают, что не обязательно выбирать экстремумы между C++ными шаблонами и Java-дженериками.

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

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

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

Как бы можно соорудить precompiled header, есть поддержка, но все это в таком жутком ручном режиме, что ну его нафиг. Я когда-то пробовал умную систему написать, которая будет вычислять когда их нужно создавать. Не очень получилось в итоге

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

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

На самом деле, время на парсинг невелико. А основное время как раз занимает мономорфизация.

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

Ну в каком-то смысле да, но в С++ мономорфизация как раз включает парсинг, тайп чекин, оптимизации, и т.д.. В языках с bounded polymorphism значительная часть из этого делается один раз, например не надо каждый раз тайп чекать мономорфизацию т.к. типы гарантированно подходят под ограничения.

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

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

Это исключает проверку типов, но основные затраты - это собственно генерация оптимизированного кода.

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

Насколько я знаю, только в официальном компиляторе, у которого не очень с оптимизацией. Gdc/ldc медленнее.

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

Время компиляции одна из самых больших проблем раста. И виноваты в этом в том числе и дженерики.

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

Мне кажется, это больше для троллинга фанбоев подходит.

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

4 со скобками, 4 по сайд-эффектам при подстановке (а++, например), 2 по внезапной перегрузке операторов

это без необычных контекстов использования, а то считать устану

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

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

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

Язык не спасет от упавшей бутылки, одумайся, безопасность превыше всего!

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

В итоге, на Си можно делать бинарники на десятки килобайт,

А смысл экономить на спичках, если речь не о суровом встроенном програмном обеспечении, конечно?

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

Чтобы не превращать софт в монстров вроде тормозиллы или хромоногой быдлоподелки, которые свистят, пердят и тупят даже на 32ГБ оперативы!!! А на моем домашнем компе с 4ГБ оперативы вообще невозможно одновременно запустить хромоногого и огнелиса с 1-2 открытых вкладках в каждом.

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

Серебряной пули нет: плюсовые шаблоны увеличивают время компиляции, джавовские дженерики - время исполнения.

Однако каким-то образом Swift и Sixten решают сразу обе проблемы:
https://www.youtube.com/watch?v=ctS8FzqcRug
https://github.com/ollef/sixten

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

А какая связь между статической/динамической сборкой и потреблением памяти? Сударь, вам бы в вопросе разобраться сначала.

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

Философ штоле? А может спросим у дровосеков?

А может у столяров? Или плотников? Викинги тоже за топор кое-что сказать могут.

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

Какие спички? У Вас что, всего 3 бинарника в системе? Современные системы состоят из тысяч пакетов, в каждом из которых десятки бинарников. А теперь представьте себе, что всё это написано на Go, а потому каждый такой бинарник весит этак по 2 мегабайта. Вот и получится, что бинарники в системе будут занимать этак под 40 гигов дискового пространства. При том, что они могли бы занимать 2 гига, если бы были написаны на Си. А если добавить сюда ещё и то, что в библиотеках тоже исправляют баги, но при динамической линковке пересобирать использующие библиотеку бинарники может быть необязательно... А тут надо будет вычислять какие бинарники используют исправленную библиотеку, и каждый пересобирать в отдельности с уже новым вариантом библиотеки...

Ну и как после такого можно одобрить использование Go?

saahriktu ★★★★★
()

Go - великолепен. Единственный его минус вот этом:


i,j := 1,1 // OK

i,j = 2,3 // OK

i,j += 1,2 // А вот так нельзя

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

Вот и получится, что бинарники в системе будут занимать этак под 40 гигов дискового пространства.

Боже мой, да и насрать же! Попробуй сэкономить на водке и купи себе HDD на терабайт. Они сейчас не так много стоят.

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

Вот и получится, что бинарники в системе будут занимать этак под 40 гигов дискового пространства.

Боже мой, да и насрать же!

Это кому как.

купи себе HDD на терабайт

Ты такой богатый, пока не надо покупать несколько тысяч HDD. А понадобится - резко сдуешься.

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

Вот и получится, что бинарники в системе будут занимать этак под 40 гигов дискового пространства.

40000, чего уж там...

А тут надо будет вычислять какие бинарники используют исправленную библиотеку, и каждый пересобирать в отдельности с уже новым вариантом библиотеки...

Один фиг пакеты постоянно обновляются, если раз-два в год обновятся из-за исправленной библиотеки - никто не заметит.

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

пока не надо покупать несколько тысяч HDD.

Ты хочешь сказать, в случае с C их покупать не понадобится? Я с трудом представляю себе реальную ситуацию за пределами embedded, где размер бинарника имел бы хоть какое-то значение.

hateyoufeel ★★★★★
()

отпишусь тут
говорят скор поднимается от тех разделов

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

а еще то что нет дженериков, мне кажется вовсе не беда

как посмотришь на эти как их там, в джаве, - обобщенные классы или методы, так глаза в трубочку сворачиваются

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