Go 1.17 Release Notes • Hacker News Board

Re: Go 1.17 Release Notes

#91

Post by zzt123 » Tue, Aug 17, 2021, 1:43 AM UTC

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…

Your point about Go shining a lot more brightly when working with a team which has mixed skill levels was one of the design goals of Go, so it seems they’ve succeeded on that front if you’ve come to that conclusion independently!

Re: Go 1.17 Release Notes

#92

Post by tialaramex » Tue, Aug 17, 2021, 1:47 AM UTC

throwaway894345 wrote: post #48

throw149102 wrote: post #30

I hate to be "that guy", but you should try Rust. It also has amazing tooling, and is probably more comparable to C/C++, considering you don't have to use a garbage collector in Rust.

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 explicit resource cleanup for a programmable interrupt controller, or a file, or a database connection -- the resource knows how to manage itself, and Rust promises to tell it immediately when it falls out of use, whereas a GC can't promise to ever clean up which is why 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).

Re: Go 1.17 Release Notes

#93

Post by bombela » Tue, Aug 17, 2021, 1:55 AM UTC

ithkuil wrote: post #42

throw149102 wrote: post #30

I hate to be "that guy", but you should try Rust. It also has amazing tooling, and is probably more comparable to C/C++, considering you don't have to use a garbage collector in Rust.

I hate to be "that guy" too, but coming from somebody who really likes Rust and is using it more and more (also at $dayjob now) we must admit that Go tooling is one step ahead. CPU profiler, allocation and heap profiler, lock contention profiler. It all comes out of the box. Yes you have cargo flamegraph for profiling locally and you now have pprof-rs to mimick Go's embedded pprof support. But allocation heap profili…

What about valgrind? https://valgrind.org/

Re: Go 1.17 Release Notes

#94

Post by Blikkentrekker » Tue, Aug 17, 2021, 1:57 AM UTC

throwaway894345 wrote: post #48

throw149102 wrote: post #30

I hate to be "that guy", but you should try Rust. It also has amazing tooling, and is probably more comparable to C/C++, considering you don't have to use a garbage collector in Rust.

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…

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

Even if it weren't for the performance I would use Rust over Go due to the lack of generics alone, as well as the associated general philosophy of Go that boilerplate is good and one should repeat oneself as much as possible.

Re: Go 1.17 Release Notes

#95

Post by tialaramex » Tue, Aug 17, 2021, 2:00 AM UTC

woodruffw wrote: post #85

jrockway wrote: post #80

Earlier quoted context omitted.

map[T]struct{} is the set type in Go. (Note that struct{} is represented with 0 bytes of memory, so it's not chaff.) You might like the slices proposal for utility functions like these: https://github.com/golang/go/issues/45955

Thanks. I wasn't aware that struct{} is zero-sized, so that plugs that hole. I'll admit freely that I'm not a proficient Go programmer, so it's easier for me to see the things I don't like than the things that Gophers praise. But even this solution leaves me unsatisfied, in contrast to what I'd reach for in Rust or even C++: it requires that I know that struct{} is zero-sized, and I still have to do the manual legwor…

Zero Size optimisations are a thing in Rust too though, and I don't think an empty struct being zero size is any more surprising than Rust's empty tuple being zero size.

Like, if you tell Rust you want 4 million empty tuples in a vector, it will give you a vector with exactly 4 million empty tuples in it and no heap allocation because those empty tuples don't take space, so, 4 million of them also doesn't take up any space.

Re: Go 1.17 Release Notes

#96

Post by bombela » Tue, Aug 17, 2021, 2:01 AM UTC

woodruffw wrote: post #85

jrockway wrote: post #80

Earlier quoted context omitted.

map[T]struct{} is the set type in Go. (Note that struct{} is represented with 0 bytes of memory, so it's not chaff.) You might like the slices proposal for utility functions like these: https://github.com/golang/go/issues/45955

Thanks. I wasn't aware that struct{} is zero-sized, so that plugs that hole. I'll admit freely that I'm not a proficient Go programmer, so it's easier for me to see the things I don't like than the things that Gophers praise. But even this solution leaves me unsatisfied, in contrast to what I'd reach for in Rust or even C++: it requires that I know that struct{} is zero-sized, and I still have to do the manual legwor…

Fun thing, is Rust employs the same trick. The HashSet is an alias for HashMap. "()" is the unit type. Which is zero-sized.

Because Rust has generics, it is more ergonomic though.

https://doc.rust-lang.org/std/collections/struct.HashSet.htm...

Re: Go 1.17 Release Notes

#97

Post by woodruffw » Tue, Aug 17, 2021, 2:07 AM UTC

tialaramex wrote: post #95

woodruffw wrote: post #85

Earlier quoted context omitted.

Thanks. I wasn't aware that struct{} is zero-sized, so that plugs that hole. I'll admit freely that I'm not a proficient Go programmer, so it's easier for me to see the things I don't like than the things that Gophers praise. But even this solution leaves me unsatisfied, in contrast to what I'd reach for in Rust or even C++: it requires that I know that struct{} is zero-sized, and I still have to do the manual legwor…

Zero Size optimisations are a thing in Rust too though, and I don't think an empty struct being zero size is any more surprising than Rust's empty tuple being zero size. Like, if you tell Rust you want 4 million empty tuples in a vector, it will give you a vector with exactly 4 million empty tuples in it and no heap allocation because those empty tuples don't take space, so, 4 million of them also doesn't take up any…

The key difference being knowledge: I don't have to know `HashSet` is really just a map with a ZST to use it efficiently. All I need to know is that I don't need a value, and the ecosystem obliges me. This in contrast to Go, where I need to know that `struct{}` is a ZST, that the "right" way to do a set is to use it as the map value, &c.

Re: Go 1.17 Release Notes

#98

Post by drchase » Tue, Aug 17, 2021, 2:07 AM UTC

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…

Hi, I'm one of the people who worked on it, and the guy who did the initial estimate back in early 2017. 5% is the geomean of a lot of benchmarks; a whole lot fall in the the 4-8% range, a few do worse because the new ABI creates new patterns of register use that don't fit well with the current register allocator, and the fix was larger than we wanted to risk. (See https://github.com/golang/go/issues/46216 )

Re: Go 1.17 Release Notes

#99

Post by throwaway34241 » Tue, Aug 17, 2021, 2:27 AM UTC

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…

> 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

Re: Go 1.17 Release Notes

#100

Post by avl999 » Tue, Aug 17, 2021, 2:39 AM UTC

ridiculous_fish wrote: post #58

avl999 wrote: post #26

Go is my favorite language to write code in. I was very skeptical when I first started learning it for a new job with error handling that looked archaic in comparison to exceptions but once I got the hang of it it has quickly become my preferred language of choice for any project. Once generics are finally added the language should basically be a no-brainer for any serious production code.

From a distance it looks difficult to write in. For example, two recommended ways to delete from a slice: a = append(a[:i], a[i+1:]...) // or a = a[:i+copy(a[i:], a[i+1:])] Both seem harder than necessary. Is that code just idiomatic, and Go programmers recognize it instantly? Or maybe they don't deal with slices that often? https://github.com/golang/go/wiki/SliceTricks

Dealing with any kind of collections will often require you to write more code than you are used to, see the other post in this thread about someone complaining about a lack of Set type. Most of these problems are due to the fact that the language doesn't have generics yet, however generics are coming soon and once they do arrive we will have a robust collection and concurrent collection library to alleviate for most of these problems.

For now you just have to accept these quirks as part of the tradeoff of working with the language. I don't find it that big of a deal esp with the solution on the horizon.