Please add "RC1" to post title. Currently it's misleading than a stable release is here.
Go 1.21 Release Candidate
151–160 of 236 posts
Re: Go 1.21 Release Candidate
#152Re: Go 1.21 Release Candidate
#153Worth noting that the release announcement was written by Eli Bendersky, of https://eli.thegreenplace.net/ fame. It's a fantastic technical blog with literally decades of content.
Re: Go 1.21 Release Candidate
#154A good first step for better WASM support, however it's currently incompatible with tinygo's WASM target. For example, I'm working on a custom WASM host (non-browser) and have a tinygo WASM package with import bindings like this: //go:wasm-module rex //export wait_for_event func wait_for_event(timeout_usec uint32, o_event *uint32) bool Both these comment directives are tinygo-specific of course, and now Go has added…
The type conversion will improve in new releases. FYI recent TinyGo releases supports go:wasmimport too. The desire is definitely to allow users to use either or at least easily migrate. Thank you for trying it out!
Re: Go 1.21 Release Candidate
#155Overall, a release more for engineering than language. Even the new API's are mainly optimizations, and optimizations are netting ~10% (pretty good for an mature toolset). The WASI preview shows Google is committing engineering resources to WASM, which could grow the community a touch.
FWIW the WASI support is 99% a community contribution, so unfortunately it's not much of an indicator of Google's commitment.
Re: Go 1.21 Release Candidate
#156Earlier quoted context omitted.
Go slices are passed by value so there's no way for clear() to resize the underlying array without reassignment. I suppose it could have been x = clear(x) or clear(&x), but certainly if you understand Go semantics then seeing any function call do Foo(slice) already signals that the call can't modify the length since there's no return value.
This is a great example of why I dislike Go. It is not obvious that a slice is passed by value while a map is not or why. Therefore every action on it feels a bit weird because of that, and now you have functions like "clear" that take a very non-obvious action. Personally, I'd rather have pass-by-value return an error and only allow pass-by-reference (better: they should have had maps and slices be pointers). I'm no…
I agree the semantics seem weird, I've occasionally wanted the equivalent of x = clear(x) but I can't think of a time when I've wanted to set all the values to the zero value.
The bug doesn't seem to discuss use cases for it either. The most I could find is: https://github.com/golang/go/issues/56351#issuecomment-13326...
Which boils down to "doing what clear(slice) does cannot be implemented efficiently today" but I'm not sure how having an efficient way to do something folks don't want is useful?
There's already a memory clearing optimization in the compiler: https://github.com/golang/go/issues/19266
So yeah I'm not sure under what situations folks will use clear(slice).
Re: Go 1.21 Release Candidate
#157It 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.)?
One aspect of this is that it was formerly impossible to delete NaNs from a map[float64]T, unless you had the nan already.
Even with the NaN, the NaN wasn't equal to itself, so it still wouldn't delete. Really, they just should have forbidden float64 key'd maps, but too late for that, I guess.
Re: Go 1.21 Release Candidate
#158Earlier quoted context omitted.
> 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 s…
I have evidently been spoiled by Python and it's abundance of batteries.
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?
Re: Go 1.21 Release Candidate
#159The new experimental fix for loop variable capture [0] is huge; this is the biggest footgun with the language in my experience. I hope the experimental fix makes it into the next version of Go by default. [0] https://github.com/golang/go/wiki/LoopvarExperiment
Wow, that’s a blast from the past. Those code examples look exactly like the var to let changes in ES2015…
Re: Go 1.21 Release Candidate
#160Earlier quoted context omitted.
I'm a go user, and think it's dumb that: clear(f) fmt.Println(len(f)) will have different results if f is a slice and a map.
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…
> The slice in Go is more or less equivalent to &[] in Rust or std::span in C++.
Not really, because they are mutable, they can mutate the underlying memory, and they can re-allocate. They are a weird mix of &mut []/Vec or std::{span,vector}.
In contrast, a Rust &[] can may the underlying storage (if it's an &mut []), but cannot spin out a new storage on its own and start a new life without a backing structure – and I'm not utterly familiar with std::span, but I would wage the semantics are close.
Go slices can, which is why they are always tricky, especially for beginners. Not only does = not really do what is intuitively expected, not only every beginner will be bitten in the ass by forgetting the `x =` in `x = append(x, y)`, but it is impossible, when calling a function expecting a slice, to know if this function only wants a view on some memory or actually expect to modify it; a capital difference that is very clear in Rust or C++ type systems.