3 ms·

>Perhaps, but they're not solved by any of the languages/platforms mentioned. Go and Elixir do support concurrency/paralellism mechanisms that are not supporte

>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
    > Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid. Three or four, most likely. That's not a long time at all. > 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. I agree. If I were to pick the biggest threat to the JVM, it wouldn't be .NET or Go, but the JS ecosystem -- including wasm, which, although low-level at this time and more resembling LLVM, may grow to be a universal high-level VM one day. > Many platforms have that covered. I think almost none do. > By that standard, Java could never have gotten to the place it is in now. Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players, so it pretty much puts OCaml, Haskell and other academic languages out of the race. This leaves JS, Go, Erlang and .NET. Go seems unwilling to really study the market, so it will achieve success among the novelty seekers, who will then move on to the next thing; Erlang -- which has an amazing, inspiring design -- has no advantage over the JVM, and is at such a huge disadvantage in terms of resources, that the chance of it ever catching up is close to zero. This leaves .NET and JS, both with plenty of resources and a lot of industry involvement, and they are the only candidates that at this time appear to be able to unseat Java.
    - fauigerzigerk 10y ago
      >Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players I can't detect even the slightest influence of careful analysis on the rise and fall of technologies. If the creators of Java were planning anything, then it certainly wasn't what actually happened. Java failed completely in all areas it was originally built for (at least until Android, which happened very late in the game and is under threat). If I had to come up with a formula for success, it would look something like this: 10% novelty-seeking and merit + 10% corporate backing and tenacity of the creators + 10% platform advantage + 70% historical accident. In Java's history, that 70% historical accident was the web. No one planned for that to happen. All careful planners were taken completely off guard by the web. Looking at my formula, I would say Swift has a shot at going somewhere. But there are huge wildcards like WebAssembly, the future of Java on Android and of course all the unknown unknowns that are probably going to disrupt all careful analysis including mine.
- pjmlp 10y ago
  > True, but not only is that solvable, it is actually being solved on the JVM as we speak I am looking forward for it, but with Brian Goetz speaking about Java 10+ (note the plus) and Oracle not having a programming language culture, I am not sure they will ever happen in the near future. IBM also doesn't talk any more about Packed Objects and I don't know if anyone is really paying attention to Gil efforts promoting object layout. Even the Scala guys are now researching into Scala Native.
  - deleted 10y ago
    [deleted]
  - bitmapbrother 10y ago
    >IBM also doesn't talk any more about Packed Objects Of course they do. You're just not looking in the right place. http://mail.openjdk.java.net/pipermail/panama-spec-experts/ http://mail.openjdk.java.net/pipermail/panama-spec-experts/
    - pjmlp 10y ago
      I know that list. 1 to 2 emails per month, for something that might eventually come in Java 10 or later isn't talking about it.

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
  > Right, it is being worked on and it will be worked on for many years to come before it gets released I'm afraid. Three or four, most likely. That's not a long time at all. > 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. I agree. If I were to pick the biggest threat to the JVM, it wouldn't be .NET or Go, but the JS ecosystem -- including wasm, which, although low-level at this time and more resembling LLVM, may grow to be a universal high-level VM one day. > Many platforms have that covered. I think almost none do. > By that standard, Java could never have gotten to the place it is in now. Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players, so it pretty much puts OCaml, Haskell and other academic languages out of the race. This leaves JS, Go, Erlang and .NET. Go seems unwilling to really study the market, so it will achieve success among the novelty seekers, who will then move on to the next thing; Erlang -- which has an amazing, inspiring design -- has no advantage over the JVM, and is at such a huge disadvantage in terms of resources, that the chance of it ever catching up is close to zero. This leaves .NET and JS, both with plenty of resources and a lot of industry involvement, and they are the only candidates that at this time appear to be able to unseat Java.
  - fauigerzigerk 10y ago
    >Java (and by that I mean mostly the JVM) were designed after careful analysis of market needs. This kind of analysis is only available to certain players I can't detect even the slightest influence of careful analysis on the rise and fall of technologies. If the creators of Java were planning anything, then it certainly wasn't what actually happened. Java failed completely in all areas it was originally built for (at least until Android, which happened very late in the game and is under threat). If I had to come up with a formula for success, it would look something like this: 10% novelty-seeking and merit + 10% corporate backing and tenacity of the creators + 10% platform advantage + 70% historical accident. In Java's history, that 70% historical accident was the web. No one planned for that to happen. All careful planners were taken completely off guard by the web. Looking at my formula, I would say Swift has a shot at going somewhere. But there are huge wildcards like WebAssembly, the future of Java on Android and of course all the unknown unknowns that are probably going to disrupt all careful analysis including mine.
pjmlp 10y ago
> True, but not only is that solvable, it is actually being solved on the JVM as we speak I am looking forward for it, but with Brian Goetz speaking about Java 10+ (note the plus) and Oracle not having a programming language culture, I am not sure they will ever happen in the near future. IBM also doesn't talk any more about Packed Objects and I don't know if anyone is really paying attention to Gil efforts promoting object layout. Even the Scala guys are now researching into Scala Native.
- deleted 10y ago
  [deleted]
- bitmapbrother 10y ago
  >IBM also doesn't talk any more about Packed Objects Of course they do. You're just not looking in the right place. http://mail.openjdk.java.net/pipermail/panama-spec-experts/ http://mail.openjdk.java.net/pipermail/panama-spec-experts/
  - pjmlp 10y ago
    I know that list. 1 to 2 emails per month, for something that might eventually come in Java 10 or later isn't talking about it.