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

321–330 of 378 posts

Re: Generics enabled by default in Go tip

#321

Post by pjmlp »

mseepgood wrote: post #298
masto wrote: post #264

Earlier quoted context omitted.

I don’t know, at this point my guess is that most people just don’t care, so those that can be bothered to comment are a bit fringe. When Go first came out, it seemed interesting, but when I checked it out it felt more like throwing out the baby with the bathwater than introducing anything of value. Not every idea since 1972 is bad. So I tried to force myself to use it for a project or two, got frustrated by exactly…

> I haven’t seen any meaningful adoption You must live in a different world. Go has been an immense success since its inception. Cloud, DevOps and SRE are nowadays unthinkable without it.

I must be doing something wrong with Java, .NET and Powershell.

Re: Generics enabled by default in Go tip

#322

Post by pjmlp »

tptacek wrote: post #98
jolux wrote: post #96

Earlier quoted context omitted.

There are certain things that just can’t be done without generics, though. Type safe higher order functions, type safe custom collections, etc. Of course, perhaps these are all just subjective to you, because you can still write any program you need without them. But not having this feature does constrain the set of type-safe programs you can write quite a bit.

I feel like it pretty much always turns out that the things you can't do without generics are, like, second-order things. Higher order functions, type safe custom collections, those are tools. What we care about mostly is what we actually build , and people build pretty much everything in every language, generics or not.

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

Re: Generics enabled by default in Go tip

#323

Post by tptacek »

pjmlp wrote: post #322
tptacek wrote: post #98

Earlier quoted context omitted.

I feel like it pretty much always turns out that the things you can't do without generics are, like, second-order things. Higher order functions, type safe custom collections, those are tools. What we care about mostly is what we actually build , and people build pretty much everything in every language, generics or not.

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.

Re: Generics enabled by default in Go tip

#324

Post by jagger27 »

jshen wrote: post #309
c-cube wrote: post #287

Earlier quoted context omitted.

If people can understand functions, they can understand generics. Nothing more complicated, generics are just functions on a few type arguments.

Here’s an example from this very thread that shows how complex generics get relatively quickly. https://news.ycombinator.com/item?id=28255738

That example is essentially the most basic use of generics. There are much more complex examples that would support your argument better.

What do you find confusing about that code?

Re: Generics enabled by default in Go tip

#325

Post by jshen »

jagger27 wrote: post #324
jshen wrote: post #309

Earlier quoted context omitted.

Here’s an example from this very thread that shows how complex generics get relatively quickly. https://news.ycombinator.com/item?id=28255738

That example is essentially the most basic use of generics. There are much more complex examples that would support your argument better. What do you find confusing about that code?

I don’t find it confusing, but it is certainly more complex than a simple function call. I chose it because it is a basic usage of generics, to highlight that basic generics are more complex than basic function calls.

A code base that makes heavy usage of generics takes more time to understand than one that doesn’t make heavy use of generics. The readability of go is what I love about it, amongst a few other things.

Re: Generics enabled by default in Go tip

#326

Post by erik_seaberg »

masklinn wrote: post #271
erik_seaberg wrote: post #242

Earlier quoted context omitted.

What good are top-level functions if they’re unreachable from any script interpreter or management RPC server or other languages’ FFI?

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.

Re: Generics enabled by default in Go tip

#327

Post by xh-dude »

jacobvosmaer wrote: post #212
xh-dude wrote: post #154

Earlier quoted context omitted.

Parametric polymorphism is a better fit for container types IMHO. There are some interesting notes here… In Go prior to generics, interface{} is an escape hatch less frequently needed but not necessarily much safer than void*. Post generics, interface{} is suddenly more useful and will be aliased by ‘any’. The way the std lib heap works in Go, an implementation doesn’t have to mention interface{}. Using the Go std li…

>not necessarily much safer than void* You can cast void* to anything you want. With interface{} you get a type check, either through an assertion or a panic. That is a big difference in safety.

Fair point. Maybe there are contrived cases that can get nasty (an interface{}-typed variable boxing a function is possible, not so with any non-empty interface ), but in practice the pathology would be ‘panic’ more than ‘here are the keys to the exploit kingdom’, if this is what you were thinking.

I was thinking more about silence where someone expected a greater degree of compile-time type safety than they really had, or relatedly e.g. the subtleties in JSON encoding / decoding where there is silent data corruption that could fall through the cracks - mostly I feel like I avoid these things by not using interface{}; I certainly did not grasp that without some experience with the language.

Re: Generics enabled by default in Go tip

#328

Post by erik_seaberg »

Taek wrote: post #253
fiddlerwoaroof wrote: post #63

Earlier quoted context omitted.

Optimizing for people that are new to a codebase seems like a mistake to me: onboarding costs are relatively minimal and finite (per developer) whereas maintenance costs have no fixed bound: if generics let you exclude invalid states by design (and they do: this is one of the biggest advantages of parametric polymorphism vs. interfaces), they will be useful for keeping maintenance costs under control.

You definitely want to optimize for people who are new to a codebase. Over enough time, the codebase grows to a point where essentially _everyone_ is new to each area of the code, because nobody has touched that code in 2-3 years and the person who wrote it may not even be with the project anymore. Even for your own single-person projects - if you get fancy with the code, 6 months later you find it's a lot harder to…

Management is responsible for making sure that doesn’t happen, by retaining experts and demanding documentation and investing in ramping up new experts. Making the code bigger because each line does less is not going to save us from nobody understanding prod, and a short learning curve puts a low limit on the value of our staff (who quickly run out of tools and stop improving in clarity and productivity).

Re: Generics enabled by default in Go tip

#329

Post by jolux »

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.

I feel like I should probably admit that I am just generally a fan of functional programming and I do think there are big benefits to it, most of the time (of course, some algorithms are just more elegant with loops and mutation). But my day job is writing services with Elixir, so ultimately complaining about generics in Go is a little rich coming from me.

At the end of the day, whatever gets the product built is what matters. I just fail to see how generics could be a hindrance.

Re: Generics enabled by default in Go tip

#330

Post by yawaramin »

I'm not a Go user; I don't consider it serious as a programming language. True, it has great tooling. It seems perfectly designed for certain groups of devs to bang out lower-level tools and utilities, and they love it for being such a great fit.

That said, I think some of them may have a point that Go shouldn't actually try to tack on generics now. Consider that generics are only one piece of the puzzle when it comes to programming language power and abstraction capability. There are also ADTs, abstract types, pattern matching, immutability, lack of null, expression-oriented syntax, etc.

Go with generics would be only one step along that journey of abstraction power. It would help the set of people who desperately need it to solve their code repetition and type-casting issues. But it would solve these problems just to clear the way for them to reach the next set of problems on the journey of abstraction.

Post reply on HN