[philosopher1234]

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.

[saghm]

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]

You can't "remove all items from the slice"; you can only change the length to 0: "slice[:0]".

[saghm]

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]

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]

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

[arp242]

Slices in Go are a tad counter-intuitive, I agree, but the approach does make sense I think. It allows you to use "dynamic sized arrays" for most cases like you would in Python and not worry too much about the mechanics, at the price of some reduced performance, but in cases where this kind of performance does matter it allows you to be precise about allocations and array sizes. So you kind of get the best of both.

Anyhow, this explains it in detail, if you're not already familiar with it: https://go.dev/blog/slices-intro

[esprehn]

clear couldn't allocate a new array unless it was s = clear(s) like append. Maybe that would have been better semantics though.

[ilyt]

> 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]

No, it was a recent discussion, here: https://github.com/golang/go/issues/59488

[tomjakubowski]

You mean samber/lo? What is nonsensical about the name?

[anyoneamous]

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...

[ilyt]

> 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]

I have evidently been spoiled by Python and it's abundance of batteries.

[justinsaccount]

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]

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]

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.

[arp242]

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?

[tick_tock_tick]

> that seems like an absolutely basic language feature

Most languages have no logging "system" built in at all. Honestly it's really quite rare.

[sa46]

Most languages include unstructured logging libraries in the standard library, including Go. Structured logging is usually provided by third party libraries.

[metaltyphoon]

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