4 ms·

Java to Go - two extremes, too bloated to too simplistic - I'd look for something between. If your projects aren't interesting an interesting language can help

Java to Go - two extremes, too bloated to too simplistic - I'd look for something between. If your projects aren't interesting an interesting language can help you endure. If your projects and your language isn't interesting then tedium.

vorg 8y ago
You needn't worry about Go being too simplistic for much longer. It looks like they're going to add a bloated form of generics soon, with something called "contracts" that's almost the same as "interfaces" but a little different. A few versions back, Go added "aliases" of types, but it was almost aliases of anything -- only intense community pressure prevented that bloat. And having had a special rule in its short-form declarations to make error handling a little terser, Go is looking at bringing another syntactic shortcut called "handle-check" to bring a little more error-handling tersity. Go's simplicity will be gone in a few short years.
- lllr_finger 8y ago
  It took 10 years to move the needle on generics and better error handling, and the draft solutions for both still smell of minimum usefulness/minimum complexity in the language. Whether that's a good approach is up to the individual, but I don't see Go 2 ending up as some unwieldy monstrosity. I'm curious how the proposal for generics is "bloated" - especially as compared to something like C# or Rust.
  - vorg 8y ago
    Just because the currently-proposed Go generics is less bloated than those of C# and Rust doesn't mean it isn't "bloated" compared to Go 1.11. And I wouldn't call the description of contracts in the discussion document from last month "minimum complexity".
oblio 8y ago
Java can be remarkably bloat-free if you so choose. The problem is that in most places where Java is used, it's used because of its stability, ergo that stability mentality will be pervasive and the code base will probably be huge and old. But if you have a greenfield project and some decent Java developers, you'd be surprised what you can do with Java if you're willing to avoid the common pitfalls (J2EE, Spring).

vorg 8y ago

You needn't worry about Go being too simplistic for much longer. It looks like they're going to add a bloated form of generics soon, with something called "contracts" that's almost the same as "interfaces" but a little different. A few versions back, Go added "aliases" of types, but it was almost aliases of anything -- only intense community pressure prevented that bloat. And having had a special rule in its short-form declarations to make error handling a little terser, Go is looking at bringing another syntactic shortcut called "handle-check" to bring a little more error-handling tersity. Go's simplicity will be gone in a few short years.

lllr_finger 8y ago
It took 10 years to move the needle on generics and better error handling, and the draft solutions for both still smell of minimum usefulness/minimum complexity in the language. Whether that's a good approach is up to the individual, but I don't see Go 2 ending up as some unwieldy monstrosity. I'm curious how the proposal for generics is "bloated" - especially as compared to something like C# or Rust.
- vorg 8y ago
  Just because the currently-proposed Go generics is less bloated than those of C# and Rust doesn't mean it isn't "bloated" compared to Go 1.11. And I wouldn't call the description of contracts in the discussion document from last month "minimum complexity".

oblio 8y ago

Java can be remarkably bloat-free if you so choose. The problem is that in most places where Java is used, it's used because of its stability, ergo that stability mentality will be pervasive and the code base will probably be huge and old. But if you have a greenfield project and some decent Java developers, you'd be surprised what you can do with Java if you're willing to avoid the common pitfalls (J2EE, Spring).