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?