Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.17 Release Notes

golang.org

Post reply on HN
Print view View original

161–170 of 222 posts

Re: Go 1.17 Release Notes

#161

Post by nemetroid »

pjmlp wrote: post #159
deathanatos wrote: post #148

Earlier quoted context omitted.

defer (/using/with) all require the programmer to remember, and write, O(use site) times, the code to release the resource. RAII destructors, on the other hand, do not permit the coder (at the use site of the type) to forget, as the destructor is invoked automatically when the variable goes out of scope. In my time reviewing Python (also GC, "with" provides a similar functionality), this is a very common error.

Apparently you missed my go vet reference on purpose, just make all of us aware of it not being the same. Same applies to using on .NET, where forgetting to call using on an IDisposable type can trigger a compiler error, via Roslyn plugins. Also seem to be unaware how closure based RAII works on FP languages. RAII isn't triggered on heap allocated objects unless smart pointers are used everywhere. Python doesn't have…

> RAII isn't triggered on heap allocated objects unless smart pointers are used everywhere.

It's triggered unless you have memory leaks.

Re: Go 1.17 Release Notes

#162

Post by yakubin »

kccqzy wrote: post #114
yakubin wrote: post #89

Earlier quoted context omitted.

In C++, preprocessor and template magic in dependencies tends to break such IDE convenience features as "go to definition" or "find all references".

This almost doesn't happen when your tools are good. At Google the Kythe tool ( https://kythe.io ) gracefully deals with templates, macros, and much more. Both "go to definition" and "find references" just work with 99.9% of C++ code, including within complicated macros and templates. (The one and only case I've ever found it doesn't work is to find references to a function that's only called via ADL in a widely used…

What about SFINAE?

Re: Go 1.17 Release Notes

#163

Post by maccard »

pxue wrote: post #35

The go code I wrote in 2015 looks and works exactly the same way new Go code I'm writing today. Even with all the upgrades. You have no idea how amazing that feels.

The C++ I wrote in 2013 still looks and works the same as it did 8 years ago, and I can write code in the same way, or opt in to newer features in C++14/17 too. The C++ code that I wrote in 2007 (when I started writing C++) also still works.

Re: Go 1.17 Release Notes

#164

Post by maccard »

theshrike79 wrote: post #132
systemvoltage wrote: post #128

Earlier quoted context omitted.

Not a GO dev, has the debugging experience improved?

Dunno, 20 years in the business and I still debug with print statements. It's enough in 95% of cases and it works every time in every environment. In the time it takes me to get a debugger running and attached to a process, I've print-debugged it and fixed it already =)

> In the time it takes me to get a debugger running and attached to a process,

In any modern editor or IDE, getting a debugger running and attached to a process usually amounts to opening a folder, adding a breakpoint and pressing F5

Re: Go 1.17 Release Notes

#165

Post by vp8989 »

Xenograph wrote: post #112
vp8989 wrote: post #84

Earlier quoted context omitted.

GC is quite problematic for web servers too. Lots of people "solve" that by giving AWS more money.

Why is GC problematic for web servers?

Because GC will pause threads while requests are being served, this leads to latency spikes at the higher percentiles.

It introduces a whole distinct type of complexity into operating the server.

The latency of a request to your server is not just caused by the code that is ran to serve that request (which is how people intuitively would think about it), it can be caused by GC pauses that are happening because of the memory pressure caused by previous requests.

Re: Go 1.17 Release Notes

#166

Post by tialaramex »

pjmlp wrote: post #120
tialaramex wrote: post #92

Earlier quoted context omitted.

> but there is still a big productivity gap between the borrow checker and GC. The borrow checker and GC aren't really doing the same thing though. One very important distinction in some fields (but unimportant in others) is that GC only really cares about memory resources. So you are (or should be) doing explicit manual cleanup for all non-memory resources in a GC language. Rust isn't, in Rust we don't write explici…

That is a misconception, RAII like code can be achieved in two ways: - defer (possibly add a go vet check for when missing it) - when Go 1.18 brings generics, the withFunc pattern from FP where lambdas get given a resource released on function exist, thus having regions/arena like resource management

The description for go vet says, "it should be used as guidance only". Go vet is in fact a linter (go lint is also a linter, but one focused on style).

So what you're doing there is adding a control to try to mitigate the consequences of a language failing. Go doesn't actually prevent you from getting this wrong, but a linter such as go vet can flag cases where it suspects you screwed up, and maybe you'll catch the worst mistakes most of the time this way and by having usage conventions.

We shouldn't mistake this for equivalent capability. The complicated cases that tempt people to ignore or switch off such linting are exactly the cases most likely to have an undetected problem.

So this is "RAII like" only in the sense that "Just remember to do it properly" is RAII like, and we could make exactly the same claim for C.

Re: Go 1.17 Release Notes

#167

Post by vp8989 »

theshrike79 wrote: post #130
vp8989 wrote: post #84

Earlier quoted context omitted.

GC is quite problematic for web servers too. Lots of people "solve" that by giving AWS more money.

Web server workers, by definition, don't run for extended periods. Making them the perfect candidate for GC languages. 1) Get request 2) Serve request 3) Get GC'd No memory issues.

Serving web requests with ephemeral workers introduces some new problems though. Generally efficiency in this space comes from pooling, reusing connections, multiplexing etc ...

Ie. amortize expensive work over many requests.

Re: Go 1.17 Release Notes

#168

Post by throwaway894345 »

zozbot234 wrote: post #136
tptacek wrote: post #106

Earlier quoted context omitted.

Rust is very expressive, but it also makes some tasks that are relatively simple in other languages much harder (anything involving tree structures, for instance), and some of what it gives you expressive control over is stuff you usually don't need to think about at all in other languages. Rust can do some things Go simply isn't suited for right now; for instance, there is no way we're getting kernel Go in the fores…

> Rust is very expressive, but it also makes some tasks that are relatively simple in other languages much harder (anything involving tree structures, for instance) Much harder, not really. Rust lets you add mutability, reference counting and thread safety to your data structures, you just need to know when to use these features. Yes, Go has fully general GC but very few problem domains have a real need for general G…

> Yes, Go has fully general GC but very few problem domains have a real need for general GC.

No, no one needs a GC, but many problem domains need productivity, and GC is the most productive way to manage memory to date. As previously mentioned, Rust has made truly impressive strides in improving productivity of borrow-checking, but it still remains quite far behind GC.

Re: Go 1.17 Release Notes

#169

Post by throwaway894345 »

josephg wrote: post #149
silisili wrote: post #101

Earlier quoted context omitted.

IMO, Go is the easiest language to read by far. Python can be, but lets one use a lot of hard to figure out magic. Go is very much WYSIWYG, and to me that's its greatest strength. It's easy for anyone to jump in about anywhere. And that lends itself well to teamwork.

I find that's only true so long as the problem you're solving fits well into Go's view of the world. If you want to make a data structure holding the equivalent of a parametric enum (or tagged union from C), go is very awkward to use compared with richer languages like Swift or Rust. Go is also awkward if you want to implement custom generic data structures. Eg, this[1] code I wrote a couple years ago for doing text…

I agree that enums are the thing that Go is lacking. I would really like first-class enums perhaps even more than generics. Hopefully we get them.

Re: Go 1.17 Release Notes

#170

Post by throwaway894345 »

tialaramex wrote: post #92
throwaway894345 wrote: post #48

Earlier quoted context omitted.

I really like Rust, but in my mind it's still relegated to the periphery of tasks that must be super fast (like C/C++, to your point) and/or low-level. Rust has made impressive strides at reducing the toil involved in compile-time memory management, but there is still a big productivity gap between the borrow checker and GC. Frankly, people are making boatloads of money off of software written in Python and JS--langu…

> but there is still a big productivity gap between the borrow checker and GC. The borrow checker and GC aren't really doing the same thing though. One very important distinction in some fields (but unimportant in others) is that GC only really cares about memory resources. So you are (or should be) doing explicit manual cleanup for all non-memory resources in a GC language. Rust isn't, in Rust we don't write explici…

Agreed, but per my original post, the additional safety that Rust affords protects against a very small share of bugs in SaaS applications. The value proposition isn’t good because you trade so much productivity for a small improvement in quality, and productivity is at a premium and quality (sadly) can be mitigated in other, less costly ways (e.g., progressively rolling out new changes, continuous deployment i.e., bugs can be patched in hours rather than months, etc).
Post reply on HN