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

211–220 of 236 posts

Re: Go 1.21 Release Candidate

#211

Post by stouset »

maccard wrote: post #198
klodolph wrote: post #120

Earlier quoted context omitted.

I guess, but that seems expected to me at this point, and consistent within the semantics of how slices and maps work (and other values). Maps are kind of like type map *struct{ len int; ... } Slices are kind of like type slice struct{ len int; ... } We get a lot of convenience by having the pointers auto-dereferenced, but the cost is that the semantics are still different and there are no syntactic markers to remind…

Every language has sharp edges, but go's whole MO is to avoid rabid footguns at the expense of verbosity (IMO). The for-shadow issue thats fixed this release is a great example of go deciding to do the intuitive thing rather than the "correct" thing because that's how people work. I don't think the implementation details matter to a user of a map or a slice (or an array for that matter) - they're language builtins (a…

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.

Re: Go 1.21 Release Candidate

#212

Post by yencabulator »

stouset wrote: post #209
yencabulator wrote: post #171

Earlier quoted context omitted.

No, it's because a use case was discovered that the for loop approach can't handle: NaN keys.

In my experience, that's exactly how this plays out every single time. Dev: Can we have a function to clear a map? Go: No, it's easy enough to write the 5 lines of code to just do it yourself every time. Dev: Okay, I don't see why I should have to write those 5 lines every time but fine. Isn't looping over everything going to be slower than just… having a function that can empty the internals? Go: We've implemented a…

You're distorting the real story to fit your bias. Once the NaNn edge case was discovered, work to deal with that edge case was started.

Re: Go 1.21 Release Candidate

#213

Post by euroderf »

preseinger wrote: post #207
euroderf wrote: post #195

Earlier quoted context omitted.

"The context stores request-scoped data" might be another Go-team dogma due for course correction RSN.

huh? there's no dogma involved here, it's just an observation of the properties of the type a context is created with each request, and destroyed at the end of it and values stored in a context are accessible only through un-typed, runtime-fallible methods -- not something you want to lean on, if you can avoid it

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 ?

Re: Go 1.21 Release Candidate

#215

Post by stouset »

yencabulator wrote: post #212
stouset wrote: post #209

Earlier quoted context omitted.

In my experience, that's exactly how this plays out every single time. Dev: Can we have a function to clear a map? Go: No, it's easy enough to write the 5 lines of code to just do it yourself every time. Dev: Okay, I don't see why I should have to write those 5 lines every time but fine. Isn't looping over everything going to be slower than just… having a function that can empty the internals? Go: We've implemented a…

You're distorting the real story to fit your bias. Once the NaNn edge case was discovered, work to deal with that edge case was started.

This isn't remotely close to the first or even the tenth time I've seen this exact pattern play out. Finally there's some straw that forces the golang team to backpedal on a dogmatic position, but along the way there's dozens of comical defenses of the current state of things.

Re: Go 1.21 Release Candidate

#216

Post by alex_lav »

yencabulator wrote: post #212
stouset wrote: post #209

Earlier quoted context omitted.

In my experience, that's exactly how this plays out every single time. Dev: Can we have a function to clear a map? Go: No, it's easy enough to write the 5 lines of code to just do it yourself every time. Dev: Okay, I don't see why I should have to write those 5 lines every time but fine. Isn't looping over everything going to be slower than just… having a function that can empty the internals? Go: We've implemented a…

You're distorting the real story to fit your bias. Once the NaNn edge case was discovered, work to deal with that edge case was started.

Can you link to any unit of work that solves this edge case? Because all I can find are bugs and issues created 2015/2016/2017 that were closed and unresolved.

Re: Go 1.21 Release Candidate

#217

Post by alex_lav »

stouset wrote: post #209
yencabulator wrote: post #171

Earlier quoted context omitted.

No, it's because a use case was discovered that the for loop approach can't handle: NaN keys.

In my experience, that's exactly how this plays out every single time. Dev: Can we have a function to clear a map? Go: No, it's easy enough to write the 5 lines of code to just do it yourself every time. Dev: Okay, I don't see why I should have to write those 5 lines every time but fine. Isn't looping over everything going to be slower than just… having a function that can empty the internals? Go: We've implemented a…

I used to really like Go. Now that I don't work with it, I find that the further I go on without it, and with using other tools, the less and less I'd want to go back.

Re: Go 1.21 Release Candidate

#218

Post by anyoneamous »

morelisp wrote: post #206
anyoneamous wrote: post #199

Earlier quoted context omitted.

Just the standard "logging" - might not meet the definition of "structured logging", but at a glance it seems about as featureful as what is being added to Go right now.

Python has no equivalent of logger.With or other k/v pairs, which is what makes it structured logging and why it's interesting at all. Go has had unstructured logging since its early days.

I don't really follow what the benefit of the k/v thing is relative to just passing in a suitable string. I'd just assumed that the automation of "debug", "info" etc was what made it structured.

Re: Go 1.21 Release Candidate

#219

Post by saghm »

arp242 wrote: post #144
saghm wrote: post #121

Earlier quoted context omitted.

That _is_ removing all the items from it; my point is that if you pass a map with `n` entries to clear, you end up with a map with 0 entries. If you do the same with a slice with `n` elements, I'd imagine most people would expect to end up with a slice with 0 elements, but instead you have a slice with `n` copies of the zero value.

But it's not "removing items", at least not for all meanings of the word "removing". You can see this with something like: s := []string{"hello", "world", "foo", "bar"} fmt.Println(s) // [hello world foo bar] s = s[:0] fmt.Println(s) // [] s = append(s, "XXX") s = s[:2] fmt.Println(s) // [XXX world] Which will print back "XXX world" because it's using the same array, and nothing was ever "deleted": only the slice's l…

Okay, yeah, that definitely isn't what I expected. It's pretty wild to me that `s = s[:2]` will ever work fine if `len(s) == 1`; I would have assumed that it would always be the same regardless of how the slice was created. Playing around with it, it seems like this means that if you pass a subslice to a function, that function can get access to things from the entire slice, including the portions that weren't in the slice passed in[1]!

I think I understand now why `clear` can't work on slices the way I think it should, but only because slices themselves don't work the way I feel even stronger that they should.

[1]: https://play.golang.com/p/fYrGUbCePuD

Re: Go 1.21 Release Candidate

#220

Post by panzi »

doctor_eval wrote: post #179
panzi wrote: post #113

Earlier quoted context omitted.

I don't actually use Go, but I have used many other languages where it is like the old behavior. I learned once that I have to build the closure correctly to get the value I want and know now to do it. Don't have any statistics on whether I made that mistake again, but anecdotally I can't remember a case where I have. In their analysis they have found a lot of cases with that mistake, though. So I guess fair enough.…

It's hardly standard behaviour. I mean in Java for example there didn't used to be value types, so everything was a pointer and the effect of this would be the same as the new behaviour in Go. The only lesson to be learned here is that languages are different. But I think the new Go behaviour is more ergonomic.

In Java you can only close over final variables, so you can't close over the loop variable at all. (Unless that changed since last time I used Java, which - granted - was a long time ago.)
Post reply on HN