5 ms·

I don’t ...

macintux 7y ago
The JVM is a kitchen sink environment. The BEAM is very opinionated. I would expect the VM built from the ground up to support a specific programming model to be superior at doing just that.
- macintux 7y ago
  In addition, every library written for the BEAM in any language is designed for message passing and the actor model. Clojure would not have that advantage on the JVM.
  - didibus 7y ago
    Clojure doesn't use the actor model...
    - macintux 7y ago
      Which was part of the discussion at the linked article.
      - didibus 7y ago
        Oh okay, sorry I misunderstood your comment the first time. The rationale for why Rich Hickey didn't go for the actor model are actually documented here: https://clojure.org/about/state https://clojure.org/about/state I agree with you, that the JVM also would have probably made it more difficult to incorporate and leverage, though Scala seems to have pretty successfully done that, and Fantom has gone that route as well successfully (though the language is niche) on the JVM. So I'm not totally sure either.
- pron 7y ago
  BEAM is a wonderful VM, but calling it "optimized" for anything is problematic. It has focused on certain use cases, but it's seen less than 1% of the investment in the JDK, so I guess it's better to call it "specialized". While it works well enough for many things, its performance is like the JVM limping on both legs after a terrible car accident and a bad case of pneumonia while trying to walk on an icy road. You are correct, though, that it probably performs better than a general-purpose platform with a similar level of investment.
  - nivertech 7y ago
    BTW, many years ago, the author of Erjang told me that eventually Erjang will be faster than BEAM for running Erlang apps, b/c of all the investment that went into the JVM ecosystem. I'm not sure it's the case now (probably since nobody using Erjang in production). You are correct in describing the raw performance of BEAM, but I'm not sure it's relevant for a typical IO-bound Erlang/Elixir app. Also most large real-life apps would use NIFs written in a language capable generating native code, i.e. C/C++ or Rust.
  - patrec 7y ago
    There is no doubt that JVM can provide massively better performance for a lot of stuff, but I wouldn't be suprised if Beam kicked JVM's butt in at least some areas. It's pretty much the only system I know of that provides for massive numbers of fairly scheduled, preemptive green threads. To do so it makes trade-offs that are not generally attractive, but I'd be surprised if it didn't beat the JVM here.
    - pron 7y ago
      I would be. BEAM is just a very slow platform, not just compared to Java, but also compared to JavaScript and Go. Again, that's not to say it's not very useful for some things (although many Erlang apps are really mixed Erlang/C apps because of BEAM's performance). Hey, CPython is really slow, too and yet very useful. Green threads is another matter as it's not a feature that currently exists on the Java platform (there are somewhat similar features in Java platform languages like Kotlin's coroutines), but there is currently a project (that I'm leading) to add fibers (AKA user-mode threads, AKA lightweight threads, AKA green threads) to the JVM: https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/
      - mruts 7y ago
        There’s Akka. Also Scala has Future’s. Both are very similar to green threads.
      - chrisseaton 7y ago

I don’t ...

The JVM is a kitchen sink environment. The BEAM is very opinionated. I would expect the VM built from the ground up to support a specific programming model to be superior at doing just that.

macintux 7y ago
In addition, every library written for the BEAM in any language is designed for message passing and the actor model. Clojure would not have that advantage on the JVM.
- didibus 7y ago
  Clojure doesn't use the actor model...
  - macintux 7y ago
    Which was part of the discussion at the linked article.
    - didibus 7y ago
      Oh okay, sorry I misunderstood your comment the first time. The rationale for why Rich Hickey didn't go for the actor model are actually documented here: https://clojure.org/about/state https://clojure.org/about/state I agree with you, that the JVM also would have probably made it more difficult to incorporate and leverage, though Scala seems to have pretty successfully done that, and Fantom has gone that route as well successfully (though the language is niche) on the JVM. So I'm not totally sure either.
pron 7y ago
BEAM is a wonderful VM, but calling it "optimized" for anything is problematic. It has focused on certain use cases, but it's seen less than 1% of the investment in the JDK, so I guess it's better to call it "specialized". While it works well enough for many things, its performance is like the JVM limping on both legs after a terrible car accident and a bad case of pneumonia while trying to walk on an icy road. You are correct, though, that it probably performs better than a general-purpose platform with a similar level of investment.
- nivertech 7y ago
  BTW, many years ago, the author of Erjang told me that eventually Erjang will be faster than BEAM for running Erlang apps, b/c of all the investment that went into the JVM ecosystem. I'm not sure it's the case now (probably since nobody using Erjang in production). You are correct in describing the raw performance of BEAM, but I'm not sure it's relevant for a typical IO-bound Erlang/Elixir app. Also most large real-life apps would use NIFs written in a language capable generating native code, i.e. C/C++ or Rust.
- patrec 7y ago
  There is no doubt that JVM can provide massively better performance for a lot of stuff, but I wouldn't be suprised if Beam kicked JVM's butt in at least some areas. It's pretty much the only system I know of that provides for massive numbers of fairly scheduled, preemptive green threads. To do so it makes trade-offs that are not generally attractive, but I'd be surprised if it didn't beat the JVM here.
  - pron 7y ago
    I would be. BEAM is just a very slow platform, not just compared to Java, but also compared to JavaScript and Go. Again, that's not to say it's not very useful for some things (although many Erlang apps are really mixed Erlang/C apps because of BEAM's performance). Hey, CPython is really slow, too and yet very useful. Green threads is another matter as it's not a feature that currently exists on the Java platform (there are somewhat similar features in Java platform languages like Kotlin's coroutines), but there is currently a project (that I'm leading) to add fibers (AKA user-mode threads, AKA lightweight threads, AKA green threads) to the JVM: https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/
    - mruts 7y ago
      There’s Akka. Also Scala has Future’s. Both are very similar to green threads.
    - chrisseaton 7y ago