Hacker News Reader

It is a boring, no-magic language on purpose.

I think it appeals to cynical devs who have seen projects misuse more powerful languages, and who don't want to debate style guidelines or linter settings for any more than 5 minutes. I count myself among them.

Aside from offering nothing new, its design was wilfully, explicitly anti-intellectual. Once you've used an expressive language, having to copy-paste boilerplate becomes very painful. And there's no real USP except Google backing, so it's pretty disappointing to see it beat out better-designed languages.

> it beat out better-designed languages

Which languages did Go beat out?

I didn't mean globally (though on a quick search I'm seeing it place above e.g. Swift, Kotlin, Dart, and Ruby), I meant it's frustrating to see Go be chosen over a better-designed language "in the small", for a specific product or SDK.

Don’t worry about it. Your assessments are exactly correct.

I’m not putting down any other development environments, but everything you say is absolutely true in your circumstances (mine too).

It’s verbose. Errors everywhere.

There are a lot of foot guns. nil slice? Fine. nil map? Segfault. Loop variables with closures. The list goes on.

Generics seemingly split the community. May be some libraries won’t get used because they picked the wrong side.

It’s surprisingly weak at modeling data. Union types would really help out.

The community is so anti-design that it’s hard to play with them. Most want to make a big ball of mud and call it agile. When you point out simple patterns, they call you an Architect Astronaut. Checkout r/golang. Also look out for people telling you how dumb you are for wanting generics.

In many cases it’s a step backwards but it has the positives you posted. That is often a reason to grin and bear it. Eventually Stockholm Syndrome kicks in.

> Loop variables with closures

indeed a brutal footgun but will be fixed soon

Have they actually agreed on how to fix this now?

Effectively yes.

A fix for the loop variable closure problem is now in the official proposal process, which is how language changes happen in Go.

It’s a concrete proposal from the core Go team and seems to be on track for acceptance:

https://github.com/golang/go/issues/60078

An implementation is already available on tip and in the upcoming Go 1.21 release behind a GOEXPERIMENT flag.

The community reaction has been extremely positive. As one approximate measure, an earlier draft of the proposal had 671 upvotes and with 0 downvotes:

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

> Generics seemingly split the community. May be some libraries won’t get used because they picked the wrong side.

I haven't really observed that at all.

One thing that is going on is there hasn't been a massive disruption while everyone stops to rewrite the world in generics, and generics are not suddenly everywhere, which is what some people had predicted would happen. I think part of the reason is that in some cases another solution (closures or interfaces or whatever) can be a better fit, and the evolutionary approach to generics that Go took means you can use generics in conjunction with non-generic libraries or other pre-existing approaches without suffering from an ecosystem split.

Golang is IMO the best applications language. Most of my criticisms of it would be that it makes some systemsy things clunky, and because of garbage collection it just isn’t ideal for some systemsy stuff.

I personally hate the empty interface and definition shadowing of Go but that could be just me not “getting it”. Fortunately at work we don’t use that too often

I think most of the criticism is from people like me coming from C++. I am continually baffled that people write web backends in Python and Node at all, to me they seem so inappropriate that criticizing them would be a waste of time. I would consider Go to be much much better overall, and thus worthy of actual criticism

> I think most of the criticism is from people like me coming from C++. I am continually baffled that people write web backends in Python and Node at all, to me they seem so inappropriate that criticizing them would be a waste of time

Care to elaborate? I'm curious what's wrong with either for web backends

I mainly love Python because of Django. I haven't found a Go equivalent (generated db migrations, admin panel, DRF, etc).

It is boring, that is the appeal for most of its proponents I think. Obviously that doesn't appeal to the nerdier side of programming, but if your goal is to "write programs" as opposed to "do programming for programmings sake", it gets out of your way most of the time to enable that in my experience.

My favourite languages are Common Lisp and OCaml but I've found Go surprisingly useful professionally. It's easy to onboard new team members, even those without prior experience, and some made contributions the very first day. The language handles complex workloads without much need for tuning or premature optimization and has sensible garbage collection defaults for latency. My main concern is an ongoing trend towards "Java-ification", like watching your favorite punk band start to sound suspiciously like Nickelback, but I think it's still a pretty good language. Go is like one of those "so bad it's good" movies.

It's just not a shiny squirrel thing in a tree, that's all.

> Genuine question..

There have been about a hundred “why Go”/“why not Go” threads on Hacker News already.

It would have been a great language, had it been released in 1992 - 1996, back when Oberon and Limbo, its influences, were making the rounds.

Nowadays, it is trailing most languages in expected set of features.

Go isn't the only alternative to running node/js or python on the server side.

> But it overall seems much nicer than running node/js or python on the server side, no?

No, it's just trade-offs.

I think you are making the same mistake by looking for validation on HN that you're making some sort of Better Choice, but you're just making a normal choice. You just don't yet have the experience to see all the trade-offs nor how they compare to, say, Node or Python.

For example, there are various ways Node is "nicer" than Go on the server. Just compare things like Promise.all or a concurrency-limited Promise.map to Go's WaitGroups.

But I'm not really making a choice. I'm open to anything, i don't want to restrict myself. I have and do use the things i mentioned a lot (node/python). I was just curious what the people have to say since i noticed this recently. I don't really need the validation since I'll try out all available options due to curiosity anyway.

HN loves playing "obligatory contrarian" so often commenters will go to lengths to find faults

there is nothing wrong with Go; it delivers on its promise, you don't need to be a genius to use it, has good community support, and you can get access to a large and decent job market

Rust is a great tool but isn't as purpose-suited to network services as Go

Zig is even less purpose-suited to writing network services and won't be at Go's level of maturity for years, if ever

If a backend dev could only know one language in 2023, it would be hard to go wrong with Go

> but isn't as purpose-suited to network services as Go

Why?

+1. In terms of development speed, Node + Axios is lightyears ahead. It's like 5 lines of code to send a JSON payload via http, vs 15+ in Go. The Javascript version is much likely to be correct as well, since it doesn't let you forget to check any of the three errors, or forget to check the http status of the response.

If I mostly use TypeScript for the backend, what would be a benefit of Go to make me switch?

It’s simple when you have WhatsApp vs BlackBerry Messenger and we know that WhatsApp wins, you begin to question yourself what’s making blackberry win even tho it’s inferior, then hearing their secret weapon “Simplicity” trying to mimic the secret weapon but yet still wondering why isn’t going as expected, this is what is happening No matter how go improves people will still talk about its past failures with present failures, so you don’t have to worry people will still use the language and its competition

Yeah, it's pretty much optimized for junior programmers to write babby's first enterprise network service in. It's got a lot of features junior programmers think are nice and easy to work with, but as you mature as a developer its verbosity becomes annoying and its shortcomings become apparent.

Using Go as a PHP alternative is pretty much the use case most aligned with its niche. So go nuts if you like doing that. But stray too far from that use case and Go will start to provide pain without adequate justification, especially when compared against Zig, Rust, or even TypeScript.

The post I'm replying to is downvoted and I should probably simply move on but there's key phrasing here I'd like to point out:

> optimized for junior programmers to write babby's first enterprise

This is the (toxic) attitude Go strives to distance itself from. There is no magic, we can all be equals in this place. It's humbling. I'm not aware of any other mainstream project that captures this essence so well.

There is power in a language equalizing things. If you aspire to wring elegance out of complex or esoteric language features then by all means have fun with that but I have no interest in working with you on that. Your definition of pain could not possibly be more diametrically opposed to mine.

> There is no magic, we can all be equals in this place.

...in the Harrison Bergeron sense.

The fact that Rust has attracted relatively inexperienced coders to do bare-metal, real-time programming shows that you don't need to nerf the language in order to appeal to interested developers of all skill levels.

Who said anything about attracting inexperienced developers? If anything I'd argue that's a negative for a healthy ecosystem, and I'd argue it has been a negative for Rust.

It's the junior engineers that most often struggle with trying to devise a way to use every language feature under the sun when solving a problem, not the other way around.

I'm tired of people saying that there is no magic. How are you saying that? Do you any basis? Named returns, compiler not ensuring that non pointer receivers do not modify a property, bare bones dependency management, laughable implementation of errors, the list goes on...

How is the implementation of errors "laughable"? An error is just another result of calling a function. Seems reasonable enough.

None of that qualifies as magic. Indicators of magic features are implicitness, action-at-a-distance, high complexity.