4 ms·

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 els

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

by nickik 12y ago

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.