proper generics would be C++ but it is called templates and could be hardcore..
https://stackoverflow.com/a/498329/729738
.Net generics do have same issues mentioned in the article
Go generics are not bad
51–60 of 305 posts
Re: Go generics are not bad
#52I think in Java, you would need to do a type-class approach. interface Numeric { T zero(); T add(T a, T b); } static T sum(Numeric n, T[] v) { T summer = n.zero(); for (int k = 0; k
also in .Net but then you enter a generic hell and you start thinking vanilla es6 is better
Re: Go generics are not bad
#53I think Go's generics are reasonable, but not quite powerful enough to scale. It's all well and good to generalize basic containers and functions (good, in fact), but I wish the language was better at inferring types. I'm sure this is something that will improve with time, but a bit after generics were released, I tried to build a type-safe language evaluator in Go using generics and found them lacking the kind of ty…
I think I am glad that kind of stuff doesn’t work, because that was pretty hard to read. Go is trying to keep things simple.
If you want a sophisticated type system with a language they complied to native code then use Swift or Rust.
I personally think it is good to have some choice in complexity level and that at least one language, Go, tries to carve out a niche in simplicity.
I am only barely convinced that generics was the right choice for Go.
Re: Go generics are not bad
#54The title says Go generics are not bad, and then in less than a page this guy only compared one use case with Java's generics. I'd expect a CS professor to be able to add a little more rigor in a blog post but I guess everyone is losing patience to read and write these days, even for the supposedly erudite.
This is his blog, he can write whatever he wants. It is not a peer reviewed paper or even arXiv. Someone submitted and people liked it, and it ends up in HN front page. All I am saying, please don't put pressure on random blog writers. You can criticize the content without saying "CS professor can be more rigor".
I only expected a CS professor to discover some of issues listed here:
https://go101.org/generics/888-the-status-quo-of-go-custom-g...
I mean, my cousin still in high school can do better than that...
Re: Go generics are not bad
#55Earlier quoted context omitted.
For example, by not allowing one to create a parametrized method. `func (self SomeNonGenericType) Foo[T any](param T) T` is not allowed, best one can do is `func Foo[T any](self SomeNonGenericType, param T) T`. The reasons are explained here: https://go.googlesource.com/proposal/+/refs/heads/master/des... but the point is, you can have this in Java, but not in Go.
You can certainly use generic parameters in methods—the [T any] just has to be on SomeNonGenericType, even if it's not used inside the type itself https://rakyll.org/generics-facilititators
Yes, but that's completely different thing. If you move T you would change the semantics.
- func (self SomeType[T]) Foo(...) is a method for a class parametrized on T. So if you want foo.Foo(1) then it only works for foo that's SomeType[int]. You cannot then easily call foo.Foo("one") on the same instance.
- func (self SomeType) Foo[T any](...) - if that'd be a thing - would be a generic method on SomeType that works for any T. So you can foo.Foo(1) and foo.Foo("one") on the very next line and that would work.
Re: Go generics are not bad
#56This is like the most cherry-picked example that could've been chosen. Java can't do this because the primitive types are not objects. Mentioning the performance of this is hilarious because 1. it's Daniel Lemire, he should know better and 2. the performance of pretty much every other thing that uses generics is terrible because of gcshapes being passed everywhere and 3. Java literally has a JIT to make generics fast…
Cherry picked? When write programming code examples this kind of thing would be the first thing I would try.
I would rather call it cherry-picking if one avoided covering such a case to make Java look good. Seems like a pretty obvious problem to me.
Handling basic number types is pretty bread and butter.
Re: Go generics are not bad
#57this article is hilarious: 1. go generics do this one thing 2. therefore they are good Go generics are better than no generics but they're still limited, and that frustrates me.
Could you give some concrete examples? Something which requires a type of Go generics but which cannot easily be solved in another way?
Re: Go generics are not bad
#58Re: Go generics are not bad
#59"not bad" is a weird bar to cross for a language that: 1. decided generics is not needed 2. went on for a decade 3. implemented a version of it that is not performance-sensitive 3.5. $$ by google
Not sure how 3.5 follows.
Re: Go generics are not bad
#60C++ generic programming is super effective and efficient even if not super user-friendly til concepts landed. The good thing about Go generics is thatis has monomorphic generics for value types. That is fundamental. Java messed it up with type erasure and now they are wirh all this Valhalla project for years.