←back to thread

Go is still not good

(blog.habets.se)
644 points ustad | 4 comments | | HN request time: 0.012s | source
Show context
SkepticalWhale ◴[] No.44985889[source]
Go has its fair share of flaws but I still think it hits a sweet spot that no other server side language provides.

It’s faster than Node or Python, with a better type system than either. It’s got a much easier learning curve than Rust. It has a good stdlib and tooling. Simple syntax with usually only one way to do things. Error handling has its problems but I still prefer it over Node, where a catch clause might receive just about anything as an “error”.

Am I missing a language that does this too or more? I’m not a Go fanatic at all, mostly written Node for backends in my career, but I’ve been exploring Go lately.

replies(10): >>44985997 #>>44986010 #>>44986136 #>>44986517 #>>44986991 #>>44987075 #>>44987252 #>>44987361 #>>44987973 #>>44992564 #
ecshafer ◴[] No.44986010[source]
> It’s faster than Node or Python, with a better type system than either. It’s got a much easier learning curve than Rust. It has a good stdlib and tooling. Simple syntax with usually only one way to do things. Error handling has its problems but I still prefer it over Node, where a catch clause might receive just about anything as an “error”.

I feel like I could write this same paragraph about Java or C#.

replies(3): >>44986143 #>>44986282 #>>44991589 #
acedTrex ◴[] No.44986143[source]
Java and C# are both languages with A LOT more features and things to learn. Go someone can pick 80% of the language up in a single day.
replies(4): >>44987049 #>>44987141 #>>44987283 #>>44990787 #
1. bob1029 ◴[] No.44987049{3}[source]
Just because you can learn about something doesn't mean you need to. C# now offers top-level programs that are indistinguishable from python scripts at a quick glance. No namespaces, classes or main methods are required. Just the code you want to execute and one simple file.

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...

replies(2): >>44987427 #>>44989242 #
2. acedTrex ◴[] No.44987427[source]
I mean thats fine, but thats hardly applicable to the ease of throwing a new dev into a very large c# codebase and how quickly they can ramp up on the language.
replies(1): >>44987536 #
3. novok ◴[] No.44987536[source]
Any large codebase has a large ramp up time by virtue of being large. And the large codebase can have devex automation to get past the initial ceremony setup of larger languages like Java. It feels like the wrong thing to optimize for. As a better alternative to small services that would've been made in python or node, yes for sure, then the quick setup and simplicity of go makes sense. Which is why the biggest audience of people who use go and used another language previously is python engineers and people who want to make small network services.

At the larger codebase go company I worked at, the general conclusion was: Go is a worse Java. The company should've just used Java in the end.

4. slipperydippery ◴[] No.44989242[source]
The benefit of the language being small and "normal" idioms mostly followed and the std library being good-enough that people rarely import another dep for something it can handle is that it's by far the easiest language in which to read my dependencies that I've ever used.

If I hit a point where I need to do that in pretty much any other language, I'll cast about for some way to avoid doing it for a while (to include finding a different dependency to replace that one) because it's almost always gonna be a time-suck and may end up yielding nothing useful at all without totally unreasonable amounts of time spent on it, so I may burn time trying and then just have to abandon the effort.

In go, I unhesitatingly hop right in and find what I need fast, just about every time.

It's the polar opposite of something like Javascript (or Typescript—it doesn't avoid this problem) where you can have three libraries and all three both read like a totally different language from the one you're writing, and also like totally different languages from one another. Ugh. This one was initially written during the "everything should be a HOF" trend and ties itself in knots to avoid ever treating the objects it's implicitly instantiating all over the place as objects... this one uses "class" liberally... this one extensively leans on the particular features of prototypal inheritance, OMG, kill me now... this one imports Lodash, sigh, here we go... et cetera.