71–80 of 305 posts
I 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
"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.
Earlier quoted context omitted.
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…
I 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
Earlier quoted context omitted.
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…
Earlier quoted context omitted.
It doesn't. Picking an area where Java is weak and where Go happens to be decent is the very definition of cherry picking. Go happens to do poorly in almost every other area and Java does meh in many (erasure, unsoundness, etc.) and excellent in others (profile-guided devirtualization).
really? Is Go that bad? Write a server that does communication or emulate select in Go in other languages. Go is really effective at writing things fast at the same time that it has value types and can scale not only in I/O but also in multi-core in a way that is easier than anything I saw before. I am a mainly C++ person but I must admit that the cost/investment ratio in Go is really good for writing server-side stu…
I'm personally no fan of Go (mostly due to the ergonomics of the standard library), but all this about generics is throwing the baby out with the bathwater. Go has a fantastic generics design.
> cost/investment ratio in Go is really good for writing server-side stuff.
And this 100%.
This 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…
???
By the time it gets to the JIT, java generics have long since been erased.
Java's generic classes run at the same speed as everything else, because there's no actual generics there.
(Although I'd be very surprised if this doesn't change in the near future: https://openjdk.org/jeps/8261529.)