Live data from Hacker News

Go 1.21 Release Candidate

go.dev

191–200 of 236 posts

Re: Go 1.21 Release Candidate

#191

This is at least the biggest release since 1.18 with generics, possibly bigger. I’m excited because the changes demonstrate a transition from the traditional go philosophy of almost fanatical minimalism, to a more utilitarian approach. Loop variable capture is a foot-gun that in the last six years has cost me about 10-20 hours of my life. So happy to see that go. (Next on my list of foot-guns would be the default inf…

Even Java and Python have default network timeouts. I don't know why that's the case though. https://ashishb.net/all/infinite-network-timeouts-in-java-an...

The popular Python “requests” HTTP library doesn’t have a default timeout. There’s a 2015 GitHub issue asking for a default timeout, if even an opt-in environment variable to avoid breaking API compatibility. There’s a lot of comments on the issue, but no commitment to implement or close as “won’t fix”.

https://github.com/psf/requests/issues/3070

Re: Go 1.21 Release Candidate

#192
post #62
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.

The proposal[0] gives a rationale. Using builtin functions lets them be variadic without allocating a slice. [0] https://github.com/golang/go/issues/59488

While I suspect open coding may make the optimization a little easier, there's no reason it couldn't optimize out a slice and fixed 2-3 iteration loop with the same result.

The proposal's real conclusion was "the decision cannot be resolved by empirical data or technical arguments."

Re: Go 1.21 Release Candidate

#193

This is at least the biggest release since 1.18 with generics, possibly bigger. I’m excited because the changes demonstrate a transition from the traditional go philosophy of almost fanatical minimalism, to a more utilitarian approach. Loop variable capture is a foot-gun that in the last six years has cost me about 10-20 hours of my life. So happy to see that go. (Next on my list of foot-guns would be the default inf…

> This is at least the biggest release since 1.18 with generics, possibly bigger.

> the changes demonstrate a transition from the traditional go philosophy of almost fanatical minimalism, to a more utilitarian approach.

This change demonstrate that "to stay as a mainstream" programming language, you can't preach minimalism , has to adopt utilitarian approach.

Re: Go 1.21 Release Candidate

#194

This is at least the biggest release since 1.18 with generics, possibly bigger. I’m excited because the changes demonstrate a transition from the traditional go philosophy of almost fanatical minimalism, to a more utilitarian approach. Loop variable capture is a foot-gun that in the last six years has cost me about 10-20 hours of my life. So happy to see that go. (Next on my list of foot-guns would be the default inf…

> An http server that doesn’t force you to write huge amounts of boilerplate?

I just started my first Go tutorials this week. One of them was go.dev's Writing Web Applications [0]. I was actually struck by the lack of boilerplate (compared to frameworks I've used in Java/Python/etc.) involved.

I get that it's a toy example, but do you know of any better write-ups on what a production Go web server in industry looks like?

[0] https://go.dev/doc/articles/wiki/

Re: Go 1.21 Release Candidate

#195
post #133

Earlier quoted context omitted.

Isn't it considered bad practice?

yes, in general the context stores request-scoped data, whether or not the logger is a request-scoped value is a grey area and to reply to sibling comment, opentelemetry is basically a house of antipatterns, definitely do not look to it for guidance

"The context stores request-scoped data" might be another Go-team dogma due for course correction RSN.

Re: Go 1.21 Release Candidate

#196
post #160

Earlier quoted context omitted.

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

To be honest I kinda hate the reply to “X is like Y” comment when someone says “X is not like Y because of difference Z”. It's just… so pedantic. The whole reason we say “X is like Y” instead of “X is the same as Y” is because X is not the same as Y. I’m just really tired of seeing this response on HN over and over. I was pretty damn explicit when I said “more or less” and you’re here to argue about whether it is leg…

> The whole reason we say “X is like Y” instead of “X is the same as Y” is because X is not the same as Y

Being able to change the underlying data is a pretty big difference. Technically, their only solid common point is that they address contiguous spaces in memory.

> you cite C++ as some kind of gold standard

I never did; I highlighted the difference between immutable views vs. whatever Go slices are.

> I think you’ve lost the plot

No need for the snark there.

Re: Go 1.21 Release Candidate

#197

This is at least the biggest release since 1.18 with generics, possibly bigger. I’m excited because the changes demonstrate a transition from the traditional go philosophy of almost fanatical minimalism, to a more utilitarian approach. Loop variable capture is a foot-gun that in the last six years has cost me about 10-20 hours of my life. So happy to see that go. (Next on my list of foot-guns would be the default inf…

Even Java and Python have default network timeouts. I don't know why that's the case though. https://ashishb.net/all/infinite-network-timeouts-in-java-an...

Typo: I meant no default network timeouts :/

Re: Go 1.21 Release Candidate

#198

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…

Every language has sharp edges, but go's whole MO is to avoid rabid footguns at the expense of verbosity (IMO). The for-shadow issue thats fixed this release is a great example of go deciding to do the intuitive thing rather than the "correct" thing because that's how people work.

I don't think the implementation details matter to a user of a map or a slice (or an array for that matter) - they're language builtins (as opposed to span, vector and map in c++ which are library types).

Re: Go 1.21 Release Candidate

#199

Earlier quoted context omitted.

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?

Just the standard "logging" - might not meet the definition of "structured logging", but at a glance it seems about as featureful as what is being added to Go right now.
Post reply on HN