Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clojerl – Clojure for the Erlang VM

github.com

Post reply on HN
Print view View original

71–80 of 105 posts

Re: Clojerl – Clojure for the Erlang VM

#71

Post by zambal »

pron wrote: post #70
chrisseaton wrote: post #66

Earlier quoted context omitted.

It's true that BEAM has excellent concurrency, parallelism, supervision, message passing... but I don't know understand why that has to come at the expense of being terrible at everything else. Why doesn't it have even a baseline reasonable quality JIT? Why doesn't its GC use a design more recent than half a century ago? It's got big corporate backers and PhDs working on it.

I would imagine that's because they'd rather focus whatever resources they have on the needs and priorities of their target audience, which probably don't think performance is critical. I hope that one day TruffleBEAM+Loom would be a great platform for all those wonderful Erlang apps.

Searching for TruffleBEAM+Loom doesn't yield any meaningful results. Could you provide any info about what it is?

Re: Clojerl – Clojure for the Erlang VM

#72

Post by [deleted] »

zambal wrote: post #71
pron wrote: post #70

Earlier quoted context omitted.

I would imagine that's because they'd rather focus whatever resources they have on the needs and priorities of their target audience, which probably don't think performance is critical. I hope that one day TruffleBEAM+Loom would be a great platform for all those wonderful Erlang apps.

Searching for TruffleBEAM+Loom doesn't yield any meaningful results. Could you provide any info about what it is?

[deleted]

Re: Clojerl – Clojure for the Erlang VM

#73

Post by pron »

zambal wrote: post #71
pron wrote: post #70

Earlier quoted context omitted.

I would imagine that's because they'd rather focus whatever resources they have on the needs and priorities of their target audience, which probably don't think performance is critical. I hope that one day TruffleBEAM+Loom would be a great platform for all those wonderful Erlang apps.

Searching for TruffleBEAM+Loom doesn't yield any meaningful results. Could you provide any info about what it is?

It's something that I hope would exist one day. Loom is a project that I'm working on to add lightweight threads to the Java platform (https://wiki.openjdk.java.net/display/loom/) and Truffle is a framework that allows writing fast language runtimes for the Java platform or standalone that chrisseaton is working on (https://github.com/oracle/graal/tree/master/truffle).

Re: Clojerl – Clojure for the Erlang VM

#74

Post by namelosw »

This is brilliant.

I'm a shallow Clojure user, I like Clojure but every time I look into 'modern' Clojure code base I would see a lot stuartsierra/component. I know this is quite a library with high quality, but it's more like a sign of compromise - 'we still need stateful component eventually, although we already have 5 different ways to deal with the state, we need another one'.

Despite what Rich said about Actors, the state in Erlang/OTP is more well-modeled. The state(process mechanism) is not only playing well with immutable functional languages but also much more robust than OO languages. And it also largely simpifies the mental model - it removes the need of atom/agent/variable/object, etc.

Another neat thing, of course, no awkward loop/recur anymore.

Re: Clojerl – Clojure for the Erlang VM

#75

Post by lostjohnny »

cuddlecake wrote: post #50
brianpgordon wrote: post #35

Earlier quoted context omitted.

It looks like this is actually running the real Erlang/OTP, just with some amount of performance penalty from not being on the BEAM. This could be fantastic for fans of BEAM languages who now have a low-profile way to introduce, say, an Elixir proof of concept into a JVM-dominated infrastructure.

Would it really matter though, whether the underlying VM is JVM or BEAM, if people don't want to code in Erlang or Elixir? I don't think introducing the BEAM is the hard part, I think it's all about the language barrier.

In my experience the opposite is true.

I've been able to introduce the BEAM in a large company (where I work) but the barrier has been they don't know it, they know very well the JVM and they don't care about the language if it can produce a runnable jar.

I would really use the JVM more if I could program it in Elixir.

Re: Clojerl – Clojure for the Erlang VM

#76

Post by verttii »

cuddlecake wrote: post #50
brianpgordon wrote: post #35

Earlier quoted context omitted.

It looks like this is actually running the real Erlang/OTP, just with some amount of performance penalty from not being on the BEAM. This could be fantastic for fans of BEAM languages who now have a low-profile way to introduce, say, an Elixir proof of concept into a JVM-dominated infrastructure.

Would it really matter though, whether the underlying VM is JVM or BEAM, if people don't want to code in Erlang or Elixir? I don't think introducing the BEAM is the hard part, I think it's all about the language barrier.

Personally I spent most of my learning curve on the BEAM facilities rather than Elixir itself. Elixir as a language is simple and fairly imperative, it's quick to pick up.

Using the language for data transformations and such is a breeze but learning the concurrency primitives, message passing, OTP tooling and behaviors is where the real work is in my opinion, when building distributed systems on top of BEAM.

Re: Clojerl – Clojure for the Erlang VM

#77

Post by simongray »

vbuwivbiu wrote: post #55
noncoml wrote: post #5

Sorry for the off topic. Any good recommendations for a Clojure book for a seasoned programmer but with little exposure to Lisps?

https://leanpub.com/elementsofclojure

That is a great book, but it doesn't introduce the language at all.

Re: Clojerl – Clojure for the Erlang VM

#78

Post by cutler »

pron wrote: post #68
tokenrove wrote: post #62

Earlier quoted context omitted.

I think your statement goes too far. In my experience, it's very difficult to do lightweight threading on the JVM anywhere near the performance of the BEAM, as well as region allocation in the style used by high-performance Erlang programs. I think a comparison is unfair. The BEAM definitely sucks for compute-oriented tasks, but it's an immense amount of work to make a JVM-based program compete in the areas where it'…

Yeah, but lightweight threading is a built in primitive in BEAM, so if you only measure scheduling overhead it is very low, but once you do any work inside those processes, it runs like any code running on low-performance runtimes. The isolated heaps are also OK, but the modern JVM GCs would still give you lower latency even with a shared heap. BEAM, CPython, MRI Ruby and other low-performance runtimes get the job do…

Don't forget Fibers - coming to a JVM near you soon!

Re: Clojerl – Clojure for the Erlang VM

#79

Post by verttii »

pron wrote: post #68
tokenrove wrote: post #62

Earlier quoted context omitted.

I think your statement goes too far. In my experience, it's very difficult to do lightweight threading on the JVM anywhere near the performance of the BEAM, as well as region allocation in the style used by high-performance Erlang programs. I think a comparison is unfair. The BEAM definitely sucks for compute-oriented tasks, but it's an immense amount of work to make a JVM-based program compete in the areas where it'…

Yeah, but lightweight threading is a built in primitive in BEAM, so if you only measure scheduling overhead it is very low, but once you do any work inside those processes, it runs like any code running on low-performance runtimes. The isolated heaps are also OK, but the modern JVM GCs would still give you lower latency even with a shared heap. BEAM, CPython, MRI Ruby and other low-performance runtimes get the job do…

yeah each individual process has low resource allocation. There could be millions running on the same box so that makes sense.

Luckily, computational parallelization is not a big challenge with new libraries such as: https://github.com/plataformatec/flow

However, immutability might still become a challenge in terms of resources/performance. Rust is often used to patch that with Erlang's NIF.

Re: Clojerl – Clojure for the Erlang VM

#80

Post by sbuttgereit »

tanzbaer wrote: post #3

Why would I use this over elixir?

I think the more interesting question would be why Clojerl over LFE (http://lfe.io/)?

Yes, there is a community around Clojure that would feel more at home with the BEAM if they could use Clojure there... and this is likely the answer to my first sentence... but once you get to a Lisp it seems like the leap is less far to another Lisp and LFE, I would think, is better established.

So I guess the real question would be, for those outside the Clojerl project, are the benefits Clojure more specifically on the BEAM worth the costs of foregoing a (possibly/likely) more mature Lisp that already exists for the BEAM?

Post reply on HN