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

201–210 of 236 posts

Re: Go 1.21 Release Candidate

#201

Post by binwiederhier »

cyode wrote: post #194
physicles wrote: post #173

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

I don't think there necessarily is a default production webserver setup. People use different routers or frameworks, or go bare bones because they can.

You asked for an example, and here is one. This is my side project "ntfy", which runs a web app and API and handles hundreds of thousands of requests a day and thousands of constantly active socket connections. It uses no router framework, and has a modified (enhanced version of the http.HandlerFunc) that can return errors. It also implements a errHTTP error type that allows handler functions to return specific http error codes with log context and error message.

It is far from the most elegant, but to me Go is not about elegance, it's about getting things done.

https://github.com/binwiederhier/ntfy/blob/main/server/serve...

The server runs on https://ntfy.sh, so you can try it out live.

Re: Go 1.21 Release Candidate

#202

Post by klodolph »

shakow wrote: post #196
klodolph wrote: post #166

Earlier quoted context omitted.

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…

> Technically, their only solid common point is that they address contiguous spaces in memory.

That’s a very major thing to have in common. Definitely not a minor detail, for sure.

Re: Go 1.21 Release Candidate

#203

Post by binwiederhier »

esprehn wrote: post #146
maximilianburke wrote: post #28

Earlier quoted context omitted.

That `clear` on a slice sets all values to their type's zero value is going to be extremely confusing especially coming from other languages (Rust, C#, C++, Java, ...) where the same-named function is used on list-ish types to set their length to zero. Doubly-so when `clear` on a map actually seems to follow the convention of removing all contained elements.

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.

That's actually a great explanation of why it's not easy to implement the clear function the way it makes sense for slices. However, this is a built-in, not a normal function, so they could make it do whatever they like, including doing the intuitive and desired thing, no? It seems to me that they've just created another "loop variable gotcha" type situation...

Re: Go 1.21 Release Candidate

#204

Post by dr2chase »

collinvandyck76 wrote: post #43
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?

I didn't see this optimization when I read the overview. I also hope that the compiler is smart enough to avoid this.

The way to view it is "unless there is syntactic sharing, it is a for loop, same as before". The compiler uses a syntactic test (with little knowledge of control flow or value use) to exclude loops from the change. This excludes most loops.

After the change, escape analysis figures out if the changed iteration variable actually needs heap allocation; in an internal sample of code that was actually buggy (i.e., biased, guaranteed to have at least one loop like this) for 5/6 of the loops escape analysis decided that heap allocation wasn't needed.

The reason this optimization isn't part of the language change proposal is that escape analysis is "behind the curtain"; ignoring performance, a program should behave the same with or without it, and it is removing heap allocations all over the place already. Escape analysis is also extremely difficult to explain exactly, so you would not want it in the spec, and "make escape analysis better" (that is, change it) is one of the prominent items in the bag of things to do for Go.

Re: Go 1.21 Release Candidate

#205

Post by shakow »

klodolph wrote: post #202
shakow wrote: post #196

Earlier quoted context omitted.

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

> Technically, their only solid common point is that they address contiguous spaces in memory. That’s a very major thing to have in common. Definitely not a minor detail, for sure.

When you're comparing two cars, the fact that both have four wheels and drive on a road is not that compelling.

Re: Go 1.21 Release Candidate

#206

Post by morelisp »

anyoneamous wrote: post #199
justinsaccount wrote: post #158

Earlier quoted context omitted.

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.

Python has no equivalent of logger.With or other k/v pairs, which is what makes it structured logging and why it's interesting at all. Go has had unstructured logging since its early days.

Re: Go 1.21 Release Candidate

#207

Post by preseinger »

euroderf wrote: post #195
preseinger wrote: post #149

Earlier quoted context omitted.

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.

huh? there's no dogma involved here, it's just an observation of the properties of the type

a context is created with each request, and destroyed at the end of it

and values stored in a context are accessible only through un-typed, runtime-fallible methods -- not something you want to lean on, if you can avoid it

Re: Go 1.21 Release Candidate

#208

Post by klodolph »

shakow wrote: post #205
klodolph wrote: post #202

Earlier quoted context omitted.

> Technically, their only solid common point is that they address contiguous spaces in memory. That’s a very major thing to have in common. Definitely not a minor detail, for sure.

When you're comparing two cars, the fact that both have four wheels and drive on a road is not that compelling.

In this scenario, we are comparing two cars, a bicycle, a jet ski, and three types of airplane. Yes, the cars are similar, within that context. Many languages, like Python and Java, do not have an array slice type. And the similarities between C++, Rust, and Go are relevant—the length is a property of the slice itself, and since the slice is passed by value, it is not modified by a function that accepts a slice as an argument, even if the objects the slice point to are modified by that function.

If you see a different context, then you misinterpreted what I wrote.

It is easy—trivial, even—to imagine scenarios where a particular “X is like Y” does not make sense. What you should do, as a reader, is try and understand what the writer means, rather than try to figure out some way to interpret a comment so that it is wrong, in your view.

The easy way out—saying “X is not like Y because of difference Z”—does not meaningfully contribute to the discussion.

Re: Go 1.21 Release Candidate

#209

Post by stouset »

yencabulator wrote: post #171
alex_lav wrote: post #71

Earlier quoted context omitted.

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

No, it's because a use case was discovered that the for loop approach can't handle: NaN keys.

In my experience, that's exactly how this plays out every single time.

    Dev: Can we have a function to clear a map?
    
    Go: No, it's easy enough to write the 5 lines of code to just do it yourself every time.
    
    Dev: Okay, I don't see why I should have to write those 5 lines every time but fine. Isn't looping over everything going to be slower than just… having a function that can empty the internals?

    Go: We've implemented a compiler optimization to detect this and rewrite it to the faster code it would have been if it we were to implement it.

    Dev: Isn't that… way harder than just writing the method? Anyway, I noticed this solution doesn't actually always work because of this edge case.
    
    Go: Just handle the edge case every time then.

    Dev: That's the point. I can't.
And around and around we go.

Re: Go 1.21 Release Candidate

#210

Post by garfij »

throwawaygo wrote: post #88
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

breaks all my variables named min and max

Not at all https://play.golang.com/p/c5tGTMamjj_a
Post reply on HN