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

101–110 of 222 posts

Re: Go 1.17 Release Notes

#101

Post by silisili »

zzt123 wrote: post #91
josephg wrote: post #69

Earlier quoted context omitted.

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

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.

Re: Go 1.17 Release Notes

#102

Post by typical182 »

woodruffw wrote: post #97
tialaramex wrote: post #95

Earlier quoted context omitted.

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.

There is also a WIP Go proposal for adding a set to the standard library using the upcoming generics:

https://github.com/golang/go/discussions/47331

Re: Go 1.17 Release Notes

#104

Post by ridiculous_fish »

kjksf wrote: post #73
ridiculous_fish wrote: post #58

Earlier quoted context omitted.

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

You can find things to complain in any language, including the languages that YOU use. For every complain like that in Go I'll find a hundred in C++, ten in Java / JavaScript / Python. As to your question, as a full-time Go programmer: this doesn't come up often. When it does, I google "slice tricks" and copy & paste the formula. It'll be fixed by next release because generics will enable writing a function that does…

Oof, I have no desire to spark a language war. Every language has its warts for sure.

It seems strange to not provide slice.erase as a primitive operation, and instead to recommend implementing it in terms of append. Usually removing from a vector does not require allocation. Still it may be for the best with upcoming generics, fewer builtins is good.

Re: Go 1.17 Release Notes

#105

Post by benhoyt »

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…

Overall for GoAWK I get an 18% speed increase on my micro-benchmarks between Go 1.16 and 1.17 (see https://github.com/benhoyt/goawk/commit/1f314f421273b3dc164f...) and I measured an 8% speed increase on my "slightly more real-world" benchmarks (these ones: https://github.com/benhoyt/goawk/blob/master/benchmark_awks....).

Re: Go 1.17 Release Notes

#106

Post by tptacek »

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…

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 foreseeable future. You couldn't reasonably build a browser, or browser components, in Go.

Both languages have their place. There is a lot of overlap, and the original comment about how one might prefer Rust if what they miss most in Go is generics makes sense. But the idea that the only thing you'd gain by choosing Go over Rust is easier development on big teams is just false. One language is GC'd, the other is borrow-checked. GC makes a lot of things faster to build. This debate ended in the mid-1990s.

Re: Go 1.17 Release Notes

#107

Post by _008_jb_ »

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.

Ah, the desperate Rust promoter crew enters the Go thread ...

Rust is great for language enthusiats doing hobby projects or for learning. The Rust book is great. Rust has great language features.

Having that said, Rust is the right tool for the job for a very small niche. Basically, if you would have used C++ before and don't need much developer reach or mature libraries. And only for the rare cases you really cannot affort a GC (even though Go's GC is highly optimized).

Go on the other hand, is an industrial strength proven and mature general purpose language. It is the best fit for various kind of networking application. Especially APIs, but also infrastructure where you can live with an GC. CLIs are great with Go as well.

If you're working on a professional grade project (where the GC is acceptable), Go is much superior than Rust in all regards.

Rust is advertised for years and years and didn't have it's breakthrough yet. This empirical fact cannot be ignored. There're reasons for this, of course. Some are:

- Writing Rust consumes so much more mental power with so little gain. That mental energy should be directed to solving the problem.

- Go makes everything besides your problem at hand easy. You can focus on solving your problem, not fighting the Borrow Checker

- Rust's ecosystem is not reliable. Many essential libs are one-man-shows. Version 0.1 everywhere.

- Rust is for and by language enthusiats. If you need to rely on libs for longer than a couple of years it is a hight risk for your project

- In terms of real world performance: Go is so close to Rust that there're very very very few use cases that really need that marginal gain

Re: Go 1.17 Release Notes

#108

Post by kouteiheika »

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…

> But allocation heap profiling is still something I struggle with.

Have you tried this one? https://github.com/koute/memory-profiler

Re: Go 1.17 Release Notes

#109

Post by sagichmal »

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

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

Re: Go 1.17 Release Notes

#110

Post by _008_jb_ »

When I started using Go I was more than sceptical. I had to mirgrate a CLI tool written in Kotlin (still my favorite language) because the memory consumption was to high.

After a while I actually understood why Go is such a successful language / ecosystem:

Go's priority is to make projects easier. It is doing so by all it's smaller and larger features respectivly skipped features. But one soon understands the big picture of the Go team. Go is designed by very experienced devs who knew what is important and what not.

In my Go projects, I don't have to worry about:

- Memory safety

- Tooling

- Performance

- Structure (once I understood the package desgin philosophie)

- Difficult syntax

- Concurrency

- Libraries, as we can do most with the standard lib

- Maturenes and stability

Instead I focus on the things that count:

- Solve the problem at hand

- Create correct, stable and maintable software

And as this was not enough, the Go team comes around the corner with an 5 % average performace gift.

Awesome.

Post reply on HN