48 ms·

You should check out SBCL, it's competitive.

pron 7y ago
It isn't. Perhaps you haven't seen what the JVM can do lately. It's got JIT compilers that do this[1], GCs that are getting close to 1ms max pause times on terabytes of heap [2], and low-overhead, in-production deep profiling [3]. Not to mention all of the classic capabilities of the JVM like hot code redefinition and exceptional monitoring. Lots of applications can certainly manage well without some or even all those things, and some want other tradeoffs (like no warmup or lower RAM footprint), but these days it's hard to compete with the JVM where it's strong. The technological gap between it and other runtimes is only growing. [1]: https://twitter.com/ChrisGSeaton/status/619885182104043520 https://twitter.com/ChrisGSeaton/status/619885182104043520 [2]: http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pdf http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pd... [3]: https://craftingjava.com/using-java-flight-recorder-with-openjdk-11/ https://craftingjava.com/using-java-flight-recorder-with-ope...
- User23 7y ago
  And yet it still can't even do TCO
  - pron 7y ago
    Right. Different platforms have different priorities. But tail calls will be coming to the JVM eventually.
  - preordained 7y ago
    This is the dumbest thing in the universe (in context of a Clojure discussion) that I keep seeing parroted over and over. So you have to type "recur <args>" instead of the actual function name + <args> for the exact same effect. If you can get over that aesthetic "sin" then you have your TCO in effect. I don't even find it mildly inconvenient...and even prefer the "shortcut" syntax vs explicitly repeating my function name.
pepper_sauce 7y ago
Do you have appropriate benchmarks? I would appreciate seeing the comparison.
- DannyB2 7y ago
  Yes, benchmarks. But it's not just benchmarks. It's capabilities. He should please provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities.
  - igouy 7y ago
    > provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities How many weeks work do you imagine that would be?
    - DannyB2 7y ago
      My point: if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well. While no language / platform / os / etc is perfect, JVM as a managed runtime platform is hard to beat. More than two decades of research in its JIT compilers, and multiple GC implementations with various knobs and dials for tuning and monitoring. Battle tested. Someone mentioned SBCL. While I am a fan of Common Lisp, and generally all Lisps, I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload -- and see how well it holds up. Just an example: You can Google for this, but in 2012 Twitter switched from Ruby on Rails to Java. They have YouTube videos explaining their change over. Basic reasons: performance and scalability. They have to handle BILLIONS of tweets per day and route each one to multiple places with notifications in near real time.
      - lispm 7y ago
        > I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload That's nothing SBCL can do, but one can save an executable and start that in a subsecond without the need for a terabyte of RAM. Generally there is a lot of stuff in the JVM which makes it less attractive as runtime for Lisp: more complex code loading via 'class loaders', lack of support for memory representation of Lisp's data types (like CLOS objects, which are more dynamic than Java classes), lack of TCO, lack of easy AOT compilation, lack of easy image dumps, lack of resumeable exceptions, ... And in 2019 something like Eclipse still is a bit clunky to run on my 8 core Xeon - part of the reason could be a less than great GUI implementation. In IntelliJ I need to restart my IDE for every simple plugin... probably features like live-updating haven't made it yet into popular apps.
User23 7y ago
http://www.chiark.greenend.org.uk/doc/cmucl-docs/compiler-hint.html http://www.chiark.greenend.org.uk/doc/cmucl-docs/compiler-hi... is mostly applicable to SBCL last I checked. It gives an idea of what kind of cleverness the compiler can undertake.

pron 7y ago

It isn't. Perhaps you haven't seen what the JVM can do lately. It's got JIT compilers that do this[1], GCs that are getting close to 1ms max pause times on terabytes of heap [2], and low-overhead, in-production deep profiling [3]. Not to mention all of the classic capabilities of the JVM like hot code redefinition and exceptional monitoring. Lots of applications can certainly manage well without some or even all those things, and some want other tradeoffs (like no warmup or lower RAM footprint), but these days it's hard to compete with the JVM where it's strong. The technological gap between it and other runtimes is only growing. [1]: https://twitter.com/ChrisGSeaton/status/619885182104043520 https://twitter.com/ChrisGSeaton/status/619885182104043520 [2]: http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pdf http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pd... [3]: https://craftingjava.com/using-java-flight-recorder-with-openjdk-11/ https://craftingjava.com/using-java-flight-recorder-with-ope...

User23 7y ago
And yet it still can't even do TCO
- pron 7y ago
  Right. Different platforms have different priorities. But tail calls will be coming to the JVM eventually.
- preordained 7y ago
  This is the dumbest thing in the universe (in context of a Clojure discussion) that I keep seeing parroted over and over. So you have to type "recur <args>" instead of the actual function name + <args> for the exact same effect. If you can get over that aesthetic "sin" then you have your TCO in effect. I don't even find it mildly inconvenient...and even prefer the "shortcut" syntax vs explicitly repeating my function name.

pepper_sauce 7y ago

Do you have appropriate benchmarks? I would appreciate seeing the comparison.

DannyB2 7y ago
Yes, benchmarks. But it's not just benchmarks. It's capabilities. He should please provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities.
- igouy 7y ago
  > provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities How many weeks work do you imagine that would be?
  - DannyB2 7y ago
    My point: if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well. While no language / platform / os / etc is perfect, JVM as a managed runtime platform is hard to beat. More than two decades of research in its JIT compilers, and multiple GC implementations with various knobs and dials for tuning and monitoring. Battle tested. Someone mentioned SBCL. While I am a fan of Common Lisp, and generally all Lisps, I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload -- and see how well it holds up. Just an example: You can Google for this, but in 2012 Twitter switched from Ruby on Rails to Java. They have YouTube videos explaining their change over. Basic reasons: performance and scalability. They have to handle BILLIONS of tweets per day and route each one to multiple places with notifications in near real time.
    - lispm 7y ago
      > I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload That's nothing SBCL can do, but one can save an executable and start that in a subsecond without the need for a terabyte of RAM. Generally there is a lot of stuff in the JVM which makes it less attractive as runtime for Lisp: more complex code loading via 'class loaders', lack of support for memory representation of Lisp's data types (like CLOS objects, which are more dynamic than Java classes), lack of TCO, lack of easy AOT compilation, lack of easy image dumps, lack of resumeable exceptions, ... And in 2019 something like Eclipse still is a bit clunky to run on my 8 core Xeon - part of the reason could be a less than great GUI implementation. In IntelliJ I need to restart my IDE for every simple plugin... probably features like live-updating haven't made it yet into popular apps.

User23 7y ago

http://www.chiark.greenend.org.uk/doc/cmucl-docs/compiler-hint.html http://www.chiark.greenend.org.uk/doc/cmucl-docs/compiler-hi... is mostly applicable to SBCL last I checked. It gives an idea of what kind of cleverness the compiler can undertake.