Love how puns are the go-to in CS
Clojerl – Clojure for the Erlang VM
51–60 of 105 posts
Re: Clojerl – Clojure for the Erlang VM
#52Earlier quoted context omitted.
With Phoenix + LiveView maybe you won't need the frontend.
It’s a great project, but I doubt it’ll ever reach the maturity and functionality of Reagent, Om, Rum. Fulcro, Datascript, re-frame and Hoplon.
I wouldn't bet against Chris McCord and Jose Valim.
They've done a wonderful job with Phoenix and Elixir. I think this feature liveview will be develop as good as presence feature and eventually will be good enough.
Re: Clojerl – Clojure for the Erlang VM
#53i especially like the QA section explaining "why do it if Hickey said actors are bad" (intentional strawman there):
> The points he makes are of course very good. For example, when no state is shared between processes there is some communication overhead, but this isolation is also an advantage under a lot of circumstances. He also mentions here that building for the distributed case (a.k.a processes and message passing) is more complex and not always necessary, so he decided to optimise for the non-distributed case and add distribution to the parts of the system that need it. Rich Hickey calls Erlang "quite impressive", so my interpretation of these writings is that they are more about exposing the rationale behind the decisions and the trade-offs he made when designing Clojure (on the JVM), than about disregarding the actor model.
That would be my understanding as well. Clojure and Erlang are ideologically quite close, just made with slightly different purposes. Erlang - to be distributed from the ground up. Clojure - to handle mutability on somewhat lower level and be on JVM, where mutability is the norm.
Re: Clojerl – Clojure for the Erlang VM
#54Earlier quoted context omitted.
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.
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 a…
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.
Re: Clojerl – Clojure for the Erlang VM
#55Sorry for the off topic. Any good recommendations for a Clojure book for a seasoned programmer but with little exposure to Lisps?
Re: Clojerl – Clojure for the Erlang VM
#56Why would I use this over elixir?
From the readme of the project: > Clojure is a Lisp and as such comes with all the goodies Lisps provide. Apart from these Clojure also introduces powerful abstractions such as protocols, multimethods and seqs, to name a few. [...] It is fair to say that combining the power of the Erlang VM with the expressiveness of Clojure could provide an interesting, useful result to make the lives of many programmers simpler and…
There are a bit different due to the host environment.
Btw, use the iOS version a lot to learn
Re: Clojerl – Clojure for the Erlang VM
#57Earlier quoted context omitted.
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.
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 a…
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.
Re: Clojerl – Clojure for the Erlang VM
#58That’s very cool. I’ve added Clojerl to my list of alternative languages on the BEAM: https://gist.github.com/macintux/6349828#alternative-languag... Given the extent to which the Erlang VM is optimized for immutable data, network transparency, and message passing, I can see why Clojure on the JVM and CLR would not have had the same success with the actor model as Erlang has.
Benchmarking Clojure (both JVM and JS) vs Erlang immutable data structures would be very interesting given the focus on clever implemeations (persistent data structures) on the Clojure side and the VM level specialization on the Erlang side.
Re: Clojerl – Clojure for the Erlang VM
#59Earlier quoted context omitted.
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 a…
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.
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/
Re: Clojerl – Clojure for the Erlang VM
#60Earlier quoted context omitted.
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 a…
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.
IIRC, Kilim (a Java library) performed better than Erlang in benchmarks.