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

Go 1.21 Release Candidate

go.dev

Post reply on HN
Print view View original

231–236 of 236 posts

Re: Go 1.21 Release Candidate

#231

Post by philosopher1234 »

alex_lav wrote: post #229
philosopher1234 wrote: post #226

Earlier quoted context omitted.

I would like to see some content from the go team on generics or clear that fits your claim. Yes, there are many in the community who speak the way you suggest, but you don’t seem to know much about the Go teams pov.

https://news.ycombinator.com/item?id=23033183 A pretty apt write up. But I accept there’s probably not an amount of evidence to change your belief on Go’s dogmatism. And that’s okay! You like a language. That’s great!

From what I can tell the issue here is that Rob Pike thinks the label "generics" is inaccurate? Seems like a far cry from what you have accused them of. I think theres not only a lack of evidence to convince me, I think your claim is just straight up unsubstantiated. I think an unbiased, responsible observer would have to conclude similarly to me.

Re: Go 1.21 Release Candidate

#232

Post by stouset »

fuzztester wrote: post #225
stouset wrote: post #211

Earlier quoted context omitted.

In my experience, go has tons of footguns that come because of the verbosity. Rather than having clear abstractions that handle edge cases for you, you get to reimplement these things yourself every single time. Case in point, clear. Or "typed nils". Or accidentally swallowing errors because you had to handle them manually. Or reimplementing higher-level job control on top of channels every single time .

>Or reimplementing higher-level job control on top of channels every single time. Can you please explain this?

Maybe generics have fixed this, I threw in the towel on golang before they released them.

But as an example, if you wanted to have any sort of higher-level management of goroutines (for example, a bounded number of background workers) you get to rewrite or copy-paste that code every place you want to accomplish that. A library couldn't exist to abstract away the idea of a pool of background workers because it can't know in advance what types you want to send over your channels.

Again, I wouldn't be surprised if post-generics there's a library now to do this for you. But for years if you wanted anything higher level than raw channels, you're basically on your own.

Re: Go 1.21 Release Candidate

#233

Post by euroderf »

preseinger wrote: post #227
euroderf wrote: post #213

Earlier quoted context omitted.

In practical terms there's pros & cons I guess, but in general doesn't loading a Context with session variables make code more concise and easier to understand ? DB connections, loggers, and the like. If you really want to pass around Context's in all your API signatures then at least try to make the most of it. Are pitfalls ever actually encountered ?

if you pass a logger to a foo as a parameter to the foo constructor, then missing a logger is a compile-time error if you pass a logger to a foo as a parameter in the request context, then missing a logger is a run-time error

Fer sher. But a passed-by-Context logger could be used (for example) to override a library package's default (stdlib?) logger.

But what is the SOP / Best Practice here ? Do many libraries have some sort of SetLogger(..) initialization call, so that loggers don't clutter the API ? Or are error returns info-(over-)loaded ?

Re: Go 1.21 Release Candidate

#234

Post by alex_lav »

philosopher1234 wrote: post #231
alex_lav wrote: post #229

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=23033183 A pretty apt write up. But I accept there’s probably not an amount of evidence to change your belief on Go’s dogmatism. And that’s okay! You like a language. That’s great!

From what I can tell the issue here is that Rob Pike thinks the label "generics" is inaccurate? Seems like a far cry from what you have accused them of. I think theres not only a lack of evidence to convince me, I think your claim is just straight up unsubstantiated. I think an unbiased, responsible observer would have to conclude similarly to me.

> I think an unbiased, responsible observer would have to conclude similarly to me.

Unsurprising conclusion. Enjoy the day!

Re: Go 1.21 Release Candidate

#235

Post by fuzztester »

stouset wrote: post #232
fuzztester wrote: post #225

Earlier quoted context omitted.

>Or reimplementing higher-level job control on top of channels every single time. Can you please explain this?

Maybe generics have fixed this, I threw in the towel on golang before they released them. But as an example, if you wanted to have any sort of higher-level management of goroutines (for example, a bounded number of background workers) you get to rewrite or copy-paste that code every place you want to accomplish that. A library couldn't exist to abstract away the idea of a pool of background workers because it can't k…

Just saw your reply now. Thank you.

Re: Go 1.21 Release Candidate

#236

Post by preseinger »

euroderf wrote: post #233
preseinger wrote: post #227

Earlier quoted context omitted.

if you pass a logger to a foo as a parameter to the foo constructor, then missing a logger is a compile-time error if you pass a logger to a foo as a parameter in the request context, then missing a logger is a run-time error

Fer sher. But a passed-by-Context logger could be used (for example) to override a library package's default (stdlib?) logger. But what is the SOP / Best Practice here ? Do many libraries have some sort of SetLogger(..) initialization call, so that loggers don't clutter the API ? Or are error returns info-(over-)loaded ?

it's pretty straightforward, everything that logs takes a logger as a dependency during construction
Post reply on HN