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

141–150 of 222 posts

Re: Go 1.17 Release Notes

#141

Post by ithkuil »

bombela wrote: post #93
ithkuil wrote: post #42

Earlier quoted context omitted.

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/

Valgrind is great, precise but slow.

The missing feature I was comparing was the ability of Go to provide good estimated heap and allocation profiles using minimal overhead on a production workload.

Re: Go 1.17 Release Notes

#142

Post by bilinguliar »

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

It is not only hard for you, but it is also hard for a computer. And Go expresses this perfectly. Once you hide this behind a convenient `slice.Delete(x)`, you may end up with a codebase that bleeds performance.

Re: Go 1.17 Release Notes

#143

Post by KronisLV »

erik_seaberg wrote: post #74
KronisLV wrote: post #50

Earlier quoted context omitted.

That's just one of the ways to think about it. Java, .NET (I felt like adding these two to expand on the comparison), Python and JS are all languages with a relatively high level of abstraction and large and useful ecosystems surrounding them. They're pretty popular for all sorts of application development, but all suffer from certain problems: - Java has lots of brittle reflection in some libraries and JDK can be fi…

GC tuning is painful, but it’s quicker and more reliable than rewriting code hoping for same result.

Partially agreed, many times it's just a patch over a codebase that's stuck only running on JDK 8 - people expect tuning to be sufficient when the code is slowly rotting.

I'd argue that most systems that won't die out eventually will need a rewrite, or alternatively, in the modern day we'll see more and more polyglotic systems popping up.

Therefore it always makes sense to explore the best options for a particular bit of development, regardless of whether it's Node, Python, Java, Go or something else.

Re: Go 1.17 Release Notes

#144

Post by xpressvideoz »

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

Huh, I also thought Go had no concept of finalizers. That is a bit... awkward way to set a finalizer. But thinking it again, it may just be due to my unfamiliarity.

Re: Go 1.17 Release Notes

#145

Post by harikb »

systemvoltage wrote: post #128
_008_jb_ wrote: post #110

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

Not a GO dev, has the debugging experience improved?

VsCode or IntelliJ with delv works beautifully for most common tasks. But don’t compare to JVM/Java. It does get trickier if you have many concurrent/goroutines but that is not unique to Go.

Re: Go 1.17 Release Notes

#146

Post by rawoke083600 »

Lol Good Little Go ! :) Still one of my favourite languages whenever "heavy lifting" or concurrency is required (really they make it stupidly easy).

Now add pattern matching please ! Well done to everyone that worked on Go ! It's still a pleasure to use.

Re: Go 1.17 Release Notes

#147

Post by Zababa »

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 have the opposite view on the type systems: Rust's type system is really great for business logic because it's really expressive (based on algebraic data types), but the language being made for low level stuff makes some things a pain. If you do something like DDD, ADTs really shine, especially when combined with pattern matching. I do agree that when you can afford a GC, Rust can be annoying.

Re: Go 1.17 Release Notes

#148

Post by deathanatos »

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

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.

Re: Go 1.17 Release Notes

#149

Post by josephg »

silisili wrote: post #101
zzt123 wrote: post #91

Earlier quoted context omitted.

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.

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 based operational transform became about 1.5x longer in Go compared to rust or typescript because its so awkward to express a parametric enum in go. And it was much harder to read & more buggy as a result. Sadly I lost the go version of the code. I'd be curious if someone with more go experience could do a better job, but I'm skeptical.

Hopefully the situation improves somewhat when generics land.

[1] https://github.com/josephg/textot.rs/blob/03c84b7c35a375ba7d...

Re: Go 1.17 Release Notes

#150

Post by kouteiheika »

nyanpasu64 wrote: post #124
kouteiheika wrote: post #108

Earlier quoted context omitted.

> But allocation heap profiling is still something I struggle with. Have you tried this one? https://github.com/koute/memory-profiler

How does this one compare to Heaptrack (which is a CLI/GUI memory profiler that supports C++ and probably Rust as well)?

There are many differences, but the main ones are that it has less overhead when profiling, more thorough analysis features (Heaptrack's GUI is relatively simple compared to it), and the next version will have scripting capabilities for analysis.
Post reply on HN