Комментарии 45
Я думаю что дженерики стоит использовать только в самых общих библиотеках. Их ипользование в логике будет создавать хаос.
Думаю, .NET-разработчики с этим не согласятся. Просто всё надо стараться делать с умом)
А так же появятся библиотеки реализующие Where, Order, Any и подобные методы для мапов и слайсов
Интересно, а почему бы такие популярные вещи не сделать в стандартной библиотеке? Противоречит ли это философии авторов Go? Точно помню и Роб Пайк, и Расс Кокс говорили, что всегда хотели оставить язык минималистичным, но про стандартную библиотеку вроде ничего такого не говорилось.
LINQ по моему скромному мнению вышел чрезвычайно удачным и удобным на практике. Было бы приятно увидеть его аналог в Go. Заодно упражнение это было бы отличным тестом возможностей дженериков.
Аббревиатура LINQ обозначает целый набор технологий, создающих и использующих возможности интеграции запросов непосредственно в язык C#.
Вы именно LINQ хотите в виде специфичного синтаксиса вида from x in .. where .. select x.something ? или в виде методов (расширений) некой объектной модели вида x.Select(), x.Any() и т.д.?
Если первое, то вряд ли в Go захотят подобное сделать, если второе - есть уже некое подобие https://pkg.go.dev/github.com/ahmetb/go-linq
В цивилизованном обществе про "специфичный синтаксис" речь обычно не идет, я думаю Вы это прекрасно понимаете, раз в профиле .NET на первом месте.
За наводку на библиотеку спасибо - было интересно посмотреть исходники, особенно реализацию "T-версий" функций с кустарной реализацией дженериков. Вероятно с новым релизом языка она сильной упростится!
Так, а универсальную функцию сортировки любого типа пока еще нельзя написать, получается? Свои оператор <, >, ==, != ведь не реализовать...
Кстати, они именно дженерики, а не шаблоны? Т.е. применяется упаковка (в interface{}), а не мономорфизация как в С++?
Это всё дженерики (обобщения). Реализацией их думаю будет боксинг (упаковка) из соображения совместимости.
А где можно почитать, какие у дженериков под капотом есть варианты реализаций?
А тут варианта всего 2: либо нагенерировать функций для каждого типа по одному шаблону, либо сделать все типы бинарно совместимыми через упаковку в наиболее общий тип, чтобы его можно было передавать одной и той же обобщённой функции.
Вот отличная статья: https://habr.com/ru/company/vk/blog/461321/
В рантайме рефлексии не будет. Разработчики называют это stenciling. Подробнее github.com/golang/proposal/blob/master/design/generics-implementation-gcshape.md
Go как всегда, лишь бы не как у всех. Какая мотивация использовать [T] вместо привычного <T>? Те кто пишет на разных языках будут страдать
https://gist.github.com/tooolbox/fb385bfa05032ddc989afb393948be48
вкратце, скорость парсинга, невозможно без анализа семантики отделить от сравнения.
И да изначально полукруглые были, были большие дискуссии, в итоге заменили на [ ]
Скорость парсинга? Серьезно? если это было реальной причиной, то они явно свернули не туда. На сколько должна замедлится сборка, чтобы это стало важнее читабельности языка
А с чего вы взяли, что все языки должны разрабатываться под ваши личные привычки? Нормально задизайненные языки не используют угловые скобки для обобщённых параметров из соображения однозначности синтакиса.
Нормально задизайненные языки не используют угловые скобки для обобщённых параметров из соображения однозначности синтакиса.
т.е. все мейнстримовые языки, делают это не правильно? У вас квадратные скобки не ассоциируются с массивом например?
Есть устоявшиеся вещи, которые в целом всех устраивают и к которым все привыкли, зачем их менять? Только не говорите про ускорение парсинга, никто этого даже не заметит
Угу, не правильно. Вот, пример, где разработчики языка включили мозг и позаботились о пользователе, а не стали бездумно копипастить ошибки прошлого: https://dlang.org/articles/templates-revisited.html#argument-syntax
А вот примеры, где мозг сразу не включили, и сделали как привычно, а потом расхлёбывали:
https://stackoverflow.com/questions/37613981/how-to-use-a-typescript-cast-with-jsx-tsx
https://rsdn.org/forum/cpp/4056508.all
Квадратные скобки у меня ассоциируются с квадратами, круглые с кругами, угловые с треугольниками, а фигурные с сиськами. И что? Введём в язык оператор для рисования сисек?
В разных языках квадратные скобки используются для разных вещей. Например, для доступа к полям объекта в js. Или для двустороннего связывания в angular. Или для аннотаций в c#. И так далее.
Не только и не столько ускорение парсинга, но и упрощение компилятора и сопутствующих инструментов, например подсветки синтаксиса в редакторах. Для того чтобы понять что имеется в виду в выражении A < B > C нужна информация о типах и объектах, она может быть доступна не всегда, и в общем случае получается на более поздних проходах компилятора.
Можно ввести какую-нибудь дополнительную пару скобок из Unicode, например 〈 〉 или〈 〉. Но пока только как дополнение к ASCII-совместимому синтаксису. Нечто подобное было в C/C++ - диграфы и триграфы, кажется их убрали совсем недавно (или только собирались убрать?)
A < B > C
Разве это валидный код Go? В чем там больше проблем по сравнению например с A[B[C]]?
Ну вы же спрашивали
Какая мотивация использовать [T] вместо привычного <T>?
В том что скобки - они везде скобки; а < > это еще и "меньше" и "больше" и они могут идти не парой, а по отдельности. Всякие системы подсветки синтаксиса или построения дерева быстрого доступа к коду (outline) в редакторах не производят полноценный синтаксический анализ, а ограничиваются "скобочным анализом".
если это было реальной причиной, то они явно свернули не туда
Сама суть Go в быстрой компиляции.
У них в приоритете скорость компиляции, а не удобство? Есть ассемблер, очень быстро компилируется.
Есть ассемблер, очень быстро компилируется.
Go все же более высокоуровневый язык.
Компиляция - это процесс перевода из одного языка в другой. Ассемблер это набор мнемоник для машинных кодов процессора. В этой классификации, ассемблер не компилируется, ассемблер интерпретируется аппаратно процессором.
У ассемблера нет сборщика мусора. С ним явно удобнее, чем без, поэтому go всё же удобнее ассемблера
Я думал что в минимальном ортогональном наборе ключевых слов
Как сказать, Go не будет первым языком использующим квадратные скобки для обольщений.
Ну вот в скале как раз [T]
Здорово, что обобщенное программирование приходит в Go, но выглядит неполно. Работа с типами в рантайме через reflect убивает почти всю мощь шаблонов. Из плюсов конечно не надо будет на каждый тип свою функцию писать.
Golang пощупаем дженерики