4 ms·

People should use Go and forget all the licensing issues. Bonus: happy developers!

rezeroed 8y ago
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).
sheeshkebab 8y ago
I don’t see old releases of go supported too long either, and google is rather firmly in control of that language.
SmellyGeekBoy 8y ago
Because Google would never dream of doing anything evil?
solatic 8y ago
Go hasn't had a history yet of breaking compatibility with earlier releases. Wait until Go 2 comes out, then we'll see how much Google wants to maintain long-term support. Two hints: it'll be at least as long as necessary for Google to port all of its Go 1 code to Go 2, and it won't be much longer than support for Inbox or Google Reader. And a further hint, Google will figure out how to port all of its Go 1 code to Go 2 much faster than you think, and your company will not be able to port its million-line Go codebase nearly as quickly.
- kodablah 8y ago
  A fourth hint, it won't break backwards compatibility and your post is a bunch of speculation and guesses.
- pkhagah 8y ago
  One of the stated goals of Go2 is forward and backward compatibility. We have to see how well this pans out when Go2 is released. > Go 2 must also bring along all the existing Go 1 source code. We must not split the Go ecosystem. Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years. We'll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part. https://blog.golang.org/toward-go2 https://blog.golang.org/toward-go2
  - solatic 8y ago
    It's an admirable goal, and we'll see whether it works out in practice. Remember, this entire thread is about JDK updates. Java also explicitly has forward and backward compatibility as a design goal, but then sun.misc.Unsafe turned out to be a bigger headache than most people thought, and upgrading to Java 11 will require many companies to update core dependencies, and unfortunately a lot of companies would rather pay for Java 8 support than put in the maintenance effort. Even if there's 99% compatibility, if upgrading requires anything more than updating the compiler, even if it's just adding a runtime flag and the upgrade effort should be minimal, you're going to see significant resistance from companies with large codebases.
topbanana 8y ago
.net core would be a better sideways step IMO
repolfx 8y ago
What happens when a company steps up and says, "we now offer commercial support for Golang"? Do you suddenly apply the same rationale because someone might download their commercial version of Go by accident?

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).

sheeshkebab 8y ago

I don’t see old releases of go supported too long either, and google is rather firmly in control of that language.

SmellyGeekBoy 8y ago

Because Google would never dream of doing anything evil?

solatic 8y ago

Go hasn't had a history yet of breaking compatibility with earlier releases. Wait until Go 2 comes out, then we'll see how much Google wants to maintain long-term support. Two hints: it'll be at least as long as necessary for Google to port all of its Go 1 code to Go 2, and it won't be much longer than support for Inbox or Google Reader. And a further hint, Google will figure out how to port all of its Go 1 code to Go 2 much faster than you think, and your company will not be able to port its million-line Go codebase nearly as quickly.

kodablah 8y ago
A fourth hint, it won't break backwards compatibility and your post is a bunch of speculation and guesses.
pkhagah 8y ago
One of the stated goals of Go2 is forward and backward compatibility. We have to see how well this pans out when Go2 is released. > Go 2 must also bring along all the existing Go 1 source code. We must not split the Go ecosystem. Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years. We'll have to figure out exactly how to do that; automated tooling like go fix will certainly play a part. https://blog.golang.org/toward-go2 https://blog.golang.org/toward-go2
- solatic 8y ago
  It's an admirable goal, and we'll see whether it works out in practice. Remember, this entire thread is about JDK updates. Java also explicitly has forward and backward compatibility as a design goal, but then sun.misc.Unsafe turned out to be a bigger headache than most people thought, and upgrading to Java 11 will require many companies to update core dependencies, and unfortunately a lot of companies would rather pay for Java 8 support than put in the maintenance effort. Even if there's 99% compatibility, if upgrading requires anything more than updating the compiler, even if it's just adding a runtime flag and the upgrade effort should be minimal, you're going to see significant resistance from companies with large codebases.

topbanana 8y ago

.net core would be a better sideways step IMO

repolfx 8y ago

What happens when a company steps up and says, "we now offer commercial support for Golang"? Do you suddenly apply the same rationale because someone might download their commercial version of Go by accident?