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

191–200 of 222 posts

Re: Go 1.17 Release Notes

#191

Post by int_19h »

erik_seaberg wrote: post #137
kubb wrote: post #57

I’ve been using Go at a large software company for 4 years. It does the job, my biggest complaints are the low capacity for abstraction, verbosity and ergonomic pain points. It can do certain things well, but in a large enough project you’ll inevitably find that it doesn’t give you the best tools for certain types of problems. I don’t know what to think about the upcoming generics. It feels late to make such a big ch…

> feels late to make such a big change This is recoverable. The Java world was also saddled with a decade of awful pre-generic code, but we burned almost all of it to the ground and started over.

The need to tackle generics later resulted in design decisions such as type erasure, which even today are still limiting the evolution of Java.

Re: Go 1.17 Release Notes

#192

Post by pjmlp »

dilyevsky wrote: post #186
pjmlp wrote: post #121

Earlier quoted context omitted.

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

Under wider definition of “system software” you can consider db tech (etcd, cockroachdb, digraph) and compute management software (kubernetes, nomad, docker) to be included into that. Which is where Go is doing just fine. Lower level stuff is harder but because of gc not lack of generics

GC is just fine for OS development, as proven by Xerox PARC, ETHZ systems used in production.

The problem is more of mentality and not having management willing to push it down unbelievers no matter what, that prefers to recycle UNIX clones instead to save money.

Midori powered Asian Bing for a while and even then the Windows team did not believe it was possible.

Re: Go 1.17 Release Notes

#193

Post by pjmlp »

nemetroid wrote: post #185
pjmlp wrote: post #178

Earlier quoted context omitted.

So it isn't.

Correct, but except in very special cases, memory leaks are themselves considered bugs. Using memory leaks as an example of RAII not always working is, in my mind, similar to saying Rust doesn't prevent memory errors since it has the "unsafe" keyword.

Except when using system code you might have to pack pointers in OS IPC structures which don't map into smart pointers.

Similar to forgetting memory in Rust, and then there is no miracle RAII.

Re: Go 1.17 Release Notes

#194

Post by erik_seaberg »

throwaway894345 wrote: post #181
Blikkentrekker wrote: post #180

Earlier quoted context omitted.

It has nothing to do with catching bugs. It has to do with that one sometimes has to write 80 lines of code in Go to to the same as 3 lines of Rust code due to having to repeat oneself all the time.

That’s an even more superficial concern. No one is bottlenecked on the rate at which they can type.

Maintainers are bottlenecked by the rate we can (re)read. Boilerplate is the problem that makes us want powerful languages; if it didn’t matter we could have stayed with assembly.

Re: Go 1.17 Release Notes

#195

Post by theshrike79 »

int_19h wrote: post #190
theshrike79 wrote: post #131

Earlier quoted context omitted.

Go is the choice of professionals IMO. When you have a team of varying skill levels who need to deliver shit that works on a schedule and still have some kind of performance, you use Go. Even more so if you need to hand off the maintenance to a team of randoms from god knows where and THEY need to be able to keep it running and add new features. It doesn't have the fanciest new EXPRESSIVE operators or anything exciti…

I would argue that e.g. decent error handling is not "fancy shit".

It's perfectly decent, it forces you to explicitly handle or ignore every error.

It's verbose as all hell, but on the other hand you'll notice immediately if it's missing.

Go is not a "fun" language by any means, but that doesn't mean it's not a productive one.

Re: Go 1.17 Release Notes

#196

Post by nemetroid »

pjmlp wrote: post #193
nemetroid wrote: post #185

Earlier quoted context omitted.

Correct, but except in very special cases, memory leaks are themselves considered bugs. Using memory leaks as an example of RAII not always working is, in my mind, similar to saying Rust doesn't prevent memory errors since it has the "unsafe" keyword.

Except when using system code you might have to pack pointers in OS IPC structures which don't map into smart pointers. Similar to forgetting memory in Rust, and then there is no miracle RAII.

Yes, if you're not using RAII, RAII doesn't work.

Re: Go 1.17 Release Notes

#197

Post by erik_seaberg »

int_19h wrote: post #191
erik_seaberg wrote: post #137

Earlier quoted context omitted.

> feels late to make such a big change This is recoverable. The Java world was also saddled with a decade of awful pre-generic code, but we burned almost all of it to the ground and started over.

The need to tackle generics later resulted in design decisions such as type erasure, which even today are still limiting the evolution of Java.

Yeah, that was an unforced error. Fundamental changes to a language can and should rely on upgrading deployed runtime libraries.

Re: Go 1.17 Release Notes

#198

Post by slownews45 »

int_19h wrote: post #189
slownews45 wrote: post #49

Earlier quoted context omitted.

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 3 should be considered a different language from Python 2, pretty much.

The level on intentional compatibility breaking was crazy.

The fact that they went out of their way to break python 2 unicode when running on python 3 was just totally nuts. Especially after making such a big deal about unicode!

I've never seen anything like it I don't think? Maybe the new Perl that never really landed?

Re: Go 1.17 Release Notes

#199

Post by throwaway34241 »

throwaway894345 wrote: post #172
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 aren’t quite the same. They run when memory pressure exceeds some threshold, but the GC analog for borrow-checking is something that will clean up a resource when the pressure on the resource in question exceeds some threshold (e.g., file handles). And even then I’m not sure if that ticks all requirements for resource management.

I meant to respond only to the quoted section comparing Java and Go, which states that Go doesn't have a way to do cleanup on GC (finalizers). I agree with you (and the two other replies and the quoted section itself) that finalizers are not a replacement for RAII etc.

I don't use them for resource cleanup, but I think they probably make sense for library authors as a back-up mechanism (for example, the standard library has a finalizer to close file handles, and the current runtime does GC every two minutes in the absence of memory pressure). You can also explicitly run the GC in Go, and while generally there's a lot of problems with that idea I could maybe imagine it being viable for certain unusual workloads.

Re: Go 1.17 Release Notes

#200

Post by kcartlidge »

KronisLV wrote: post #50
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.

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…

I do both C# and Go so have no axe to grind here. Just two small points though.

> .NET needs a runtime

It doesn't. With a single command .NET Core can produce stand-alone single-file cross-platform deployables needing no SDK, Framework, runtime, or other dependency on the server.

> Go at least partially solves some of those problems, by being compiled, having decent performance, somewhat rich ecosystem and passable package management, all while the language remains usable.

It does, and I've been a big fan of Go for a fair few years now. However every point made in that sentence applies equally to .NET too.

The one area where Go beats C# (and most others) hands-down for me is the build time. It's a whole order of magnitude (possibly several) faster than most alternatives.

Post reply on HN