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

31–40 of 87 posts

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

#31

Post by nickpsecurity »

pron wrote: post #2

BEAM is a very nice VM (albeit rather slow compared to HotSpot or V8), but I don't understand why every mention of BEAM has to spread misconceptions about the JVM: > In many systems, Java included, the Garbage Collector (GC) must examine the entire heap in order to collect all the garbage. There are optimizations to this, like using Generations in a Generational GC, but those optimizations are still just optimization…

What you're saying is a VM with tons of R&D, tons of corporate investment, and a focus on speed was faster than a new one that was Ericsson's side project focused on stuff other than speed? Little surprise. Meanwhile, BEAM and its language have been doing exactly what they're designed for with enough success that it's mainstreamed naturally. Which Java didn't.

Truth be told, most of the crowd using BEAM doesn't care if it's a bit slower than Java. They just want easy scaling, distribution, and fault-tolerance. A different code-base than Java's is a plus in terms of increasing implementation diversity and avoiding the bullseye currently on Java.

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

#32

Post by nickpsecurity »

pron wrote: post #10
NhanH wrote: post #8

Earlier quoted context omitted.

> True, that is a good selling point -- in theory. Indeed BEAM's process isolation is better than the JVM's on paper. In practice, so many Erlang systems have so much C in them (because Erlang isn't fast enough for the data plane), that they can still bring down the entire VM (not as if there aren't other ways of doing that even without native code), or they interfere with one another in other ways because of BEAM's…

> Actor model does not require concurrent data structure to be effective. Actually that's the whole point of it... That's complicated. Actors don't require concurrent data structures for the bits that don't require concurrent data structures but they do for the bits that do :) That's why Erlang has ETS. That's why you still need a database.

No it's not. The proper way to design systems is breaking them into pieces, implementing each one the best way for that piece, and connecting them together. So, if one can't do DB's with Actors, do it with another tool or model (eg Eiffel/Java w/ SCOOP). Use Erlang/BEAM for what it's good at. There's also tools such as ZeroMQ that make the integration fast & easier. You get the best of both worlds.

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

#33

Post by nickpsecurity »

corysama wrote: post #17
pron wrote: post #14

Earlier quoted context omitted.

> Erlang makes it much easier to do well and much harder to screw up. That's a feature of the language, not the VM (compare with Clojure, that does a similar thing on the JVM). You could still do all that on a higher-quality VM (simply because the effort put into it is orders-of-magnitude more than into BEAN; not because OpenJDK's people are smarter or anything).

If I could get the JVM's JIT & serial GC performance combined with the BEAM's trivial-cost threads & thread-segregated GC, it would be sweet indeed.

That would be a nice combination.

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

#34

Post by dozzie »

pron wrote: post #13
RickHull wrote: post #7

Earlier quoted context omitted.

> The thing I don't get about Erlang and BEAM is the idea that having lots of little processes means that your program will scale brilliantly to run in parallel. The point is scaling. Think in terms of request rate. If you know you can have millions of processes per machine and they run well in parallel, then you can handle requests with processes and stop worrying.

Sure, but you can have those millions of processes on the JVM, too and scale better because of better access to shared data than ETS.

> [...] 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. 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, or else you would get exactly the same problems with green threads as everywhere else.

Under JVM you just don't spawn a thread for each and every activity, because you would choke your system. The whole point of developing Erlang was to allow exactly this programming style in a manner safe against processing congestion.

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

#35

Post by losvedir »

pron wrote: post #2

BEAM is a very nice VM (albeit rather slow compared to HotSpot or V8), but I don't understand why every mention of BEAM has to spread misconceptions about the JVM: > In many systems, Java included, the Garbage Collector (GC) must examine the entire heap in order to collect all the garbage. There are optimizations to this, like using Generations in a Generational GC, but those optimizations are still just optimization…

As a point of disclosure, and also to improve your credibility, you are the author of Quasar (actors and erlang-style processes on the JVM), are you not?

I'm just learning Elixir (and therefore erlang/BEAM somewhat) and one thing that's cool to me is that a piece of code that's taking too long to execute can be paused by the VM while it switches to another thing, which keeps the latency down. I think, like, each process has some number of "ticks" or something before it switches away.

Can erlang on the JVM do that?

Edit: Also, the other thing that majorly attracts me to Elixir/Erlang is OTP (applications, genservers, supervision trees with restart strategies, etc). Are there any plans to port those libraries/philosophy into Quasar?

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

#36

Post by nickpsecurity »

pron wrote: post #13
RickHull wrote: post #7

Earlier quoted context omitted.

> The thing I don't get about Erlang and BEAM is the idea that having lots of little processes means that your program will scale brilliantly to run in parallel. The point is scaling. Think in terms of request rate. If you know you can have millions of processes per machine and they run well in parallel, then you can handle requests with processes and stop worrying.

Sure, but you can have those millions of processes on the JVM, too and scale better because of better access to shared data than ETS.

I'm guessing you're the Quasar guy or am I off? Either way, I think you have benchmarked the lightweight thread approaches on JVM's. How much simultaneous concurrency can the JVM methods manage right now for say serving web requests? And how much does Erlang's best do on same machine?

I think that's an interesting and useful comparison point to start with to test your claim. This is also something I figured Java side would greatly improve on.

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

#37

Post by nickpsecurity »

chrisseaton wrote: post #19
digitalzombie wrote: post #16

Earlier quoted context omitted.

> brilliantly to run in parallel. I just want to clarify it's for concurrent not parallel. Erlang doesn't promise parallel. You can get parallel from concurrent but not the other way around and once again Erlang only enable concurrency and you may get parallel beacuse of concurrency.

I can keep quoting from the same book: > Here’s the good news: your Erlang program might run n times faster on an n-core processor—without any changes to the program. Sounds hopeful - and they've qualified it with might which is good. > But you have to follow a simple set of rules. If you want your application to run faster on a multicore CPU, you’ll have to make sure that it has lots of processes, that the processes…

That's not true for any language. It depends heavily on how that language is interpreted or compiled to machine code. A number of languages support threads but have eg GIL's. We have to judge each on a case-by-case basis. Both the Erlang language and BEAM designed specifically to support this. Here's some details for you in a JVM comparison:

http://ds.cs.ut.ee/courses/course-files/To303nis%20Pool%20.p...

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

#38

Post by vitalyd »

pron wrote: post #2

BEAM is a very nice VM (albeit rather slow compared to HotSpot or V8), but I don't understand why every mention of BEAM has to spread misconceptions about the JVM: > In many systems, Java included, the Garbage Collector (GC) must examine the entire heap in order to collect all the garbage. There are optimizations to this, like using Generations in a Generational GC, but those optimizations are still just optimization…

What JVM stops threads for ~20 micros?

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

#39

Post by acjohnson55 »

dozzie wrote: post #34
pron wrote: post #13

Earlier quoted context omitted.

Sure, but you can have those millions of processes on the JVM, too and scale better because of better access to shared data than ETS.

> [...] 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?

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

#40

Post by pron »

cdumler wrote: post #18
chrisseaton wrote: post #3

Earlier quoted context omitted.

The thing I don't get about Erlang and BEAM is the idea that having lots of little processes means that your program will scale brilliantly to run in parallel. Programming Erlang (authored by the creator of Erlang) says without any qualification at all that "Concurrent programs are made from small independent processes. Because of this, we can easily scale the system by increasing the number of processes and adding m…

No, Erlang does not mean that anything you write will scale. Your solution has to be broken into parallelizable pieces. But, the scalability of your solution is only as good as the mechanisms within the language and runtime to efficiently allow developers to create a scalable system. BEAM implements several nice features: Data is immutable, so we don't have to worry about keeping data coherent between.. anything. Whe…

> 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, everything is abstracted to the notion of nodes with in a cluster.

That's the runtime library's concern. Not the VM's.

> When you start thinking in terms of how structure you code for BEAM, you inherently get easy access to scalability.

All of that is great, but implementing those features at the language/library level and harnessing HotSpot's power would give you that same easy access to even greater scalability.

Post reply on HN