range по функциям в Go
В Go 1.23 (август 2024) появится цикл range по функциям. Проще всего показать на примере.
Предположим, вы написали собственный тип OrderedMap, который (в отличие от обычной карты) сохраняет порядок элементов.
Сделали ему конструктор и метод Set:
m := NewOrderedMap[string, int]()
m.Set("one", 1)
m.Set("two", 2)
m.Set("thr", 3)
Хорошо, а как теперь итерироваться по карте? Традиционно это делали примерно так:
m.Range(func(k string, v int) {
fmt.Println(k, v)
})
// one 1
// two 2
// thr 3
А с новой фичей range-over-func можно сделать так:
for k, v := range m.Range {
fmt.Println(k, v)
}
То есть это такой синтаксический сахарок.
Стоило ли оно того
Стоило ли добавлять в язык range-over-func? На мой взгляд — нет.
Сила Go — в дубовости. У нас уже есть много фичастых языков с большой внутренней сложностью (Java, C#, C++), и Go был единственной простой мейнстрим-альтернативой для них.
Да, Go не модный, и код на нем простынявый. Но он простой до примитивности, и это хорошо.
С появлением дженериков в 1.18 по простоте языка был нанесен серьезный удар (вероятно, оправданный). Теперь же авторы продолжают усложнять язык без веских на то причин, просто чтобы было красивенько.
Почему так происходит?
Есть подозрение, что в команде разработки Go заработал стандартный для гугла процесс — promotion-driven development. Развитием языка управляют люди, которым надо демонстрировать выполнение KPI — а значит, будут поливать Go фичами из шланга, превращая в еще одну джаву.
Ждут нас и корутины, и стримы, и паттерн-матчинг.
Штош.
★ Подписывайтесь на новые заметки.