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

131–140 of 236 posts

Re: Go 1.21 Release Candidate

#131

Post by xh-dude »

JyB wrote: post #37
showdeddd wrote: post #19

I wonder if the new stdlib logger is featured enough to get rid of logrus/zerolog.

I'm wondering the same. Anyone already played for some time with the pkg?

There’s been an emphasis in slog on Handler composition over directly implementing a ton of features. Personally I love it - there are things I’ve needed, that slog can do, that few other loggers make easy/possible.

Zerolog will still be relevant for raw performance (slog is close to zap on perf - doesn’t win benchmarks, doesn’t look out of place either), fewer really need it but some really do.

Re: Go 1.21 Release Candidate

#132

Post by jsd1982 »

A 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 its own third and different directive of course.

When I add Go's desired `//go:wasmimport rex wait_for_event` directive, it complains about the types `*uint32` and `bool` being unsupported. Tinygo supports these types just fine and does what is expected (converting the types to uint32). On the surface, I understand why Go complains about it, but it's such a trivial conversion to have the compiler convert them to `uint32` values without requiring the developer to use unsafe pointer conversion and other tricks.

Hopefully I can find a way to keep both tinyo and Go 1.21rc2 happy with the same codebase going forward and be able to switch between them to evaluate their different strengths and weaknesses.

Re: Go 1.21 Release Candidate

#133

Post by vl »

lokar wrote: post #130
onionisafruit wrote: post #122

Earlier quoted context omitted.

That bugs me too. I consider it a red flag for a library to log to anything except a ` log.Logger` passed in from the caller. Now I'll expand that to include a ` slog.Logger` as well. If the library is logging directly to stderr or stdout, that is a sign that it probably has other design issues as well.

Put the logger in the context

Isn't it considered bad practice?

Re: Go 1.21 Release Candidate

#134

Post by steveklabnik »

klodolph wrote: post #120
maccard wrote: post #116

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

My understanding is, to use the Rust/C++ term, slices in Go are owned, but they are not in Rust or C++. That is, they're a pointer + length in the latter two, but a pointer, length, and capacity in Go.

Re: Go 1.21 Release Candidate

#135

Post by throwawaygo »

racingmars wrote: post #101
throwawaygo wrote: post #81

So I guess with new builtin functions we will be breaking backwards compatibility?

If you already have your own functions or variables named max, min, or clear in-scope, they will shadow the new built-in functions and your code will continue to use your own version of the functions. No breakage to existing identifiers that match the new function names. (This is the same behavior as the append built-in function today, for example. These things in Go are _not_ reserved keywords, they are simply globa…

You’re right. Backwards unfriendly is maybe a better way to say it.

min and max are common variable names so depending on the version of go and the scope you should expect min and max to mean different things.

No reason these functions couldn’t have been part of the stdlib.

Re: Go 1.21 Release Candidate

#136

Post by tastysandwich »

Really glad to see some of these new packages (sort, map, etc) making use of generics. Should reduce the need for a lot of helper functions.

Also really excited to see loop capture variables finally getting sorted out. It is a constant pain point with new devs, and I have no good answer when they ask "but WHY is it like this?"

More information about loop capture here for those interested https://github.com/golang/go/discussions/56010

Re: Go 1.21 Release Candidate

#137

Post by [deleted] »

nu11ptr wrote: post #18

It 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.)?

[deleted]

Re: Go 1.21 Release Candidate

#138

Post by suessflorian »

Nice - but hang on a second, I thought you cannot shadow language keywords in Go. So projects bumping to 1.21 in the future should be aware that you will run into compile time errors all of a sudden… doesn’t that actually break the compatibility promise?

    max := something()
https://go.dev/doc/go1compat

Re: Go 1.21 Release Candidate

#139

Post by tedunangst »

suessflorian wrote: post #138

Nice - but hang on a second, I thought you cannot shadow language keywords in Go. So projects bumping to 1.21 in the future should be aware that you will run into compile time errors all of a sudden… doesn’t that actually break the compatibility promise? max := something() https://go.dev/doc/go1compat

Builtins aren't keywords.
Post reply on HN