> New built-in functions: min, max and clear.
What a mistake.. reserved keywords are words I can no longer use for myself...
Zig does it better by requiring a prefix @ for most their builtin needs
Go 1.21 Release Candidate
51–60 of 236 posts
Re: Go 1.21 Release Candidate
#52I'm a bit surprised that the slog package was added to the stdlib, but it does seem to use the API that I think is the most ergonomic across libraries I saw in Go (specifically, varargs for key values, and the ability to create subloggers using .With), so I guess it's nice most of the community will standardize around it. If all goes well, you won't have different libraries using different loggers anymore, in some no…
I literally just updated all of my golang logging to use zerolog so i could get severity levels in my logs. Bad timing on my part! I guess ill re-do it all with slog, i prefer stdlib packages to third party packages.
ideally an slog handler is built for zerolog, so that you can use slog BE and keep the zerolog FE
Re: Go 1.21 Release Candidate
#53> New built-in functions: min, max and clear. What a mistake.. reserved keywords are words I can no longer use for myself... Zig does it better by requiring a prefix @ for most their builtin needs
They're not reserved keywords. Existing/package defined min/max functions would take precedence. They have the same semantics as `append`
Re: Go 1.21 Release Candidate
#54Why is map copy "dst, src" vs "src, dst"?
Copy operations in Go are normally destination first, source second. This includes builtins like copy() and library functions like io.Copy(). Making it "src, dest" would make this one case the opposite of all the others. Note that the order mimics variable assignment. You copy an integer with: var src, dest int dest = src // dest first, src second I appreciate the consistency.
Thanks, "mimics variable assignment" is a good way to remember it
Re: Go 1.21 Release Candidate
#55I'm a bit surprised that the slog package was added to the stdlib, but it does seem to use the API that I think is the most ergonomic across libraries I saw in Go (specifically, varargs for key values, and the ability to create subloggers using .With), so I guess it's nice most of the community will standardize around it. If all goes well, you won't have different libraries using different loggers anymore, in some no…
I literally just updated all of my golang logging to use zerolog so i could get severity levels in my logs. Bad timing on my part! I guess ill re-do it all with slog, i prefer stdlib packages to third party packages.
Tomorrow we will see a blog post titled “Why I always use 3rd part dependencies instead of stdlibs”
Re: Go 1.21 Release Candidate
#56It is interesting to see them add things like the "clear" function for maps and slices after suggesting to simply loop and delete each key one at a time for so long. Is this a result of the generics work that makes implementation easier vs. the extra work of making a new "magic" function (like "make", etc.)?
That `clear` on a slice sets all values to their type's zero value is going to be extremely confusing especially coming from other languages (Rust, C#, C++, Java, ...) where the same-named function is used on list-ish types to set their length to zero. Doubly-so when `clear` on a map actually seems to follow the convention of removing all contained elements.
C#’s array/span.Clear() does exactly the same - it zeroes them out.
Re: Go 1.21 Release Candidate
#57Earlier quoted context omitted.
That `clear` on a slice sets all values to their type's zero value is going to be extremely confusing especially coming from other languages (Rust, C#, C++, Java, ...) where the same-named function is used on list-ish types to set their length to zero. Doubly-so when `clear` on a map actually seems to follow the convention of removing all contained elements.
Sure, although as a Go user, the behavior described is exactly what I’d expect. These new functions are no different from functions that you could write yourself.
The builtin clear() will handle cases like deleting NaN from a map.
Re: Go 1.21 Release Candidate
#58Seems 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 sl…
> 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…
No, it was a recent discussion, here: https://github.com/golang/go/issues/59488
Re: Go 1.21 Release Candidate
#59I'm a bit surprised that the slog package was added to the stdlib, but it does seem to use the API that I think is the most ergonomic across libraries I saw in Go (specifically, varargs for key values, and the ability to create subloggers using .With), so I guess it's nice most of the community will standardize around it. If all goes well, you won't have different libraries using different loggers anymore, in some no…
I have mixed feelings about it. if nothing else, the name..."slog" isn't exactly the word i want repeating to myself as I'm working.
Re: Go 1.21 Release Candidate
#60> New built-in functions: min, max and clear. What a mistake.. reserved keywords are words I can no longer use for myself... Zig does it better by requiring a prefix @ for most their builtin needs
They're not reserved keywords. Existing/package defined min/max functions would take precedence. They have the same semantics as `append`
You refactored your code, you think you wrote your ``min`` function, but no, it'll call the builtin one, without warning you..
I don't like this design..