5 ms·

>All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved

>All of these choices have deep, fundamental and serious problems -- both technical and environmental -- that are unlikely to ever be solved, but are all solved on the JVM. The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time. Programming language history sometimes seems pretty random. If Java hadn't hinted at the fantastic possibilities of the now completely defunct Applet technology, Smalltalk VMs might have captured the server-side with technologies very similar to what the JVM became many years later. They were arguably on the verge of doing that. It's ironic that Applets failed because of unsolved problems with the JVM that remain largely unsolved to this day (such as insane memory usage and laggy startup). And Java failing on the client side has created another problem unsolved by the JVM, which is code and skills sharing between client and server. That's one of the main reasons why node.js exists. And the one problem with the JVM that is probably unsolvable forever is the influence of its authority-seeking users on software design. That's what makes the JVM environment so utterly broken. Its culture of excessive complexity. I wouldn't dare to predict which flavor-of-the-month will fade and which one will dominate. It seems to be random and largely dependent on fantasies about future platforms unrelated to technological merit. We could have stuck with Lisp and Fortran and we wouldn't be any worse off than we are today. There is very little progress in our industry when it comes to programming environments.

pron 10y ago
> The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time. Perhaps, but they're not solved by any of the languages/platforms mentioned. > Smalltalk VMs might have captured the server-side with technologies very similar to what the JVM became many years later. They were arguably on the verge of doing that. Except that they were the same VMs (HotSpot was a Smalltalk VM). Smalltalk didn't lose; it just got repackaged as Java. > And Java failing on the client side has created another problem unsolved by the JVM, which is code and skills sharing between client and server. That's one of the main reasons why node.js exists. With that I agree, but JS has its own issues, and the other languages mentioned don't have it any easier in that regard. > And the one problem with the JVM that is probably unsolvable forever is the influence of its authority-seeking users on software design. That's what makes the JVM environment so utterly broken. Its culture of excessive complexity. Except that the JVM is by far the leading platform not only in conservative enterprises, but also among the thought-leaders and biggest technological innovators. I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software. As I said, for less-serious/smaller applications, Java and the JVM were not meant to be the first choices. We had VB and Delphi, then Python and Ruby, and now Node and whatever. It's the same market share, and I don't see evidence that the JVM is slipping.
- fauigerzigerk 10y ago
  >Perhaps, but they're not solved by any of the languages/platforms mentioned. Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Go also solves the value type issues that cause the JVMs excessive memory usage. Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is). >Except that they were the same VMs (HotSpot was a Smalltalk VM) Yes, but HotSpot is from 1999 whereas Java is came out in 1995 if I remember correctly. The initial Java VM was a bit of a throwback. >I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software. How do you define "serious"?
  - pron 10y ago
    > Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Nope. Tooting my own horn here, but the Quasar library on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game. > Go also solves the value type issues that cause the JVMs excessive memory usage True, but not only is that solvable, it is actually being solved on the JVM as we speak, and will be released long before Go will have caught up. OTOH, Go has some serious issues that are unlikely to ever be solved (its reliance on source-code instrumentation and lack of support for dynamic code manipulation; this has been demonstrated to be of great value for many server software systems). > Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is). This isn't any worse than any language that isn't JS. On the JVM you have Kotlin, Clojure and Scala, all also compile to JS, and those are just the leading options. > How do you define "serious"? Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade. .NET is pretty much Java's only serious competition there.
    - fauigerzigerk 10y ago
      >Tooting my own horn here, but Quasar on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game. If that is so then kudos to you. >it is actually being solved on the JVM as we speak Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid. >This isn't any worse than any language that isn't JS Yes, but JavaScript VMs do exist, they are serious competition for the JVM, also, as you say, as a compilation target, which makes it even worse for the JVM. The importance of "runs in the browser" is hard to overstate. And then there is WebAssembly on the horizon. >Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade. Many platforms have that covered. Your arguments in favor of the most widely used platform seem a bit tautological at times. By that standard, Java could never have gotten to the place it is in now.

pron 10y ago

> The problems that the JVM solves are solved by other platforms as well, and they were in fact already "solved" by the time Java was invented. Java was the prototypical flavor of the month language at one point in time. Perhaps, but they're not solved by any of the languages/platforms mentioned. > Smalltalk VMs might have captured the server-side with technologies very similar to what the JVM became many years later. They were arguably on the verge of doing that. Except that they were the same VMs (HotSpot was a Smalltalk VM). Smalltalk didn't lose; it just got repackaged as Java. > And Java failing on the client side has created another problem unsolved by the JVM, which is code and skills sharing between client and server. That's one of the main reasons why node.js exists. With that I agree, but JS has its own issues, and the other languages mentioned don't have it any easier in that regard. > And the one problem with the JVM that is probably unsolvable forever is the influence of its authority-seeking users on software design. That's what makes the JVM environment so utterly broken. Its culture of excessive complexity. Except that the JVM is by far the leading platform not only in conservative enterprises, but also among the thought-leaders and biggest technological innovators. I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software. As I said, for less-serious/smaller applications, Java and the JVM were not meant to be the first choices. We had VB and Delphi, then Python and Ruby, and now Node and whatever. It's the same market share, and I don't see evidence that the JVM is slipping.

fauigerzigerk 10y ago
>Perhaps, but they're not solved by any of the languages/platforms mentioned. Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Go also solves the value type issues that cause the JVMs excessive memory usage. Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is). >Except that they were the same VMs (HotSpot was a Smalltalk VM) Yes, but HotSpot is from 1999 whereas Java is came out in 1995 if I remember correctly. The initial Java VM was a bit of a throwback. >I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software. How do you define "serious"?
- pron 10y ago
  > Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Nope. Tooting my own horn here, but the Quasar library on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game. > Go also solves the value type issues that cause the JVMs excessive memory usage True, but not only is that solvable, it is actually being solved on the JVM as we speak, and will be released long before Go will have caught up. OTOH, Go has some serious issues that are unlikely to ever be solved (its reliance on source-code instrumentation and lack of support for dynamic code manipulation; this has been demonstrated to be of great value for many server software systems). > Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is). This isn't any worse than any language that isn't JS. On the JVM you have Kotlin, Clojure and Scala, all also compile to JS, and those are just the leading options. > How do you define "serious"? Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade. .NET is pretty much Java's only serious competition there.
  - fauigerzigerk 10y ago
    >Tooting my own horn here, but Quasar on the JVM has both models to the T, performs on-par with Go and blows Erlang/Elixir out of the water in its own game. If that is so then kudos to you. >it is actually being solved on the JVM as we speak Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid. >This isn't any worse than any language that isn't JS Yes, but JavaScript VMs do exist, they are serious competition for the JVM, also, as you say, as a compilation target, which makes it even worse for the JVM. The importance of "runs in the browser" is hard to overstate. And then there is WebAssembly on the horizon. >Critical software that is required to serve for a decade or more, and whose development costs exceed, say, one man-decade. Many platforms have that covered. Your arguments in favor of the most widely used platform seem a bit tautological at times. By that standard, Java could never have gotten to the place it is in now.