Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go: Support for Generic Methods

github.com

Post reply on HN
Print view View original

151–160 of 288 posts

Re: Go: Support for Generic Methods

#151

Post by _jackdk_ »

assbuttbuttass wrote: post #141
xena wrote: post #92

This will finally let me make the monad library I've been dreaming of for years. Be afraid.

It's (sadly) still not possible to express monads with this change, since generic methods can't implement interfaces. You'd probably want something like: type Monad[T any] interface { Bind[U any](func(T) Monad[U]) } However this requires the Bind method to be generic, which still isn't allowed in an interface

I am not very familiar with Go and especially not its generics support. Can you implement the "join" version instead of the "bind" version, where you turn a T[T[a]] into a T[a]?

Re: Go: Support for Generic Methods

#152

Post by sunsetSamurai »

poncho_romero wrote: post #60
ramon156 wrote: post #5

Earlier quoted context omitted.

So which language had it right from the start? is there a language that has a very low rewrite status?

I think Elixir is a good candidate here. It's small, coherent, and composes well, and (at least to my understanding) the authors consider the language finished, with no new major features planned.

Elixir is missing static types though, it's hard to go back to work on dynamic languages.

Re: Go: Support for Generic Methods

#153

Post by sunsetSamurai »

Maxatar wrote: post #66
maccard wrote: post #13

Earlier quoted context omitted.

That’s whataboutism - no language is perfect, but given when go released it’s fair to hold them to a higher standard than languages what were designed 25 years earlier. As an aside - D, Zig, Rust, even typescript got most of the lessons learned from C right

D literally can't even maintain backwards compatibility between minor version updates not to mention a big part of the D community left when D reinvented itself with D2. Among languages it's probably the one that is constantly in a state of flux.

what's a big project built with D? I feel it gets mentioned a lot on hackernews but I've never run into any project using it in the wild.

Re: Go: Support for Generic Methods

#155

Post by symaxian »

someone_19 wrote: post #84
layer8 wrote: post #24

Earlier quoted context omitted.

It’s still annoying ~20 years after Java did the same mistake of not including generics, which was already clear to many people with C++ experience back then.

...and Java didn't even have basic enums or sum types from the beginning. But it had null. They added enums, they added sealed classes. They're trying to get rid of null (apparently it's really hard). The problem is that in 2012, when go 1.0 was released, this should have been obvious to everyone. Here's a famous discussion from 2009, three years before the 1.0 release (tldr: facepalm) https://groups.google.com/g/gol…

That is an interesting read, seems some were having a hard time grasping the benefit of having compiler checks for potential null dereferences. Having worked with null safety in TypeScript and Kotlin the extra bit of strictness is nice.

Re: Go: Support for Generic Methods

#156

Post by ratrace »

chlorion wrote: post #108
fhn wrote: post #62

Earlier quoted context omitted.

so make your own and let's see how you do

I am actually working on my own language, and getting something better than Go is actually not that difficult! The hard part about making a language is creating the stdlib and tooling and support for the language, but actually creating a language itself that has more features and better features than go can be done by a single person in a few months or a year probably, depending on how much experience they have. Gene…

[dead]

Re: Go: Support for Generic Methods

#158

Post by 20k »

zarzavat wrote: post #149
h1fra wrote: post #2

slowly implementing all the things they said we didn't need

Watching Go's development is like reliving the development of Java (which also didn't have generics at first), but over decades instead of years. Cannot wait for Go to implement an error handling system in the 2030s.

Its very funny watching certain segments of the programming industry rediscovering incredibly basic programming principles, after railing against them for so long. The AI people are starting to try and create formal specs to force the AI to generate an exact output, which is absolutely hilarious to me

Dynamically typed/untyped languages finding that strict and visible typing is actually good is another

Re: Go: Support for Generic Methods

#159

Post by 20k »

j_w wrote: post #112
School-Cotton wrote: post #85

Earlier quoted context omitted.

An array of arrays is an extremely inefficient and error-prone way to represent multidimensional arrays. If I want a 1000x1000 array, representing it physically as a single 1000000-element array requires one allocation, and processing it element-by-element (assuming it's stored in the same order we're iterating over it) is sequential in memory and therefore very efficient. Representing it as 1000 separate 1000-elemen…

Isn't an array of arrays by definition the sequential implementation? Otherwise you would have an array of pointers to arrays. The usage (syntax) for them would be the same but the performance would not be. They also have different uses. You would expect an array of arrays to be an array of arrays which share the same length. For an array of pointers to an array you would expect dynamic length arrays contained within…

The C++ way to do it currently would be:

    std::array, M> data;
Which is contiguous

    int data[M][N];
also works fine and is contiguous in C++

Edit:

For the stack at least. On the heap, you'd need to use a single std::vector and do the indices manually, or use mdspan

Re: Go: Support for Generic Methods

#160

Post by ratrace »

stouset wrote: post #113
9rx wrote: post #46

Earlier quoted context omitted.

The social landscape doesn't depend on anyone actually using it. However, 1.0 isn't a significant milestone like you suggest either. For a current example, Zig is relatively popular today despite not yet reaching 1.0.

Do you just forget the things you write in earlier comments? > Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing Of course the social landscape depends on people actually using it. None of the people who weren’t using Rust at the time were magically confused about enums and sum types by the mere existence of some new and experimental language. Rust barely e…

[dead]
Post reply on HN