Four years of Go

Uhh... The hype is there for a reason.

It is inherently portable, because the bytecode can be run everywhere you have a JVM. You don't need to compile for every platform you wan't to run your software in, or muck around with cross-compilers. True, you can do plattform-spesific things in any language, but the Java standards library is almost entirely cross-plattform. In this way, Java really is as cross-platform as it gets.

The language itself is more secure. Buffer overflow? Forget about it. Undefined behaviour? Forget about it. Wierd stuff happening due to pointer arithmetick. Forget about it. Memory leaks? Forget about it, (well, almost).

Why can't it be used for client software? A JVM language can be used for anything that doesn't require minimal use of memory or short start-up time. Any program you write that will be running for more than 10 seconds and don't run in a memory strained environment, fits Java rather well.

Java is also easier to learn and reason about IMHO than C++.

Java today is the easier, safer, more portable but slower and memory-hungry edition of C++. Which is why there is a hype. Altough that hype is slowly dying, due to Java (the language, not the vm and ecosystem) being outdated compared to it's competitors.

This is true but, from my experience with developers (not to mention HR/hiring managers) at my own company and elsewhere there is a prevalent attitude that language is the basis of "What You Do". I agree that attitude is totally wrong but a lot of places seem to have this backwards prejudice about hiring good developers and chucking them headfirst into a language or technology they haven't already proven they know.

"There was and continues to remain NOTHING that compares to the Java platform."

... today. Thrownaway2424 said (my emphasis) "Java in the 90s was a spectacular con job that millions of developers and managers bought hook, line, and sinker."

This was true. Sun purchased Java's popularity. It did not even come close to living up to the hype in the first few years. I could segfault it without much difficulty using Swing, and I was hardly using it for anything (school assignment!). I was not a sophisticated developer at the time. I should not have been able to do that.

It is also true that through tenacity and dedication, Java eventually did live up to its promises. But that came later.

My experience with Go was bizarre -- I loved programming in it, but I don't understand why!

For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem to agree that it's always superior to have a REPL than to be forced to live without.

Lots of people love programming in Golang (I especially love to write distributed systems with it!) yet it probably won't ever offer us a REPL. That must mean one of two possibilities are true, both of which are bizarre: either 1) we love Go in spite of being limited by not having a REPL, or 2) having a REPL isn't as big of a deal as everyone thought.

So I'd like to ask all of you: Do we love Go in spite of being held back by it? If so, then what are the factors that cause us to decide that using Go is worth giving up programming power? After all, each of us are choosing to use Go in lieu of more powerful languages. So why do we choose to give up programming power?

Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? That seems plausible. It's at least as plausible as "it's a good idea to give up REPLs for static typing."

Go is wonderful to work with. But I'm so confused why it feels wonderful to me. I know I love programming in it, but once I start thinking about the implications, I start to wonder: Isn't giving up power a bad thing, and therefore choosing to use Go == choosing to be forever held back by its deficits, and therefore it's a bad decision? Or is it true that having every possible language feature available to you ("maximum potential programming power," i.e. as far above Blub as possible) isn't as big a deal as we all thought?

This pg essay talks about why it's worthwhile to have as much power as possible: http://www.paulgraham.com/avg.html (search for Blub Paradox) .... So either he's wrong, or we're ignoring him even though he's right. Which is it?

EDIT: There are other limitations besides lacking a REPL, e.g. there's no dynamic typing. It seems like we should try to figure out why it's a good idea to give up any programming power at all.

I think it's mostly a case of storage systems being a very core, important part of any software stack. If shit goes wrong at that level you're really screwed, so it takes longer to develop that kind of software and also longer for people to trust it enough to use it for serious things.

But there is plenty of action at that level in the Go community, and as distributed consensus libraries like go-raft mature it will only become easier to write and trust such software in Go.