Comment by one2three4 | Hacker News Reader

Comment by one2three4 | Hacker News Reader

Parent Full thread

Things like that make me shake my head every time I hear "Go is easy to learn."

No. It's not. There are way too many dark corners with things lurking there to bite you. It just "looks easy" until you try to do something non-trivial.

Used to love it but the more I learn about it the more I fall out of love. I can't help to wonder, would it be so successful if it weren't for all the Google-hype and the push because of kubernetes?

I don't mean to bad-mouth it. It's just that I invested time and effort to what now seems to me a bad language. A good language -IMO- should get out of the way once you spend some time with it. Be as transparent as possible so that you can focus on the real problem. And do that in a safe way. But here I am in 2021 having to worry about all different types of nils. Or having to decide which way to go about marshalling JSONs. Why put at least one inefficient way to do it? I know, it makes code reviews fun. And don't get me started with all the conventions and whatnot that half the community sees as holy - if they are why not putting them in the compiler like they did with gofmt and get done with it? I mean this whole thing started off on very good premises -cut down complexity, simplify, get unproductive arguments out of the way- but somehow it looks like it stuck somewhere halfway there in a grey zone that converts it to the new java fast. No problem with java here but I guess if they wanted to create a new javaesque ecosystem/community then why go to all that trouble. So my guess is that they didn't.

Dunno...

Had I time and not job market restrictions I'd be looking to Elixir for concurrency and Nim for everything else. But things being what they are I'm stuck with the gopher.

Time, Enums, Final, Sets - all nightmares in Go and make me miss Java. These are the basics and they are hard or missing.

And now with records and pattern matching coming to Java, even more so.

I have the same feeling every time someone says C is "simple". It's simpler than C++, yes, but it's definitely not simple. There are a LOT of dark corners.

There are no hidden calls, mostly there is one way to do something. No exceptions, so you can see entrance and exit points of a function. There is no "abstraction" feature, so you tend to keep your code away from unnecessary abstractions.

You can find counter-examples ofcourse, bad programmers can create a mess from anything and everything.

My question is, as an example, how come Linux kernel's code ,nginx's code or memcached's code 100 times more readable than any other project in another "better" language.

This is why people say C is simple. You have limited options and you tend to end up with a "simple, readable" solution.

No one says "C is perfect, you should use it for anything and everything, it handles all the issues of computers, no gotchas, no surprises, 3 year old kids should start with C programming."

Unless you're working with strings, which are a hell of a nightmare to use safely. It's become a lot better in terms of the stdlib, but even stuff like the supposedly safe vsnprintf may quickly ruin your day and open potential overflow exploits if you forget to accout for the space of a null terminator or accidentally write the return value to a size_t instead of an int.

Error handling isn't obvious either. The linux kernel does it the right way with error code returns and results in pointers, but that's not the obvious way at all.

Until you try to do something like zero a buffer to clear sensitive data just before it goes out of scope, and find that there's no way to do so that compilers actually have to obey.

Does Go have more dark corners than Nim, or are you just more used to Nim's dark corners?

I picked up Go when C# was my most familiar language, having dabbled in many over 30 years, and Go was the easiest to learn language I've ever dealt with. Plenty of things I don't like about it (like that nil exists! option types please!) but ease of learning and reading other people's code was amazing.

> I can't help to wonder, would it be so successful if it weren't for all the Google-hype and the push because of kubernetes?

Yes - Go would have been successful without the hype. There is a lot of underlying thoughtfulness to the design and language ergonomics when it comes to working in teams. Go lets you write simple code in a simple way - and that's the bulk of the code I read and write. The more hairy bits can be a bit unwieldy in Go, but it's still serviceable.

As a recovering Perl programmer, Go has an anti-TIMTOWTDI philosophy, and I love it. It absolutely demolishes a lot of bike-shedding: I bet gofmt alone has saved humanity millions of work-hours. For any system that requires a modicum of maintenance in a team setting, Go edges out most other languages: Go code is darn readable. For writing once-off/one and done systems, Go loses its biggest advantage.

"Easy" is relative. Go has been one of the easier languages to pick up and...go. I can read most go code that isn't my own without too much trouble. Modern java is also good in this regard, and has the added advantage of so many existing libraries.

Every language has warts and tradeoffs, many which have nothing to do with the language itself. Can it be hired for? Is is supported? What's the ecosystem like? How easily can it be deployed in a container?

Reply on news.ycombinator.com