5 ms·

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

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.
- pron 7y ago
  > but one can save an executable and start that in a subsecond without the need for a terabyte of RAM. A few tens of magabytes maybe and the JVM runs a complete Hello World in about 60ms, but yeah, Clojure does a lot of work on startup. It's more of a Clojure issue than a JVM issue, though. It's true that HotSpot is mostly designed for long-running applications. Other JVMs -- like Substrate VM (AKA Graal native image, which isn't quite a JVM yet) and Excelsior JET give you AOT compilation (no warmup). > makes it less attractive as runtime for Lisp I think Clojurists (which probably outnumber all other professional Lispers combined several times over) would disagree. I'm sure there are use cases where you'd like to use Lisp and HotSpot is not the right choice, but it seems like those cases are vastly outnumbered by the cases where it is. Domains where HotSpot is certainly not the right choice are usually either client-side web or domains where C/C++ dominate. > lack of TCO, lack of resumeable exceptions Delimited continuations and eventually tail calls are coming as part of Project Loom (https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/). > lack of easy image dumps HotSpot's monitoring, management and observability are almost unmatched (maybe Smalltalk is somewhat better in some regards, and BEAM in some others). Whatever you may be lacking on that front is probably offset by something probably even more valuable (these capabilities have been designed over the past decades to suit the needs of millions of developers running huge backbones). I'm not saying that HotSpot is always the best tool for the job, but it's the best tool for the job for a huge portion of the software industry. > 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. You don't need to use a Java IDE if you want to write Clojure, although the Java IDEs are also pretty unmatched -- a matter of getting used to.
  - lispm 7y ago
    > Other JVMs So I need to switch to exotic JVMs to get better performance? > I think Clojurists (which probably outnumber all other professional Lispers combined several times over) would disagree Does the number matter, since most of them have a) never used Lisp nor b) do they know anything about Lisp implementation? Things like 'no TCO' in the JVM are no question of the number of people using it, it's simply a fact. If the JVM would be a better match, then Lisp implementations on it would have a better start-up time - like most Lisp runtimes have. There are many reasons to use the JVM, but good support in the JVM for Lisp implementations is not one of the strong points. > Delimited continuations and eventually tail calls are coming as part of Project Loom Which means, after reading the linked doc, that neither resumeable exceptions nor TCO are in JVM, neither currently nor in the near future. Now the usual arguments about TCO are: a) one does not need TCO b) it makes tracing difficult c) it's a security problem d) we can do recursive self-calls e) a future version of the JVM will provide annotatations for tail calls f) using TCO would provide interop problems with JVM code... etc etc. The fact remains: TCO is not supported by the JVM, while this capability is a part of many other runtimes. > probably even more valuable (these capabilities have been designed over the past decades to suit the needs of millions of developers running huge backbones). That's all great, but I don't develop huge backbones all the time. > I'm not saying that HotSpot is always the best tool for the job Your original claim was this: 'if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well.' We are now talking about capabilities like full TCO and the JVM simply does not provide it. It currently provides no TCO at all. > You don't need to use a Java IDE It's not about what I need, it's that capabilities like extending the IDE on the fly are still not available in an IDE like IntelliJ - why? After downloading a plugin, it wants to restart the IDE. Something which a typical Lisp system on a Lisp runtime brings for free, because of its capabilities.
    - deleted 7y ago
      [deleted]
    - pron 7y ago
      > So I need to switch to exotic JVMs to get better performance? Depends what you mean by "better". HotSpot is optimized for peak performance (which is higher than that of other Lisp runtimes), and to suit the needs of server-side development. Other VMs target other uses -- fast startup, embedded etc. > If the JVM would be a better match, then Lisp implementations on it would have a better start-up time - like most Lisp runtimes have. It's already a better match, because that's what most Lispers prefer. If you mean it could be even better than it is, then I agree. I also agree that it's not the best match for, say, Racket. Now, it's perfectly fine if you prefer Racket over Clojure, but most people prefer Clojure to Racket, partly because overall the runtime gives them more of what's most important to them. Would it be cool if the JVM had more features that would allow it to be a better match for Racket? Sure. > Does the number matter Yes, because Clojure is the most popular Lisp, the features it has are probably the ones most important to Lispers. > Things like 'no TCO' in the JVM are no question of the number of people using it, it's simply a fact. Yes, but how much not having TCO matters can be answered by popularity. That people use Clojure much more than they use Lisps on runtimes with TCO suggests that other things matter to them more. > neither currently nor in the near future Currently, no. Near future -- probably. I'm the technical lead for that project, and it's very likely that delimited continuations would arrive soon (in fact, you can already build the prototype today, and early access builds will be available in a couple of months). > Now the usual arguments about TCO are ... Well, as it's being addressed only now rather than, say, 10 years ago means that it's not a top priority, but judged to justify some reasonable effort at this point in time. > TCO is not supported by the JVM, while this capability is a part of many other runtimes. True, but the fact remains that the totality of capabilities of the JVM is considered more attractive by more people than that of most other runtimes. > That's all great, but I don't develop huge backbones all the time. I am not saying that you, personally, should definitely use the JVM, only that it seems that the JVM is a great platform for many languages, including Lisps, and that the use cases it targets are very desired. > Your original claim was this ... I believe I also said that I mean capabilities for the domain HotSpot targets. Obviously, other things may be more attractive for, say, embedded software. > It currently provides no TCO at all. There are other things it doesn't provide. But by comparing capabilities I did not mean one by one, but the totality of those of one runtime vs. those of the others. > It's not about what I need, it's that capabilities like extending the IDE on the fly are still not available in an IDE like IntelliJ - why? After downloading a plugin, it wants to restart the IDE. Something which a typical Lisp system on a Lisp runtime brings for free, because of its capabilities. No, that capability is definitely there. I'm guessing the IDE authors just didn't think it's worthwhile to use. NetBeans, for example, doesn't require a restart after downloading plugins (or, rather, rarely does).

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.

pron 7y ago
> but one can save an executable and start that in a subsecond without the need for a terabyte of RAM. A few tens of magabytes maybe and the JVM runs a complete Hello World in about 60ms, but yeah, Clojure does a lot of work on startup. It's more of a Clojure issue than a JVM issue, though. It's true that HotSpot is mostly designed for long-running applications. Other JVMs -- like Substrate VM (AKA Graal native image, which isn't quite a JVM yet) and Excelsior JET give you AOT compilation (no warmup). > makes it less attractive as runtime for Lisp I think Clojurists (which probably outnumber all other professional Lispers combined several times over) would disagree. I'm sure there are use cases where you'd like to use Lisp and HotSpot is not the right choice, but it seems like those cases are vastly outnumbered by the cases where it is. Domains where HotSpot is certainly not the right choice are usually either client-side web or domains where C/C++ dominate. > lack of TCO, lack of resumeable exceptions Delimited continuations and eventually tail calls are coming as part of Project Loom (https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/). > lack of easy image dumps HotSpot's monitoring, management and observability are almost unmatched (maybe Smalltalk is somewhat better in some regards, and BEAM in some others). Whatever you may be lacking on that front is probably offset by something probably even more valuable (these capabilities have been designed over the past decades to suit the needs of millions of developers running huge backbones). I'm not saying that HotSpot is always the best tool for the job, but it's the best tool for the job for a huge portion of the software industry. > 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. You don't need to use a Java IDE if you want to write Clojure, although the Java IDEs are also pretty unmatched -- a matter of getting used to.
- lispm 7y ago
  > Other JVMs So I need to switch to exotic JVMs to get better performance? > I think Clojurists (which probably outnumber all other professional Lispers combined several times over) would disagree Does the number matter, since most of them have a) never used Lisp nor b) do they know anything about Lisp implementation? Things like 'no TCO' in the JVM are no question of the number of people using it, it's simply a fact. If the JVM would be a better match, then Lisp implementations on it would have a better start-up time - like most Lisp runtimes have. There are many reasons to use the JVM, but good support in the JVM for Lisp implementations is not one of the strong points. > Delimited continuations and eventually tail calls are coming as part of Project Loom Which means, after reading the linked doc, that neither resumeable exceptions nor TCO are in JVM, neither currently nor in the near future. Now the usual arguments about TCO are: a) one does not need TCO b) it makes tracing difficult c) it's a security problem d) we can do recursive self-calls e) a future version of the JVM will provide annotatations for tail calls f) using TCO would provide interop problems with JVM code... etc etc. The fact remains: TCO is not supported by the JVM, while this capability is a part of many other runtimes. > probably even more valuable (these capabilities have been designed over the past decades to suit the needs of millions of developers running huge backbones). That's all great, but I don't develop huge backbones all the time. > I'm not saying that HotSpot is always the best tool for the job Your original claim was this: 'if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well.' We are now talking about capabilities like full TCO and the JVM simply does not provide it. It currently provides no TCO at all. > You don't need to use a Java IDE It's not about what I need, it's that capabilities like extending the IDE on the fly are still not available in an IDE like IntelliJ - why? After downloading a plugin, it wants to restart the IDE. Something which a typical Lisp system on a Lisp runtime brings for free, because of its capabilities.
  - deleted 7y ago
    [deleted]
  - pron 7y ago
    > So I need to switch to exotic JVMs to get better performance? Depends what you mean by "better". HotSpot is optimized for peak performance (which is higher than that of other Lisp runtimes), and to suit the needs of server-side development. Other VMs target other uses -- fast startup, embedded etc. > If the JVM would be a better match, then Lisp implementations on it would have a better start-up time - like most Lisp runtimes have. It's already a better match, because that's what most Lispers prefer. If you mean it could be even better than it is, then I agree. I also agree that it's not the best match for, say, Racket. Now, it's perfectly fine if you prefer Racket over Clojure, but most people prefer Clojure to Racket, partly because overall the runtime gives them more of what's most important to them. Would it be cool if the JVM had more features that would allow it to be a better match for Racket? Sure. > Does the number matter Yes, because Clojure is the most popular Lisp, the features it has are probably the ones most important to Lispers. > Things like 'no TCO' in the JVM are no question of the number of people using it, it's simply a fact. Yes, but how much not having TCO matters can be answered by popularity. That people use Clojure much more than they use Lisps on runtimes with TCO suggests that other things matter to them more. > neither currently nor in the near future Currently, no. Near future -- probably. I'm the technical lead for that project, and it's very likely that delimited continuations would arrive soon (in fact, you can already build the prototype today, and early access builds will be available in a couple of months). > Now the usual arguments about TCO are ... Well, as it's being addressed only now rather than, say, 10 years ago means that it's not a top priority, but judged to justify some reasonable effort at this point in time. > TCO is not supported by the JVM, while this capability is a part of many other runtimes. True, but the fact remains that the totality of capabilities of the JVM is considered more attractive by more people than that of most other runtimes. > That's all great, but I don't develop huge backbones all the time. I am not saying that you, personally, should definitely use the JVM, only that it seems that the JVM is a great platform for many languages, including Lisps, and that the use cases it targets are very desired. > Your original claim was this ... I believe I also said that I mean capabilities for the domain HotSpot targets. Obviously, other things may be more attractive for, say, embedded software. > It currently provides no TCO at all. There are other things it doesn't provide. But by comparing capabilities I did not mean one by one, but the totality of those of one runtime vs. those of the others. > It's not about what I need, it's that capabilities like extending the IDE on the fly are still not available in an IDE like IntelliJ - why? After downloading a plugin, it wants to restart the IDE. Something which a typical Lisp system on a Lisp runtime brings for free, because of its capabilities. No, that capability is definitely there. I'm guessing the IDE authors just didn't think it's worthwhile to use. NetBeans, for example, doesn't require a restart after downloading plugins (or, rather, rarely does).