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

121–130 of 222 posts

Re: Go 1.17 Release Notes

#121

Post by pjmlp »

atombender wrote: post #55
dilyevsky wrote: post #39

Earlier quoted context omitted.

Python/Js are interpreted by default and not good system programming choices. Go is compiled. This comparison totally misses the mark. In fact Go was developed mostly as C++ but sometimes Python replacement at Google.

And yet Go seems to have not captured many C++ developers, but rather developers from languages like Python, Ruby, and JavaScript. The Go team originally wanted to replace C++, especially inside Google, but they didn't succeed. According to googlers on Hacker News, very few projects inside Google actually use Go. The reason Go attracted these kinds of developers is precisely that it isn't a systems programming langua…

Lack of generics kept most of us away.

You don't return to 1992 C++, thinking nah this is fine.

Companies like F-Secure are using Go for real system programming just fine.

https://www.f-secure.com/en/consulting/foundry/usb-armory

Re: Go 1.17 Release Notes

#122

Post by pjmlp »

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.

My C and C++ code for Windows 3.1 written in 1995 would compile just fine today on Windows 10.

Re: Go 1.17 Release Notes

#123

Post by benhoyt »

jen20 wrote: post #116
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.

Note that this switches to a register-based calling convention, but it's not the platform "standard" one. The Go authors describe the rationale for this here: https://go.googlesource.com/proposal/+/master/design/40724-r...

Re: Go 1.17 Release Notes

#124

Post by nyanpasu64 »

kouteiheika wrote: post #108
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…

> 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)?

Re: Go 1.17 Release Notes

#125

Post by systemvoltage »

pjmlp wrote: post #122
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.

My C and C++ code for Windows 3.1 written in 1995 would compile just fine today on Windows 10.

As a person that gets anxiety from JS projects and how fast things move, I love this aspect of C. It puts the soul to ease.

Re: Go 1.17 Release Notes

#126

Post by zz865 »

pgwhalen wrote: post #34
zz865 wrote: post #15

Anyone seen jobs for business applications? Go seems to have a sweet spot for systems. I'd like to replace Java at my work but no one else is doing it.

I use (and enjoy using) both Go and Java at work, and Go is in my opinion very much a Java replacement more than it is, say, a Python or C++ replacement. It is absolutely suitable for business logic, and I've never been quite sure what its designers mean when they say it's a systems language. Yes, you can squeeze great performance out of it, but you can with Java as well. The way I see it, both Go and Java are crawli…

Thanks, that sounds about right. Throw Rust in there too, its an interesting time.

Re: Go 1.17 Release Notes

#127

Post by systemvoltage »

ricardobeat wrote: post #90
rowanG077 wrote: post #56

Earlier quoted context omitted.

Of course changes but afaik it's backwards compatible.

I don't think the OP was making a point about backwards compatibility, but how the language itself has remained stable (sign of good design?). That is not the case for the majority of languages, except for maybe Ruby. Javascript in particular looks nothing like code from 6 years ago.

Furthermore, you rarely just plain JS. It's always another behemoth framework such as React or Angular.

I challenge anyone to upgrade a project from Angular ver 5 to the latest. It's possible but you'll also question whether its possible for you to quit software engineering and learn woodworking.

Re: Go 1.17 Release Notes

#128

Post by systemvoltage »

_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?

Re: Go 1.17 Release Notes

#129

Post by steren »

systemvoltage wrote: post #125
pjmlp wrote: post #122

Earlier quoted context omitted.

My C and C++ code for Windows 3.1 written in 1995 would compile just fine today on Windows 10.

As a person that gets anxiety from JS projects and how fast things move, I love this aspect of C. It puts the soul to ease.

The JS code you wrote 20 years ago still runs today (and much much faster)

The problem is not JS, more the dependencies you decided to take for your project.

Re: Go 1.17 Release Notes

#130

Post by theshrike79 »

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.

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.
Post reply on HN