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

121–130 of 236 posts

Re: Go 1.21 Release Candidate

#121

Post by saghm »

arp242 wrote: post #39
saghm wrote: post #21

Earlier quoted context omitted.

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

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

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.

Re: Go 1.21 Release Candidate

#122

Post by onionisafruit »

mdaniel wrote: post #115
onionisafruit wrote: post #107

Earlier quoted context omitted.

Indeed it's in "golang.org/x/exp/slog"

https://pkg.go.dev/golang.org/x/exp/slog#hdr-Levels seems to fall into the same trap that drives me _starkraving_ about the 18,000 different(!) golang logging packages: there doesn't seem to be a sane way of influencing the log level at runtime if the author doesn't have the foresight/compassion to add a command-line flag or env-var to influence it. A similar complaint about the "haha I log json except this other dep…

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.

Re: Go 1.21 Release Candidate

#123

Post by Patrickmi »

ubavic wrote: post #12

I enjoy Go so much. It is almost perfect language for getting things done, but I still can't understand some design choices. Does someone knows why Go uses env variables (like GOOS and GOARCH) instead command line arguments?

As a PL focused on building networking services across different arch and platforms if it was any different that’ll be the first thing to hate in go

Re: Go 1.21 Release Candidate

#124

Post by onionisafruit »

klodolph wrote: post #119
Hakkin wrote: post #63

Earlier quoted context omitted.

That doesn't seem to be true, unless I'm misunderstanding something. https://go.dev/play/p/ymM0tD3aGYg?v=gotip Obviously these sample functions don't take into account all the intricacies of float min/max functions.

You can const x = min(a, b) assuming a and b are const.

I can't think of a use case for that. If all the inputs are consts, then you know the values and can just assign it to be the less of a or b. Am I missing something here?

Re: Go 1.21 Release Candidate

#125

Post by Patrickmi »

benhoyt wrote: post #114
29_29 wrote: post #2

This is a big release. Lots of new packages. The language is changing

It is a big release, and the number of new stdlib packages (4) is relatively high for a Go release. That said, apart from the addition of some minor builtins (min, max, clear), the language isn't changing. That happened back in 1.18 with the introduction of generics.

Go releases feels it’s has changed massively when reading the release notes but when coding it’s just like every other day

Re: Go 1.21 Release Candidate

#126

Post by Hakkin »

tinco wrote: post #91
Hakkin wrote: post #9

Huh, I'm glad to see generic Min/Max functions, but the fact that they're built-ins is a little odd to me. I would have expected them to put a generic math library into the stdlib instead. The fact the stdlib math package only works with float64s has always struck me as a poorly thought out decision.

What sort of use case do you see for non-float64 math operations in a Go application?

Well, the obvious ones are of course Min and Max functions, which is resolved with this. Other ones I commonly find myself wanting to use with integers would be math.Abs and math.Pow I guess. Otherwise they are mostly functions useful with floats, so ultimately I understand the logic, though even in that case, it would be nice if they were usable with float32s as well without casting back and forth.

Personally I try to avoid using floats for calculations if I can (unless it's obviously warranted), I've encountered far too many foot guns from using them, though honestly the same can be said about integers in some situations too. I wish there was a package like math/big that was more accessible, I find the current interface for it pretty abysmal.

Re: Go 1.21 Release Candidate

#127

Post by nordsieck »

onionisafruit wrote: post #124
klodolph wrote: post #119

Earlier quoted context omitted.

You can const x = min(a, b) assuming a and b are const.

I can't think of a use case for that. If all the inputs are consts, then you know the values and can just assign it to be the less of a or b. Am I missing something here?

> I can't think of a use case for that.

It helps to document intent.

Probably not so useful for min, but it can be more useful for more complex functions.

Re: Go 1.21 Release Candidate

#128

Post by [deleted] »

tick_tock_tick wrote: post #8
anyoneamous wrote: post #7

Earlier 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. TBH I'd say the same about min/max, but could forgive those being absent since Go isn't known for being numerically-focused...

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

Re: Go 1.21 Release Candidate

#129

Post by Patrickmi »

arp242 wrote: post #79
nasretdinov wrote: post #76

Earlier quoted context omitted.

I don't think Multipath TCP has been tested in enough environments to become the default yet. It's compatible with TCP, yes, but it's mostly useful for e.g. mobile devices that have multiple links like Wi-Fi and 4G, and it lets users to maintain TCP connection to a certain service even when moving across networks. Go seems to be server-oriented first, and there are some potential downsides to multipath TCP in a datac…

"In a future Go release we may enable Multipath TCP by default on systems that support it." This could be five years from now. Or maybe never.

From what I heard the reason for not defaulting, its not yet acceptable across different platforms esp windows and most who’ll need this are data centers 5 years its too long, since linux kernel has accepted mptcp

Re: Go 1.21 Release Candidate

#130

Post by lokar »

onionisafruit wrote: post #122
mdaniel wrote: post #115

Earlier quoted context omitted.

https://pkg.go.dev/golang.org/x/exp/slog#hdr-Levels seems to fall into the same trap that drives me _starkraving_ about the 18,000 different(!) golang logging packages: there doesn't seem to be a sane way of influencing the log level at runtime if the author doesn't have the foresight/compassion to add a command-line flag or env-var to influence it. A similar complaint about the "haha I log json except this other dep…

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
Post reply on HN