Hacker News Reader

Comment by dnautics | Hacker News Reader

The defer interaction with named return values is going to give me nightmares.

We have a senior dev whose software caused a memory leak in prod. One of our less senior devs (who has an engineering PhD in concurrent systems theory) immediately identified that the senior was trying to do clever optimizations for single threadedness that simply cannot work when concurrent... I wouldn't be surprised if his code is causing a goroutine leak.

I am convinced that go is popular because it's comfortable to elder seniors and makes them think they can use their aging python/c/c++ skills in something flashy, new, concurrent, "supported by Google" and... Well at least it's genuinely safer.

Disclaimer: I'm an aging dev myself.

View on HN

I actually think go is being propped up by young people with mediocre experience/jobs that work on glue/ops tooling and thinking they are leet. Go is such a primitive language it feels like systems programming (C) without actually being useful for systems programming and is wildly outclassed for applications programming. The perfect self selector for Google's SRE army.

One nice thing about Go is it produces cross platform binaries without external dependencies, and the standard library supports Windows api stuff like system services and registry.

Mono/C# is better, but the learning curve is pretty steep compared to Go with all the missing reference assemblies, diverse runtime versions, etc. Gopath sucks and sucks to configure but it's less complicated than .net.

So you can ask a junior web dev to learn a new language in a week and write a native windows application, and they might actually deliver. Whether this is empowering or signals the death of Quality remains a hotly contested issue.

I started writing Go at age 23, for what its worth. (That was a just a few years ago.) I like Go because its simple. Obviously, that is also its downfall. Overall, I would still hold it as one of the best languages for writing various kinds of software (servers, CLI tools, and some odds and ends.)

It’s true that you can write bad Go by trying to do things that are not a good idea, but I’m not sure what you’d expect. The Go ecosystem is damning evidence of the ease of writing pretty good code in the language.

Disclaimer: I work for Google (but I do not work on Go and I did not work for Google when I first began writing Go.)

No doubt. I strongly believe go is a major advancement over c/c++ for routine work and an improvement over python.

There are, however major footguns, I find it hard to read other people's, or even my own code (parsing nested if conditionals is no fun when you're debugging under duress), and CSP is really just.... Not the best concurrency paradigm.

There's no such thing as "C/C++".

Sorry c/c++ family. Explicit is better than implicit.

Pardon me. C was my second real language after Pascal and c++ came immediately after that in a 6 month timespan, so for my underperforming and scelerotic brain (aside from an ld_preload shim I wrote two years ago haven't touched them since the aughts) they are "together" in my brain. Curly braces and all that.

I fully disagree. I find Go very nice to read.

I think that's plausible, even though Google's intentions with it were the opposite:

I've had the opportunity to talk with a few people who were involved in Go's design and they explicitly said the idea was to get fresh-out-of-school programmers to be productive on web systems immediately.

One of the idioms of Golang is not being clever but being verbose and clear.

Looks like your senior dev has completely missed that.

By clever I mean clever reuse of system resources, e.g. This is not anything being more verbose would have helped.... Race conditions and deadlocks were introduced.

Reply on news.ycombinator.com