Как стать автором
Обновить

Комментарии 20

>Когда в 2008 я впервые задумался о дженериках в Go, главными примерами были C#, Java, Haskell и ML.

Вы это серьезно? Java никогда не была образцом того, как надо делать дженерики. Тут чисто консервативный подход, выбранный с целью сохранить максимальную совместимость — и в итоге, с большим числом сильных ограничений, которые уже много лет аукаются там и тут.
Вы это серьезно? Java никогда не была образцом того, как надо делать дженерики. Тут чисто консервативный подход, выбранный с целью сохранить максимальную совместимость — и в итоге, с большим числом сильных ограничений, которые уже много лет аукаются там и тут.

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

Ну, дело в том, что то решение оказалось не очень. Понятно что лучше иметь такие дженерики, как в Java, чем никаких, но считать это хорошим образцом наравне с хаскелем — это какой-то явный перебор.
А где сказано, что выбор, который был сделан в Java, хороший?
>главными примерами были C#, Java, Haskell и ML. Но ни один из подходов, реализованных в этих языках, не выглядел идеально подходящим для Go.

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

Как это так ловко получилось "не выглядел идеально подходящим для Go" == "не идеальный, но подходящий"?

А как по вашему-то? Если он совсем не подходит — то зачем его рассматривать, как будто других мало? Причем других успешных (ну да, с поправкой на то, что это было в 2008 — все может быть было и не так радужно — но все равно уже была скала, например, где с этим все гораздо лучше).

Я наоборот пытаюсь понять, зачем они рассматривали реализацию в Java, при том что у Go очевидно другая ситуация. Как минимум — совсем нет никакого байткода, и никаких проблем обратной совместимости, с ним связанных.

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

НЛО прилетело и опубликовало эту надпись здесь
А мне очень хотелось бы иметь в Go задаваемые по умолчанию значения аргументов функций и элементов структур (насколько понимаю код компилятора, там аргументы функций хранятся как структуры как раз). Чтобы написать как-то так:
func Qwerty(a string, b string = "zxc") string {
  return a + b;
}
Это как раз про дженерики:
Qwerty(«hello»)
Qwerty(«hello», «world»)
Нет, с дженериками, насколько я понимаю, было бы как-то так:
func <T> Qwerty(a, b T) T {
  return a + b;
}
> Результаты тестов тоже нужно кешировать: если входные данные не менялись

Сомнительное предложение. Повторение тестов может выявить плавающие ошибки.
НЛО прилетело и опубликовало эту надпись здесь

Так если на звезды у "генераторов генериков" посмотреть, то понятно чего их откладывают

Когда в 2008 я впервые задумался о дженериках в Go, главными примерами были C#, Java, Haskell и ML. Но ни один из подходов, реализованных в этих языках, не выглядел идеально подходящим для Go. Сегодня есть более свежие решения, например, в Dart, Midori, Rust и Swift.


Что такое Midori? От какого года оригинальная статья?
Нажал на ссылку для вас: January 18, 2017
Спасибо. С вашей помощью я всё таки нашел эту ссылку.
https://research.swtch.com/go2017

По поводу Midori я нашел только
https://ru.wikipedia.org/wiki/Midori_(операционная_система)
а Go язык программирования, не понятно какие дженерики в операционной системе Midori?
Может быть есть язык программирования с названием Midori?
Я, увы, тоже не знаю о какой Midori говорит Russ Cox.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий