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

111–120 of 222 posts

Re: Go 1.17 Release Notes

#111

Post by throwaway34241 »

sagichmal wrote: post #109
throwaway34241 wrote: post #99

Earlier quoted context omitted.

> Go doesn't even bother providing a means to do this automatically for your non-memory resources when they're garbage collected (Java does, but again, no promises it ever fires, so, don't rely on this). It sounds like you are talking about finalizers? If so, they exist in Go in a similar way to the Java feature [1]. [1] https://pkg.go.dev/runtime#SetFinalizer

Finalizers are not guaranteed to run. They're not ersatz destructors.

Yes, if you look at the quote I was responding to, it appears they are saying Go doesn't have finalizers, which is incorrect.

Re: Go 1.17 Release Notes

#112

Post by Xenograph »

vp8989 wrote: post #84
zarzavat wrote: post #67

Earlier quoted context omitted.

Go is a replacement for a certain subset of C/C++ projects that are I/O heavy, e.g. web servers. However the GC precludes it from many uses of C/C++, e.g. you couldn't write an AAA game in it, or a kernel, or a toaster.

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?

Re: Go 1.17 Release Notes

#113

Post by beltsazar »

throwaway34241 wrote: post #99
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…

> Go doesn't even bother providing a means to do this automatically for your non-memory resources when they're garbage collected (Java does, but again, no promises it ever fires, so, don't rely on this). It sounds like you are talking about finalizers? If so, they exist in Go in a similar way to the Java feature [1]. [1] https://pkg.go.dev/runtime#SetFinalizer

You usually want to release non-memory resources deterministically, but finalizers in C#/Java/Go are not deterministic. That's why finalizers usually are not used for resource management. Instead, C# has using statements, Java try-with-resources, Go defer statements.

Re: Go 1.17 Release Notes

#114

Post by kccqzy »

yakubin wrote: post #89
initplus wrote: post #47

Earlier quoted context omitted.

If you use C++ tools where your dependencies get pulled in and built from source like Go does, you get the same experience. If you only have prebuilt system libraries obviously this doesn't work. It's not like Go's tooling is that much better than the best modern C++ tools, but the ecosystem is so much more unified by having 1 blessed set of tooling. Rather than 20 different package managers/(meta)build systems. No n…

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 template that's instantiated with thousands of different types.)

Re: Go 1.17 Release Notes

#115

Post by Scaevolus »

benhoyt wrote: post #46
benhoyt wrote: post #29

To me, the most interesting change is the performance improvement due to the new register-based calling convention. Your CPU-bound programs will magically get 5% faster when compiled with 1.17: > Go 1.17 implements a new way of passing function arguments and results using registers instead of the stack. Benchmarks for a representative set of Go packages and programs show performance improvements of about 5%, and a ty…

Wow, this update is awesome: my GoAWK interpreter ( https://github.com/benhoyt/goawk ) runs a simple CPU-bound AWK program 38% faster when compiled with Go 1.17 (compared to 1.16). $ time goawk_go1.16 'BEGIN { for (i=0; i I wonder why it's so much better than their advertised 5% perf improvement? Here's a quick CPU profile: https://i.imgur.com/csJyOYq.png ... I don't get too much out of it at a glance, just seems lik…

Look at the disassembly and observe how your function calls have far fewer push/pop operations going on, and how the function prologues/epilogues are smaller.

Re: Go 1.17 Release Notes

#116

Post by jen20 »

benhoyt wrote: post #29

To me, the most interesting change is the performance improvement due to the new register-based calling convention. Your CPU-bound programs will magically get 5% faster when compiled with 1.17: > Go 1.17 implements a new way of passing function arguments and results using registers instead of the stack. Benchmarks for a representative set of Go packages and programs show performance improvements of about 5%, and a ty…

This also likely improves compatibility with observability tooling which assumes the standard calling convention, which is welcome.

Re: Go 1.17 Release Notes

#117

Post by jchw »

umvi wrote: post #7

At first I didn't like Go because I thought it was too opinionated. But the more I used it, the more I found the tooling to be just heads and shoulders above similar languages like C/C++. I use VSCode a lot, and in VSCode you can press "F12" to jump to the location of a function definition. In Go I find myself deep diving into github libraries all the time just because F12 takes me there. That never happened with C/C…

I think people claiming modern C/C++ tools are close to as good as Go’s are wrong, in my opinion. With that having been said, IMO if you want the C++ experience to be better, use Clangd and generate a compile_commands.json file. For many projects you can use wrappers like compiledb, or Bear, and some build systems like CMake can output it natively. Either way, once you have found a way to do this, and get it outputting into the project root, add a local ignore for it (in .git/info/exclude) and install the VSCode clangd extension.

Truly, it is night and day. I can get Real code intelligence on almost anything, including large C projects with custom Makefiles that compile cross-arch like Wine. It only ever has trouble with unusual translation unit patterns. (You can see this in Higan for example, which has .cpp files including other .cpp files; clangd seemingly fails to put them in the context of the intended translation unit.)

It’s not as good as Go, but it is life-changing for me.

Re: Go 1.17 Release Notes

#118

Post by fny »

slownews45 wrote: post #49
rowanG077 wrote: post #43

Earlier quoted context omitted.

Isn't that the case for the vast majority of languages though? The python,c,Haskell,js,language x code from 2015 works the same now as it did 5 years ago.

python 2 -> 3 was not easy (aka a total nightmare). By 3.6 it was pretty good though and even migrations and dual code bases were easier because they went back and allowed things like u"" for unicode strings to continue to mean unicode strings in python 3 - before that they'd actually blocked unicode in 3 that was working well in 2.x code bases! It was a total in your face move to break the ecosystem even though supp…

Python was a unique shit show.

Re: Go 1.17 Release Notes

#119

Post by pjmlp »

josephg wrote: post #69
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…

> In this world, most errors are silly type errors I can’t speak to python, but typescript has basically fixed this problem overnight in the javascript ecosystem. The typescript compiler finds almost all small bugs like this while I’m coding. And as an added bonus, type hints allow the IDE to be much more helpful - adding to jump to function support, autocomplete, method parameter suggestions (or documentation on hov…

I have been in plenty of hills since I wrote those first BASIC lines on a Timex 2068.

Just like consumers don't care if their favourite music application is written in Electron, as long it plays their favourite album on their newly acquired speakers, they also don't care what type system was used to deliver such experience.

With Go finally getting generics, it will be pretty alright, 99% of distributed computing applications need not care about zero GC code, only proper use of value types.

Re: Go 1.17 Release Notes

#120

Post by pjmlp »

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…

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

Post reply on HN