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

BEAM languages, Hindley–Milner type systems, and new technologies

medium.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: BEAM languages, Hindley–Milner type systems, and new technologies

#71

Post by pathsjs »

acjohnson55 wrote: post #39
dozzie wrote: post #34

Earlier quoted context omitted.

> [...] but you can have those millions of processes on the JVM, too [...] In theory, yes. In practice, it's very difficult. JVM thread corresponds to a thread of host OS. Spawning and keeping those is very slow and expensive compared to Erlang's processes. You could have a pool of pre-spawned workers, but suddenly you can't spawn a worker for each connection and hope it will all work; you need to manage the pool. Yo…

How does Akka stack up in regards to providing these attributes on the JVM?

Akka actors are multiplexed on real JVM threads. So they implement a cooperative model of threading (i.e. you'd better not block for long inside the body of an actor)

Re: BEAM languages, Hindley–Milner type systems, and new technologies

#72

Post by pron »

johlo wrote: post #53

It's surprising that the BEAM support for operations and management is very rarely mentioned. To me this is the key selling point for using BEAM vs JVM or something else. Being able to open a remote console and do system introspection/tracing/profiling/debugging is a huge advantage when running in production. And all languages running on top of BEAM ofc get this for free. In my experience, running JVM in production w…

> In my experience, running JVM in production with tools like JProfiler/VisualVM/jconsole, etc. does not come close to the BEAM when trying to understand what is happening in the system.

Then you haven't tried Java Flight Recorder/Mission Control or the new javosize. BEAM doesn't come close... :)

Re: BEAM languages, Hindley–Milner type systems, and new technologies

#73

Post by johlo »

pron wrote: post #72
johlo wrote: post #53

It's surprising that the BEAM support for operations and management is very rarely mentioned. To me this is the key selling point for using BEAM vs JVM or something else. Being able to open a remote console and do system introspection/tracing/profiling/debugging is a huge advantage when running in production. And all languages running on top of BEAM ofc get this for free. In my experience, running JVM in production w…

> In my experience, running JVM in production with tools like JProfiler/VisualVM/jconsole, etc. does not come close to the BEAM when trying to understand what is happening in the system. Then you haven't tried Java Flight Recorder/Mission Control or the new javosize. BEAM doesn't come close... :)

I hadn't heard of javosize before, looks interesting, thanks. Being able to update code and data on a live system is very useful and I haven't seen that for the JVM before (BEAM of course handles that :) ).

Re: BEAM languages, Hindley–Milner type systems, and new technologies

#74

Post by pron »

johlo wrote: post #73
pron wrote: post #72

Earlier quoted context omitted.

> In my experience, running JVM in production with tools like JProfiler/VisualVM/jconsole, etc. does not come close to the BEAM when trying to understand what is happening in the system. Then you haven't tried Java Flight Recorder/Mission Control or the new javosize. BEAM doesn't come close... :)

I hadn't heard of javosize before, looks interesting, thanks. Being able to update code and data on a live system is very useful and I haven't seen that for the JVM before (BEAM of course handles that :) ).

Well, there are a lot of JVM tools to inject code into a running application. Take a look at Byteman (which is much more mature than javosize, but mostly targets injecting traces for live debugging purposes)

Re: BEAM languages, Hindley–Milner type systems, and new technologies

#75

Post by BenoitP »

vitalyd wrote: post #61
BenoitP wrote: post #54

Earlier quoted context omitted.

http://www.azulsystems.com/products/zing/whatisit 8000$ per machine, though. The G1 collector that will be made default in Java 9 might make some applications effectively pauseless too on some workloads.

I know Azul, it doesn't guarantee pauses of 20 micros ; <10 millis maybe. G1 isn't even close.

Here is the claim they make:

> Proven to deliver consistent latencies in the 10s of microseconds

http://www.azulsystems.com/products/zing-performance-data

-----------

For workloads where heap is at 100G they still claim latency under 20ms at the 99.999%.

http://www.azulsystems.com/sites/default/files//images/Azul_...

-----------

Now, I would be interested in an independent benchmark.

Re: BEAM languages, Hindley–Milner type systems, and new technologies

#76

Post by vitalyd »

BenoitP wrote: post #75
vitalyd wrote: post #61

Earlier quoted context omitted.

I know Azul, it doesn't guarantee pauses of 20 micros ; <10 millis maybe. G1 isn't even close.

Here is the claim they make: > Proven to deliver consistent latencies in the 10s of microseconds http://www.azulsystems.com/products/zing-performance-data ----------- For workloads where heap is at 100G they still claim latency under 20ms at the 99.999%. http://www.azulsystems.com/sites/default/files//images/Azul_... ----------- Now, I would be interested in an independent benchmark.

Indeed, they have good marketing :). Don't get me wrong, I think Azul and its C4 GC is very nice. However, beyond some absolute best case on smallish heaps, I do not see it hitting guaranteed 20 micros on large server heaps. Also, Azul sacrifices some throughput in favor of minimizing GC latency, which is fine as most things need tradeoffs but should be mentioned (G1 also has lower throughput than parallel due to heavier write barriers).

Re: BEAM languages, Hindley–Milner type systems, and new technologies

#77

Post by pron »

dozzie wrote: post #56
pron wrote: post #44

Earlier quoted context omitted.

> you need to manage the pool. You also could try to implement green threads in JVM, as they are in Erlang, but you would need an entirely new compiler to insert yield points at appropriate places. I am talking about a new compiler. An Erlang compiler. The JVM is a virtual machine. Erlang is a language. We've already proven you can run Erlang on the JVM quite well, and that was before many pertinent improvements to t…

JVM still lacks some serious functions, namely, links and monitors. I'm not that sure you can emulate those on JVM reliably without implementing them as fundamental operations. And then, there's still problem of interoperability. Even when you write your code in Erlang@JVM, it still needs to talk to Java code, which doesn't have yield points.

> JVM still lacks some serious functions, namely, links and monitors. I'm not that sure you can emulate those on JVM reliably without implementing them as fundamental operations.

You don't emulate them; you implement them -- just as BEAM does. Having them baked into the runtime serves no purpose. The JVM operates at a much lower level than BEAM -- just as BEAM is implemented in C, it could be implemented in Java, except that the really hard parts (JIT and GC) are already taken care of. Think of Java as C + JIT + GC.

> it still needs to talk to Java code, which doesn't have yield points.

That's not a problem. First, Erlang code talks to C code, which doesn't have yield points, either. Second, the JVM doesn't need to rely on yield points as much as BEAM does, because it is much more kernel-thread-friendly than BEAM.

Re: BEAM languages, Hindley–Milner type systems, and new technologies

#78

Post by pron »

anonyfox wrote: post #47
pron wrote: post #40

Earlier quoted context omitted.

> Data is immutable... But you don't need that at the VM level. Clojure does that on the JVM. Having that at the VM level makes a simple GC work reasonably well, but HotSpot has world-class GCs that perform better, even without the assumption of immutability. > Everything is defined in modules. Again, that's a language-level feature. > Processes are an abstraction You can get that on the JVM, too. > Finally, everythi…

Hey man, some people (like me) just don't like to work on the JVM, despite it's advantages and superior features like the GC. Just accept it. Having worked with java, scala, jruby and closure, something always is clumsy, be it interfacing with java cruft, slow startup times of the vm, maven & co... While there are solutions to fix the solutions, its just annoying for me. I get what you say, but nevertheless are JVM (…

> Hey man, some people (like me) just don't like to work on the JVM, despite it's advantages and superior features like the GC. Just accept it.

I accept it, but the fact of the matter is that -- like it or not -- there are at least two orders of magnitude more people who use the JVM than BEAM. You're comparing the world's most popular runtime with a runtime that's not even in the top-ten.

Some of your complaints stem from exactly that difference -- the JVM is designed to operate much higher workloads than BEAM, and people use that -- hence Clojure's slow startup etc (the JVM starts up in < 80ms, BTW). But, again, your observations don't change the fact that if Erlang stays on BEAM it will forever be a niche language.

Re: BEAM languages, Hindley–Milner type systems, and new technologies

#79

Post by pron »

vitalyd wrote: post #76
BenoitP wrote: post #75

Earlier quoted context omitted.

Here is the claim they make: > Proven to deliver consistent latencies in the 10s of microseconds http://www.azulsystems.com/products/zing-performance-data ----------- For workloads where heap is at 100G they still claim latency under 20ms at the 99.999%. http://www.azulsystems.com/sites/default/files//images/Azul_... ----------- Now, I would be interested in an independent benchmark.

Indeed, they have good marketing :). Don't get me wrong, I think Azul and its C4 GC is very nice. However, beyond some absolute best case on smallish heaps, I do not see it hitting guaranteed 20 micros on large server heaps. Also, Azul sacrifices some throughput in favor of minimizing GC latency, which is fine as most things need tradeoffs but should be mentioned (G1 also has lower throughput than parallel due to hea…

The Azul guys told me they treat any pause > 20us (or maybe 40us, I don't remember exactly) as a bug.

Re: BEAM languages, Hindley–Milner type systems, and new technologies

#80

Post by pron »

nickpsecurity wrote: post #63
pron wrote: post #49

Earlier quoted context omitted.

All the more reason to use Erlang/JVM alongside other JVM languages. Polyglotism is one of the JVM's greatest strengths, and interlanguage interoperability on the JVM is the best you can get. And Erlang/JVM can be even better than Erlang/BEAM at everything Erlang/BEAM is good at. There is nothing in BEAM that makes it more appropriate for running Erlang than HotSpot (that may have been true in the past, but that's no…

"Polyglotism is one of the JVM's greatest strengths, and interlanguage interoperability on the JVM is the best you can get." It's not the best you can get but polyglot support is a strength. "There is nothing in BEAM that makes it more appropriate for running Erlang than HotSpot (that may have been true in the past, but that's no longer the case)." Still got it beat on latency and security risk per dollar spent: zero…

> zero for Erlang w/ 5 digits for RT-JVM

RT-JVM's guarantee scheduling latencies of 2us. Erlang doesn't come close. In practice, stock HotSpot has better latency than Erlang. Erlang's "guarantees" are only in effect when 1) no native code is used, 2) no global effects are used (some process registrations, binary heap, etc.).

Post reply on HN