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

Generics enabled by default in Go tip

go-review.googlesource.com

Post reply on HN
Print view View original

331–340 of 378 posts

Re: Generics enabled by default in Go tip

#331

Post by sagichmal »

masklinn wrote: post #272
ibraheemdev wrote: post #265

Earlier quoted context omitted.

If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0]. The generics proposal is being implemented from the ground up. [0]: https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...

> If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0]. They're not generic (aka userland) generics, but they're still generics: parametric types, and functions able to work on them generically (you don't have a separate `append` function for every type you might put in a slice). > The generics proposal is being impleme…

> the builtins are ad-hoc and half-assed

In what way are slices and maps half-assed?

Re: Generics enabled by default in Go tip

#332

Post by whateveracct »

SergeAx wrote: post #240
tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

I am okay with generics as long as they are not affecting compile time. I love Go for blazing fast builds and testing and afraid generics will degrade it. Otherwise, generics are adding some cognitive complexity to code, but I don't have to use them and will just occasionaly have to figure them out in libraries.

Parametric polymorphism pretty much never adds cognitive complexity..it's the only true abstraction there is in CS.

Go could easily fuck it up tho - that's fair.

Re: Generics enabled by default in Go tip

#333

Post by pjmlp »

tptacek wrote: post #323
pjmlp wrote: post #322

Earlier quoted context omitted.

Yeah, we should have kept using macro assemblers instead of needless abstractions.

If you believe that absolutely, the way you imply here, then we're all just chumps for not working in Haskell.

Not necessarily Haskell, although it would be nice, there are already enough ML influences in modern languages, with exception of Go.

Confessions of a used programming language salesman

https://dl.acm.org/doi/10.1145/1297027.1297078

> As a result, functional programming has finally reached the masses, except that it is called Visual Basic 9 instead of Haskell 98.

Re: Generics enabled by default in Go tip

#334

Post by pjmlp »

13415 wrote: post #297
smokey_circles wrote: post #187

Language flamewars on internet forums are... strange. Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it? I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful. Use Go if you like the "clarity",…

There is no doubt that Go needs generics. Pretty much every Go container and data structure library on github will benefit from generics. The empty interface is used everywhere , leading to all kinds of panicking typecasts, hard to debug errors, and inefficient conversions. The vast majority of these uses can be made type-safe, more efficient, and clearer with generics. There is nothing subjective about the benefits…

Might be dead for FOSS, but still has 5 compiler vendors around and a new standard revision being done.

Re: Generics enabled by default in Go tip

#335

Post by pjmlp »

R0b0t1 wrote: post #231
SideburnsOfDoom wrote: post #219

Earlier quoted context omitted.

> Go adds generics. HN thread: I don't want this If generics are a good idea for a language, then it's better to add them in version 0.01 of the language and build up from there with generics as an intrinsic part of the language and standard libraries. No, I don't want _tacked on_ generics. Generics are not in 2021 a "bleeding edge" feature, that _might_ be useful later. They are established and proven in ways that t…

These don't seem tacked on. They spent so long on them specifically so they don't seem tacked on. The issue with Go is if you're not shuffling around binary data it has horrible developer ergonomics. Network data is usually untyped, but if you start needing to care about what is in that data and need typed datastructures built around it you stop having fun quick. Same issue with C, really.

There is lots of fun to had when debugging mismatched dynamic structures sent around the network.

It is no wonder that any new format introduced with hype to release developers from type safety boilerplate chains, a few years in production ends up getting its own flavour of schema definition.

Re: Generics enabled by default in Go tip

#336

Post by pjmlp »

vips7L wrote: post #310
josefx wrote: post #295

Earlier quoted context omitted.

> C++ The parsing rules for templates alone probably make a decent door stopper. They can also trivially kill compile times. The bloat from page long symbol names also isn't something to ignore, just std::map ::find() results in a decent chunk once the compiler is done expanding it. > Java That is a can of worms, haven't professionally worked with Java in some time, but from memory: * Compile time only, reflection or…

Fwiw generics in Java should have less holes once they start releasing things from Valhalla.

Yes, optional being the best example, it will be a proper primitive class.

Re: Generics enabled by default in Go tip

#337

Post by pjmlp »

pjmlp wrote: post #317
iainmerrick wrote: post #237

Earlier quoted context omitted.

No, I don't want _tacked on_ generics. What languages in your opinion have good, non-tacked-on generics? Are they generally better than other languages? Here are some pretty successful languages that gained generics after maturity: C++, Java, C#, TypeScript (based on JavaScript), Objective-C, even Python.

Ada, ML, Modula-3 and CLU got generics since day one. In fact, so much research and Go generics are mostly similar to CLU.

I forgot to mention Eiffel, Sather and BETA as well.

Re: Generics enabled by default in Go tip

#338

Post by pjmlp »

SergeAx wrote: post #240
tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

I am okay with generics as long as they are not affecting compile time. I love Go for blazing fast builds and testing and afraid generics will degrade it. Otherwise, generics are adding some cognitive complexity to code, but I don't have to use them and will just occasionaly have to figure them out in libraries.

Check ML languages with its multiple backends, Eiffel or Delphi/FreePascal.

Go compile times, while great, weren't any novelty to old timers before the .com wave that brought scripting languages into the spotlight and Sun's gigantic Java push.

Thankfully the 20 years detour seems to be getting over.

Re: Generics enabled by default in Go tip

#339

Post by pjmlp »

erik_seaberg wrote: post #326
masklinn wrote: post #271

Earlier quoted context omitted.

I fail to see what any of this has to do with reflection. > any script interpreter What are you even talking about. > or management RPC server I would very much expect RPC endpoints to be opted in explicitly and statically. > or other languages’ FFI? I fail to see why Go-level reflection would be involved in that in any capacity. > What good are top-level functions You can call them? From your go code? Are you saying…

When I type at a Groovy REPL, an interpreter is using reflection for nearly everything. Same goes for native code that has to use reflection via JNI entry points to call Java. It’s damn useful. At the heart of every debugger is a half-finished reflection API that deserves to be cleaned up and surfaced for language interop and novel kinds of tools.

Have a look at D and .NET 5 for compile time reflection.

Or in Java's case annotation processors.

Yes, not everything gets exposed, but it also does the job.

Re: Generics enabled by default in Go tip

#340

Post by pjmlp »

theshrike79 wrote: post #233
takeda wrote: post #107

Earlier quoted context omitted.

I think readability has multiple dimensions, and it really depends what you are looking for. For example here's a code in Go to look for a Prime: func IsPrime(n int) bool { if n It's readable as it is simple to understand what each line does. Here for example is a code that does the same thing in Rust: fn is_prime(n: u64) -> bool { match n { 0...1 => false, _ => !(2..n).any(|d| n % d == 0), } } It's might seem more c…

The difference here is that I can hand off the first code to any random freshly hired CS grad or cheapest outsourced coder and they can grok the code quickly. This is the advantage Go has to all other languages. The Rust code needs maintenance coders of way higher caliber, not something you'd usually find. It's super fun for the top-tier developers who love to be expressive and concise with their code, but all code i…

That was one of the points from Java 1.0.

Thing is, care with what you wish for when easy to outsource is a goal, a welcomed feature mostly relevant to IT managers that don't care about the final quality of delivery, nor what consequences it makes to the home job market.

So yeah to all Wipros, Infosys, TCS, .....

Post reply on HN