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

71–80 of 236 posts

Re: Go 1.21 Release Candidate

#71

Post by alex_lav »

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

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

Slowly walking back dogmatic positions is just how the Go team works.

I say this as a person that wrote Go full time for a handful of years.

Re: Go 1.21 Release Candidate

#72

Post by pjmlp »

WhereIsTheTruth wrote: post #51

> 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

For anyone that misses their Objective-C days.

Re: Go 1.21 Release Candidate

#74

Post by bananapub »

WhereIsTheTruth wrote: post #60
philosopher1234 wrote: post #53

Earlier quoted context omitted.

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

if you have so few tests and so little code review that this matters then I am not sure what to suggest

Re: Go 1.21 Release Candidate

#75

Post by vito »

WhereIsTheTruth wrote: post #60
philosopher1234 wrote: post #53

Earlier quoted context omitted.

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

The compiler will tell you if the types aren't compatible, and this is only for primitive comparable types. What `min()` implementation could you have that even does something different?

Re: Go 1.21 Release Candidate

#76

Post by nasretdinov »

kkirsche wrote: post #66
nasretdinov wrote: post #64

I am honestly surprised nobody mentioned the intention of Go team to make multipath TCP the default in later releases

Can you elaborate on why this is surprising for those who don’t fully understand the differences?

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 datacenter environment (e.g. potentially higher CPU usage, etc).

Re: Go 1.21 Release Candidate

#77

Post by Chiron1991 »

WhereIsTheTruth wrote: post #60
philosopher1234 wrote: post #53

Earlier quoted context omitted.

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

Not too familiar with go toolchains, but I bet there's a linter that will warn you about shadowing builtins.

Re: Go 1.21 Release Candidate

#79

Post by arp242 »

nasretdinov wrote: post #76
kkirsche wrote: post #66

Earlier quoted context omitted.

Can you elaborate on why this is surprising for those who don’t fully understand the differences?

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.

Re: Go 1.21 Release Candidate

#80

Post by xh-dude »

panzi wrote: post #33

Wait is this now heap allocating a value in every iteration of every loop? I hope that allocation is optimized out in every case where there isn't a closure over the loop variable?

Generally it is optimized out.

The fine details resemble the analysis of correctness - all the evidence shows people expect per-iteration semantics with considerable frequency, and don’t rely on per-loop semantics with measurable frequency. But it’s impossible to completely automate that assessment. Likewise, it’s impossible to automatically detect code that will spuriously allocate because of the semantic transition.

Post reply on HN