Go 1.18

Ну хоть такие дженерики, хоть что-то

Как бы и не дженерики, но как бы и «LOL NO GENERICS» уже не скажешь?

Лучше никак, чем так.

Нарушения DRY устраняют, что ещё нужно?

Современные языки в сторону полного перечисления покрываемых кейсов и движутся, так что чего ныть-то?

если заранее перечислить все типы аргументов, для которых применима эта функция;

это только один из двух способов ограничения:

Первый, скорее всего наиболее частый:

// ReadAll можно использовать для любого типа реализующего io.Reader
func ReadAll[R io.Reader](r R) ([]byte, error) {
    …
}

В т.ч. ограничение interface{} == any означает поддержку любого типа

Второй, со списком поддерживаемых типов

type Integer interface {
    int | int8 | int16 | int32 | int64
}

func Min[T Integer](a, b T) T {
    if a < b {
        return a
    }
    return b
}

Кажется самый значимый релиз в истории го.

Почему-то не упомянули fuzzing. На мой взгляд это важней генериков.

А кто-то будет обновляться? предлагаю остаться на 1.17 вечно. Дженерики не нужны.

Уже использовал в одной либе, как раз их ждал.

А как же тот, в котором их планировщик потоков с кооперативной многозадачности переехал на вытесняющую?

А как же тот, в котором их планировщик потоков с кооперативной многозадачности переехал на вытесняющую?

В Go хотят так сделать? O_o

реализованы «псевдогенерики»

Продавили. Значит го повторит путь цпп.

В Go хотят так сделать? O_o

Ага, подумывают. https://go.dev/doc/go1.14

Goroutines are now asynchronously preemptible. As a result, loops without function calls no longer potentially deadlock the scheduler or significantly delay garbage collection. This is supported on all platforms except windows/arm, darwin/arm, js/wasm, and plan9/*.

Вроде вполне все это симпатично выглядит. Интересно какие результаты будут в части быстродействия по сравнению с рефлексией …

Хз а что тут такого. Кажется не особо нужным.

С 1.14 сделали, насколько я помню.

Кажется не особо нужным.

А ты явно не из тех, кому доводилось дебажить RTOS на предмет «да где ж оно так надолго залипает!?».

Продавили. Значит го повторит путь цпп.

Закон анти-энтропии: всё усложняется.

На Go в основном бэк пишут, это так?

Системный софт тоже. Докер, например.

Ага, подумывают

Зачем тогда нужен этот Go? Я думал весь цимес языка в удобной кооперативной многозадачности.

Системный софт

Докер

эксперты, почему этот язык не стал таким buzzword, как rust? почему мы не встраиваем Go-подсистему в ядро?

почему мы не встраиваем Go-подсистему в ядро?

Из-за GC и runtime.

Относитесь к ЯП как к инструментам. Go создан и существует для других задач.

// ReadAll можно использовать для любого типа реализующего io.Reader

Бяка какая-то. Тут дженерик совершенно лишний. Лучше так.

func ReadAll(r io.Reader) ([]byte, error) {
    …
}

Вообще дженерики нужно использовать только там, где без них действительно не обойтись. Не стоит пихать их везде куда непоподя. И судя по всему сейчас многие так и буду делать.

Относитесь к ЯП как к инструментам.

я и отношусь, как у инструментам, но я не программер, а админ.

Из-за GC и runtime.

ну понятно

И что по-твоему не так с многозадачностью?

Из-за санкций не запретят писать на GO?) Шутка.

Ничего не мешает любому русскому собрать бинарник и распространять его. Санкции в отношении открытого ПО работают плохо.

Зачем оно когда есть Dlang, Crystal и Rust?

Продавили.

Что значит «продавили»? Если ты думал, будто разработчики были принципиально против дженериков, то это не так. Разработчики в своё время решили не реализовывать дженерики, чтобы не усложнять компилятор и быстрее выкатить хоть какую-то стабильно-рабочую версию языка. А также не могли выбрать, как именно их реализовать, а вариантов хватает, со своими плюсами и минусами. Например.

Популярное и с GC.

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

Бяка какая-то.

Специально реадалл взял, у какого-то укурка видел нечто подобное и откомментировал прям как ты сейчас )

Естественно, в этом случае нужно без генерыка. Просто для иллюстрации, ну и хохма.

эксперты, почему этот язык не стал таким buzzword, как rust?

потому как люди на нем пишут код и некогда заниматься словоблудием в отличие от )

почему мы не встраиваем Go-подсистему в ядро?

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

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

Специально реадалл взял, у какого-то укурка видел нечто подобное и откомментировал прям как ты сейчас )

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

но риторика всегда звучала как фатальный недостаток языка ))).

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

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

Для говнокодеров которые хотят с питона свалить.

Да нет, это всё ещё lol no generics.

почему?

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

Приведи конкретный пример, пока не понимаю, о чём ты.

Конкретный пример чего? Твоя функция – в одном пакете, типы, с которыми ты хочешь работать – в другом. А в третьем ты всё это вместе пытаешься вызывать. Всякие C++, Rust, Haskell и даже жабы это могут. Golang, похоже, не может.

Попробуй вот такое на голанге сделать:

#include <iostream>
#include <optional>
#include <vector>
#include <list>

using std::optional;
using std::vector;
using std::list;

template<template <typename> class V, typename A>
optional<A> sum(const V<A> &a) {
  if(a.empty()) {
    return {};
  }
  auto it = a.begin();
  auto r = *it++;
  while(it != a.end()) {
    r += *it++;
  }
  return r;
}

int main() {
  vector<int> v = { 1, 2, 3, 4 }; 
  list<double> l = { 1.0, 2.0, 3.0, 4.0 };

  std::cout << "Sum of vector<int>: " << *sum(v) << std::endl;
  std::cout << "Sum of list<double>: " << *sum(l) << std::endl;

  return 0;
}

И шоп оно работало с любым контейнером и любым типом с оператором +.

и еще мне go проще было бы освоить, чем раст, из-за похожести синтаксиса на Си. если уж rust пихают в системное программирование, то могли бы это учесть.

Go 1.18 (комментарий)

package main

import "fmt"

func sum[T any](items []T, zero T, add func(T, T) T) T {
	result := zero
	for _, item := range items {
		result = add(result, item)
	}
	return result
}

func main() {
	items := []int{1, 2, 3, 4, 5}
	s := sum(items, 0, func(x int, y int) int { return x + y })
	fmt.Printf("%v", s)
}

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

Посаны немного не в тему...в Fortran 77 длина имени переменной ограничена восемью символами. А можно ентот фортран переписать чтобы он не был ограничен?

items []T

Ты видишь проблему, да? А если там будет не массив, а список или множество? Или ещё хер знает что? Ну и передача функции для сложения – тоже так себе. Лучше уж тогда интерфейс сделай и не позорься.

Но вообще, голанг просто не может. Это девиз разработчиков языка должен быть.

Первый, скорее всего наиболее частый:
// ReadAll можно использовать для любого типа реализующего io.Reader

Это вообще какая-то бессмыслица, а не обобщённое программирование. Это всё уже реализуется интерфейсами. Тебе не нужно писать обобщённый код, чтобы работать с экземпляром интерфейса:

package main

import "fmt"

type animal interface {
	breathe()
	walk()
}

type lion struct {
     age int
}

func (l lion) breathe() {
	fmt.Println("Lion breathes")
}

func (l lion) walk() {
	fmt.Println("Lion walk")
}

type dog struct {
     age int
}

func (l dog) breathe() {
	fmt.Println("Dog breathes")
}

func (l dog) walk() {
	fmt.Println("Dog walk")
}

func main() {
	l := lion{age: 10}
	callBreathe(l)
	callWalk(l)

	d := dog{age: 5}
	callBreathe(d)
	callWalk(d)
}

func callBreathe(a animal) {
	a.breathe()
}

func callWalk(a animal) {
	a.breathe()
}

Интересно какие результаты будут в части быстродействия по сравнению с рефлексией …

При чём тут вообще рефлексия, алё? Это всё логика времени компиляции.