7 ms·

The thing is (from my experience): The things you list are actually not that important. VisualVM: Great, surely any VM should provide all of this through metri

The thing is (from my experience): The things you list are actually not that important. VisualVM: Great, surely any VM should provide all of this through metrics or profiling? I can count the number of times VisualVM has told me anything I didn't already know or diagnose through other means on one hand. Mission Control: Can't speak about it yet, haven't tried. (But I will!) IDEA: Meh. It's a Java IDE. (Well, it does Scala too and some other stuff, but the thing is I don't actually miss that when programming in, say, Haskell. I do have some auto-compile stuff in my Emacs, but frankly I get along fine without it.) Graal? Experimental at best. AFAIUI it's actually quite a lot slower than State of the Art JS engines. Don't get me wrong, it's still great to have, but it's not exactly a game-changer if I could just shell out to another JS engine and communicate via sockets. (Don't get me wrong, it's great research. It's also a new thing. I've been hearing this "JVM is great" meme for years and years.) SceneBuilder? Seriously? If you've got OpenGL, why would you bother? Yes, it's all in one package, but at what cost? You're having to program on a VM which lack even such basics as tail-call-optimization, value types, etc. (I realize some of these things may be coming, but I'm talking about now). Standardization, I'll give you, but frankly, has the level of standardization actually been tested seriously? Can you take any old compiled-for-1.5 app and run it on Azul's JVM? Can you do the reverse? (I'm not actually sure what kind of guarantees the TCK does provide. In any case and in my experience, most "ordinary" admins are running the unverified OpenJDK on their servers.) EDIT: Sorry, my spelling and grammar are atrocious when slightly drunk. I can only apologize. EDIT#2: Sorry, if there were any ninja edits. I'll try to stop now.

nickik 12y ago
What is the alternative? Haskell has a ok compiler and some fast weblibrary (I hear) but everybody agress that it cant compete on library and tooling. What else is there? That compets in performance, langauge and tooling?
- pjmlp 12y ago
  > What else is there? That compets in performance, langauge and tooling? Only .NET, I would say.
  - nickik 12y ago
    Well so really have the choice between on thing and the copy of it.
    - pjmlp 12y ago
      Yeah, but there are quite a few things that CLR is better at.
      - nickik 12y ago
        Well, I would agree if we are talking Java vs C# but platform in general im not quite sure. Rich Hickey for example said he had much more problems with the CLR and ended up mostly dropping it (could be diffrent knowdays). Competition can only be good, seams to me they are pretty much a wash at the moment. For me the JVM is much better because thats the prefered Clojure platform.
        pjmlp 12y ago
        - Ahead of time compilation since day 1. On JVM side you need to rely on commercial JVMs - Always JITs, there is no interpretation. Some JVMs do this as well. On the reference implementation, you need to set interpretation threshold to zero. - Tail Call Optimization. Eventually it will come to the JVM, after the bytecode verifier gets updated. - Reiffied generics. JVM 9 or maybe 10, depending on project evolution. - Value types. JVM 9 or maybe 10, depending on project evolution. - Better interop story. Oracle is now working on a JNI replacement for Java 9, maybe 10. - support for pointers in unsafe code - support for stack allocation - control over memory layouts > Rich Hickey for example said he had much more problems with the CLR and ended up mostly dropping it (could be diffrent knowdays). http://clojure.org/clojureclr http://clojure.org/clojureclr Quite up to date.
        vardump 12y ago
        Amen. Control over memory layouts. That would be truly useful for getting reasonable performance. And dropping memory required by the reference hell. Java doesn't support arrays for anything but basic types. Just boolean, byte, char, double, float, int, long. And (object|array) reference. Arrays in Java can have up to 2^31 entries. An array of 2^31 Objects takes 4 * 2^31 (8 GB), with compressed references. Plus of course 8 * 2^31 (8+16 GB) for java.lang.Objects that don't do anything. Smallest usable objects with at least one member would take 16 * 2^31 (8+32 GB) RAM. But this would prevent you from using compressed references (max 32GB heap), which would increase consumed memory to 16+32 GB. Like for example for 2 billion Integers. I realize you wouldn't store integer values this way, the point is integers are about the smallest useful objects imaginable. Java should have true object arrays (like C structs). And how do you align objects to say a cache line? You don't! It's hard to even avoid false sharing in Java. Practically impossible, because you can even get cross-object false sharing due to object memory alignment! Always JITs can be also a bad thing, why bother with code that is very rarely executed? If time it takes to compile + execute compiled version exceeds time it takes to interpret, why bother?
- lomnakkus 12y ago
  (I'll ignore the "language" bit, the JVM doesn't have "a language".) You still haven't stated exactly what it should compete with and what you imagine as the alternative to the JVM. Imagine I have absolutely no tooling, no language, no performance. Sell me on the JVM. Now imagine you could have the world. What would your ideal VM look like? "That compets in performance [...]": Well, C/C++ certainly competes in performance, Rust probably as well. Hell, even JS probably competes favorably on modern browsers. What I'm questioning here is really whether you can actually say "X is best for everything" or "X is best practice". (Where X was obviously the JVM.) (I just mentioned Haskell as an aside, let's not make that the primary point of this exchange.)
  - nickik 12y ago
    > Well, C/C++ certainly competes in performance It competes in performance if you are good at programming in it. It does not compete in securty, ease of use, buildsystems and complexity. Writing C/C++ code if you are not a export is basiclly just one big security hole, that is one of the major reasons. > Rust probably as well I love Rust but its no even anywere near what we are talking about > Hell, even JS probably competes favorably on modern browsers. Well 'on modern browsers' is very limiting. It cant compete on the server side, not even closly. > "X is best for everything" Nobody is claiming that, thats not what at issue. Its good at many things, and it specially good at server-side stuff.
    - jbergens 12y ago
      >> Hell, even JS probably competes favorably on modern browsers. > >Well 'on modern browsers' is very limiting. It cant compete on the server side, not even closly. I think JS is on the way to be a real competitor. The number of packages created for it grows faster than probably any other language. It is already fast on the server and more and more tools are being developed. If you count lack of static typing as show stopper then it can't compete. On the other hand Dart and TypeScript has types and might solve that part.
pjmlp 12y ago
VisualVM and Mission Control are widely used in the enterprise world. > IDEA: Meh. It's a Java IDE. (Well, it does Scala too and some other stuff, but the thing is I don't actually miss that when programming in, say, Haskell. I do have some auto-compile stuff in my Emacs, but frankly I get along fine without it.) I have been there, VI (not VIM) and Emacs. None of them can give me the experience I had with Smalltalk and that modern IDEs try to built upon. But to each its own. > Graal? Experimental at best. It is planned to eventually replace Hotspot and is better than it in escape analysis. JRuby is now using it. > SceneBuilder? Seriously? If you've got OpenGL, why would you bother? What has a RAD tool for GUI have to do with OpenGL? Do you write all your widgets by hand? > Standardization, I'll give you, but frankly, has the level of standardization actually been tested seriously? Yes. We develop on Windows and deploy on Oracle and IBM JVMs. I am aware of projects working on Aonix, JamaicaVM and many others. I don't know what "ordinary" admins are. We do Fortune 500 consulting usually with multi-site development.
- lomnakkus 12y ago
  (I don't think HN is conducive to point-by-point, nor do I necessarily think it's a good form of debate, so I'll just leave it at this:) I'm happy for you to do F500 consulting, but I don't think you've actually come up with anything persuasive. I can't say I've actually tried Smalltalk IDEs, but as I understand them they have a "repeatability" problem: could one and did you do distributed version control with your Smalltalk code? Other than copying images around? (I fully acknowledge that IDEs provide value for Java and Scala, but that's because those languages are fundamentally broken, from my perspective at least. This has nothing to do with the JVM, obviously.) Re: Graal. Yes, perhaps in future. I'm talking about now. I can postulate any number of wonderful things that'll happen in the future... that won't acutally happen. "Develop on Windows and deploy on X". If you have good enough QA you can get away with that, but I happened regularly on my (former) team that someone used "C:/whatever" as a path name in their configuration... which wouldn't work on Linux machines, obviously. Unfortunately not all of us have the luxury of working in an environment which has ample resources for QA and Integration Testing or what have you. I can fully agree that if you have enough resources, JVM is going to work just fine for you. I just don't think it's anywhere near optimal on the result/(effort+expense) scale.

nickik 12y ago

What is the alternative? Haskell has a ok compiler and some fast weblibrary (I hear) but everybody agress that it cant compete on library and tooling. What else is there? That compets in performance, langauge and tooling?

pjmlp 12y ago
> What else is there? That compets in performance, langauge and tooling? Only .NET, I would say.
- nickik 12y ago
  Well so really have the choice between on thing and the copy of it.
  - pjmlp 12y ago
    Yeah, but there are quite a few things that CLR is better at.
    - nickik 12y ago
      Well, I would agree if we are talking Java vs C# but platform in general im not quite sure. Rich Hickey for example said he had much more problems with the CLR and ended up mostly dropping it (could be diffrent knowdays). Competition can only be good, seams to me they are pretty much a wash at the moment. For me the JVM is much better because thats the prefered Clojure platform.
      - pjmlp 12y ago
        - Ahead of time compilation since day 1. On JVM side you need to rely on commercial JVMs - Always JITs, there is no interpretation. Some JVMs do this as well. On the reference implementation, you need to set interpretation threshold to zero. - Tail Call Optimization. Eventually it will come to the JVM, after the bytecode verifier gets updated. - Reiffied generics. JVM 9 or maybe 10, depending on project evolution. - Value types. JVM 9 or maybe 10, depending on project evolution. - Better interop story. Oracle is now working on a JNI replacement for Java 9, maybe 10. - support for pointers in unsafe code - support for stack allocation - control over memory layouts > Rich Hickey for example said he had much more problems with the CLR and ended up mostly dropping it (could be diffrent knowdays). http://clojure.org/clojureclr http://clojure.org/clojureclr Quite up to date.
        vardump 12y ago
        Amen. Control over memory layouts. That would be truly useful for getting reasonable performance. And dropping memory required by the reference hell. Java doesn't support arrays for anything but basic types. Just boolean, byte, char, double, float, int, long. And (object|array) reference. Arrays in Java can have up to 2^31 entries. An array of 2^31 Objects takes 4 * 2^31 (8 GB), with compressed references. Plus of course 8 * 2^31 (8+16 GB) for java.lang.Objects that don't do anything. Smallest usable objects with at least one member would take 16 * 2^31 (8+32 GB) RAM. But this would prevent you from using compressed references (max 32GB heap), which would increase consumed memory to 16+32 GB. Like for example for 2 billion Integers. I realize you wouldn't store integer values this way, the point is integers are about the smallest useful objects imaginable. Java should have true object arrays (like C structs). And how do you align objects to say a cache line? You don't! It's hard to even avoid false sharing in Java. Practically impossible, because you can even get cross-object false sharing due to object memory alignment! Always JITs can be also a bad thing, why bother with code that is very rarely executed? If time it takes to compile + execute compiled version exceeds time it takes to interpret, why bother?
lomnakkus 12y ago
(I'll ignore the "language" bit, the JVM doesn't have "a language".) You still haven't stated exactly what it should compete with and what you imagine as the alternative to the JVM. Imagine I have absolutely no tooling, no language, no performance. Sell me on the JVM. Now imagine you could have the world. What would your ideal VM look like? "That compets in performance [...]": Well, C/C++ certainly competes in performance, Rust probably as well. Hell, even JS probably competes favorably on modern browsers. What I'm questioning here is really whether you can actually say "X is best for everything" or "X is best practice". (Where X was obviously the JVM.) (I just mentioned Haskell as an aside, let's not make that the primary point of this exchange.)
- nickik 12y ago
  > Well, C/C++ certainly competes in performance It competes in performance if you are good at programming in it. It does not compete in securty, ease of use, buildsystems and complexity. Writing C/C++ code if you are not a export is basiclly just one big security hole, that is one of the major reasons. > Rust probably as well I love Rust but its no even anywere near what we are talking about > Hell, even JS probably competes favorably on modern browsers. Well 'on modern browsers' is very limiting. It cant compete on the server side, not even closly. > "X is best for everything" Nobody is claiming that, thats not what at issue. Its good at many things, and it specially good at server-side stuff.
  - jbergens 12y ago
    >> Hell, even JS probably competes favorably on modern browsers. > >Well 'on modern browsers' is very limiting. It cant compete on the server side, not even closly. I think JS is on the way to be a real competitor. The number of packages created for it grows faster than probably any other language. It is already fast on the server and more and more tools are being developed. If you count lack of static typing as show stopper then it can't compete. On the other hand Dart and TypeScript has types and might solve that part.

pjmlp 12y ago

VisualVM and Mission Control are widely used in the enterprise world. > IDEA: Meh. It's a Java IDE. (Well, it does Scala too and some other stuff, but the thing is I don't actually miss that when programming in, say, Haskell. I do have some auto-compile stuff in my Emacs, but frankly I get along fine without it.) I have been there, VI (not VIM) and Emacs. None of them can give me the experience I had with Smalltalk and that modern IDEs try to built upon. But to each its own. > Graal? Experimental at best. It is planned to eventually replace Hotspot and is better than it in escape analysis. JRuby is now using it. > SceneBuilder? Seriously? If you've got OpenGL, why would you bother? What has a RAD tool for GUI have to do with OpenGL? Do you write all your widgets by hand? > Standardization, I'll give you, but frankly, has the level of standardization actually been tested seriously? Yes. We develop on Windows and deploy on Oracle and IBM JVMs. I am aware of projects working on Aonix, JamaicaVM and many others. I don't know what "ordinary" admins are. We do Fortune 500 consulting usually with multi-site development.

lomnakkus 12y ago
(I don't think HN is conducive to point-by-point, nor do I necessarily think it's a good form of debate, so I'll just leave it at this:) I'm happy for you to do F500 consulting, but I don't think you've actually come up with anything persuasive. I can't say I've actually tried Smalltalk IDEs, but as I understand them they have a "repeatability" problem: could one and did you do distributed version control with your Smalltalk code? Other than copying images around? (I fully acknowledge that IDEs provide value for Java and Scala, but that's because those languages are fundamentally broken, from my perspective at least. This has nothing to do with the JVM, obviously.) Re: Graal. Yes, perhaps in future. I'm talking about now. I can postulate any number of wonderful things that'll happen in the future... that won't acutally happen. "Develop on Windows and deploy on X". If you have good enough QA you can get away with that, but I happened regularly on my (former) team that someone used "C:/whatever" as a path name in their configuration... which wouldn't work on Linux machines, obviously. Unfortunately not all of us have the luxury of working in an environment which has ample resources for QA and Integration Testing or what have you. I can fully agree that if you have enough resources, JVM is going to work just fine for you. I just don't think it's anywhere near optimal on the result/(effort+expense) scale.