6 ms·

Seems like a really substantial release to me. The new built in functions min, max, and clear are a bit surprising, even having followed the discussions around

Seems like a really substantial release to me. The new built in functions min, max, and clear are a bit surprising, even having followed the discussions around them. The perf improvements seem pretty great, I’m sure those will get much love here. Personally, I’m most excited about log/slog and the experimental fix to loop variable shadowing. I’ve never worked in a language with a sane logging ecosystem, so I think slog will be a bit personally revolutionary. And the loop fix will allow me to delete a whole region of my brain. Pretty nice.

anyoneamous 3y ago
As a non-developer who has only gone as far as "hello world" in Go, I'm baffled by the idea that the log/slog thing is new - that seems like an absolutely basic language feature. TBH I'd say the same about min/max, but could forgive those being absent since Go isn't known for being numerically-focused...
- tick_tock_tick 3y ago
  > that seems like an absolutely basic language feature Most languages have no logging "system" built in at all. Honestly it's really quite rare.
  - deleted 3y ago
    [deleted]
- ilyt 3y ago
  > As a non-developer who has only gone as far as "hello world" in Go, I'm baffled by the idea that the log/slog thing is new - that seems like an absolutely basic language feature. Then you'd be even more surprised when you learn that the vast majority of languages do not have standard logging library in core. Most have one or few common libraries that community developed instead, but they are not in stdlib, and if stdlib has one it's usually very simple one (Go had standard logger interface that was too simple for example)
  - anyoneamous 3y ago
    I have evidently been spoiled by Python and it's abundance of batteries.
    - justinsaccount 3y ago
      Python does not include a structure d logging package as part of the stdlib as far as I know. What package are you thinking does what slog does?
      - anyoneamous 3y ago
        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.
        morelisp 3y ago
        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.
        anyoneamous 3y ago
        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.
- arp242 3y ago
  There's been a "log" package since forever, but slog adds structured logging with fields and some other things. I don't think many standard libraries have that built in?
- sa46 3y ago
  Most languages include unstructured logging libraries in the standard library, including Go. Structured logging is usually provided by third party libraries.
  - metaltyphoon 3y ago
    The only other one I know would be C# with Microsoft.Extensions.Logging. Its so ubiquitous that 3rd party libraries work with its abstractions. Slog is a really good thing for Go
ilyt 3y ago
> The new built in functions min, max, and clear are a bit surprising, even having followed the discussions around them. Was that discussion pre-generics? Most of functions and libraries introduced in Go 1.21 is stuff people already put in community libraries (lodash being probably most popular, despise utterly nonsensical name not relating to anything it does) so it is just potentially cutting extra dependencies for many projects.
- philosopher1234 3y ago
  No, it was a recent discussion, here: https://github.com/golang/go/issues/59488 https://github.com/golang/go/issues/59488
- tomjakubowski 3y ago
  You mean samber/lo? What is nonsensical about the name?
saghm 3y ago
Am I reading it correctly that `clear` does different things for maps and slices? Why doesn't it remove all the items from the slice like it does with the map, or set the values in the map to the zero value like it does for slices? That seems like an easy thing to get tripped up on
- arp242 3y ago
  You can't "remove all items from the slice"; you can only change the length to 0: "slice[:0]".
  - saghm 3y ago
    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.
    - arp242 3y ago
      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 length was updated. This is why "delete(slice, n)" doesn't work and it only operates on maps. I suppose clear(slice) could allocate a new array, but that's not the same behaviour as clear(map) either, and doesn't really represent the common understanding of "clearing a slice". The only behaviour I can think of that vaguely matches what "clearing a slice" means is what it does now.
      - saghm 3y ago
        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 https://play.golang.com/p/fYrGUbCePuD

anyoneamous 3y ago

As a non-developer who has only gone as far as "hello world" in Go, I'm baffled by the idea that the log/slog thing is new - that seems like an absolutely basic language feature. TBH I'd say the same about min/max, but could forgive those being absent since Go isn't known for being numerically-focused...

tick_tock_tick 3y ago
> that seems like an absolutely basic language feature Most languages have no logging "system" built in at all. Honestly it's really quite rare.
- deleted 3y ago
  [deleted]
ilyt 3y ago
> As a non-developer who has only gone as far as "hello world" in Go, I'm baffled by the idea that the log/slog thing is new - that seems like an absolutely basic language feature. Then you'd be even more surprised when you learn that the vast majority of languages do not have standard logging library in core. Most have one or few common libraries that community developed instead, but they are not in stdlib, and if stdlib has one it's usually very simple one (Go had standard logger interface that was too simple for example)
- anyoneamous 3y ago
  I have evidently been spoiled by Python and it's abundance of batteries.
  - justinsaccount 3y ago
    Python does not include a structure d logging package as part of the stdlib as far as I know. What package are you thinking does what slog does?
    - anyoneamous 3y ago
      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.
      - morelisp 3y ago
        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.
        anyoneamous 3y ago
        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.
arp242 3y ago
There's been a "log" package since forever, but slog adds structured logging with fields and some other things. I don't think many standard libraries have that built in?
sa46 3y ago
Most languages include unstructured logging libraries in the standard library, including Go. Structured logging is usually provided by third party libraries.
- metaltyphoon 3y ago
  The only other one I know would be C# with Microsoft.Extensions.Logging. Its so ubiquitous that 3rd party libraries work with its abstractions. Slog is a really good thing for Go

ilyt 3y ago

> The new built in functions min, max, and clear are a bit surprising, even having followed the discussions around them. Was that discussion pre-generics? Most of functions and libraries introduced in Go 1.21 is stuff people already put in community libraries (lodash being probably most popular, despise utterly nonsensical name not relating to anything it does) so it is just potentially cutting extra dependencies for many projects.

philosopher1234 3y ago
No, it was a recent discussion, here: https://github.com/golang/go/issues/59488 https://github.com/golang/go/issues/59488
tomjakubowski 3y ago
You mean samber/lo? What is nonsensical about the name?

saghm 3y ago

Am I reading it correctly that `clear` does different things for maps and slices? Why doesn't it remove all the items from the slice like it does with the map, or set the values in the map to the zero value like it does for slices? That seems like an easy thing to get tripped up on

arp242 3y ago
You can't "remove all items from the slice"; you can only change the length to 0: "slice[:0]".
- saghm 3y ago
  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.
  - arp242 3y ago
    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 length was updated. This is why "delete(slice, n)" doesn't work and it only operates on maps. I suppose clear(slice) could allocate a new array, but that's not the same behaviour as clear(map) either, and doesn't really represent the common understanding of "clearing a slice". The only behaviour I can think of that vaguely matches what "clearing a slice" means is what it does now.
    - saghm 3y ago
      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 https://play.golang.com/p/fYrGUbCePuD