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

51–60 of 87 posts

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

#51

Post by pron »

losvedir wrote: post #35
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 proc…

Yes, I am Quasar's main author, but note that I'm not advocating Quasar. I'm advocating Erlang, only on the JVM. And yes, Quasar has all those features, too, but an Erlang implementation on the JVM would use the Erlang implementation, not Quasar's Java implementation.

> Can erlang on the JVM do that?

Of course it can! Just like BEAM does it. (In fact, Quasar used to do that, too. We took out that feature because Quasar also gives you access to kernel threads, and processes that take to long can just be moved to kernel threads, which does this kind of preemption better, anyway. But an Erlang implementation on the JVM can behave just as Erlang does on BEAM).

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

#52

Post by pron »

Ixiaus wrote: post #29
kasey_junk wrote: post #22

Earlier quoted context omitted.

> Erlang generally encourages shared-nothing architectures. This is the language feature that `pron` keeps mentioning. Nothing about the VM is especially better for this than the JVM for instance. > I see nothing wrong with ETS, it's well optimized for the Erlang term format in particular and gives you serializable updates. There isn't anything wrong with it (as a complete neophyte to ETS and the EVM generally), the…

It would be a phenomenal bit of tech anywhere. We had to go with Erlang for one piece of our product at Plum precisely because there is no analog story in Haskell to the Erlang full story. I would have loved to be able to build that specific piece in Haskell but it made little sense when considering what Erlang/OTP provides. It's nice to say that the JVM has more resources and is better at XYZ while the BEAM VM is on…

I think the areas that BEAM is lacking in can be tackled and brought up to parity

Probably. But why not spend that effort on the language and libraries?

instead of homogenizing the VM-field

That makes as much sense as saying your language shouldn't run on the kitchen-sink Linux so as not to homogenized the OS field.

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

#53

Post by johlo »

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 with tools like JProfiler/VisualVM/jconsole, etc. does not come close to the BEAM when trying to understand what is happening in the system.

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

#54

Post by BenoitP »

vitalyd wrote: post #38
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?

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.

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

#55

Post by dozzie »

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?

Unless Akka provides a compiler, it doesn't allow much of the style Erlang was developed for.

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

#56

Post by dozzie »

pron wrote: post #44
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…

> 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.

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

#57

Post by abrgr »

nickpsecurity wrote: post #30
abrgr wrote: post #26

"It’s not going to be too much longer before we declaratively describe out systems as well as our code. I am looking forward to that." Amen! Been doing that to the extent possible for a while and it is terrific!

It's been done before to varying degrees. The original in automatic programming was one that took input from case tools and autogenerated a lot of COBOL. Sun's DASL language from ACE project was a domain-specific language for specifying a type of web application. Around 9-10kloc of it autogenerated 100+kloc XML, client code, server code, etc. Lots of them in the 4GL category for database manipulation with WINDEV/WEBD…

I definitely agree that we'll always need people who think like programmers. We can develop tools in the vein of those you mention to significantly enhance the productivity of those people though. I haven't seen many tools like that that help in distributed systems or that allow one to easily visualize and understand an entire system.

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

#58

Post by vezzy-fnord »

pron wrote: post #48
vezzy-fnord wrote: post #15

Earlier quoted context omitted.

Erlang generally encourages shared-nothing architectures. Of course, in some cases you want regions of shared memory or some other concurrent global resource, hence ETS. I see nothing wrong with ETS, it's well optimized for the Erlang term format in particular and gives you serializable updates. Scalability and large actor counts aren't the definitive features of Erlang, though. It's supervision trees, the distributi…

> There is absolutely no reason to switch to the JVM when the EVM is a beast of its own. I think there is, if you want to concentrate your limited resources on the language and its phenomenal libraries while letting an enormous team working on the world’s second-largest open-source project take care of the VM for you, while at the same time giving you better performance and a wider reach. There are many more organiza…

Completely ignoring the massive resources it would take to make the switch in the first place.

Erjang doesn't cut it. It's an incomplete research project that works on the basis of bytecode translation. Further, the disadvantages with regards to global GC are clearly listed. You say that it'll only keep improving, but that's essentially taking a leap of faith that the JVM developers will eventually get to parity with a feature you already have.

"Limited resources" is a red herring and FUD, plain and simple. Nor is "wider reach" guaranteed in the slightest. Wider reach is not intrinsically a good thing, either. Organizations for whom Erlang is out of reach simply because it doesn't use the JVM are absolutely petty and there is no loss from them not using it, IMO.

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

#59

Post by Ixiaus »

pron wrote: post #52
Ixiaus wrote: post #29

Earlier quoted context omitted.

It would be a phenomenal bit of tech anywhere. We had to go with Erlang for one piece of our product at Plum precisely because there is no analog story in Haskell to the Erlang full story. I would have loved to be able to build that specific piece in Haskell but it made little sense when considering what Erlang/OTP provides. It's nice to say that the JVM has more resources and is better at XYZ while the BEAM VM is on…

I think the areas that BEAM is lacking in can be tackled and brought up to parity Probably. But why not spend that effort on the language and libraries? instead of homogenizing the VM-field That makes as much sense as saying your language shouldn't run on the kitchen-sink Linux so as not to homogenized the OS field.

> Probably. But why not spend that effort on the language and libraries?

Because the best Erlang has to offer isn't really in the Language. Some in the Libraries. Most in its VM. I would pick Haskell or ATS over Erlang - unless I need those few unique features that Erlang/OTP really got right.

> That makes as much sense as saying your language shouldn't run on the kitchen-sink Linux so as not to homogenized the OS field.

No, your analogy is moving the goal post. No one ever said someone couldn't implement Erlang the language for the JVM. As many people have pointed out to you, it isn't the language that makes Erlang. It's BEAM + OTP. We're not talking about moving the language around, we're talking about gutting the VM, my statement still holds: Exalting the JVM to be the one-true-VM for Erlang (therefore also implying any language you do not understand well that needs a VM) is a very bad idea and pretty silly.

Diversity is good. BEAM's VM is good. The JVM is good. Even the CLR is pretty amazing (F# beats the pants off of Scala). There's no reason at all to think that Erlang would be better off on the JVM; however, borrowing successful ideas from other awesome and successful technologies? I think that's a swell path to walk. Beware of the kitchen sink, though, is my only warning.

Also, I don't always think OS' are the best place to run your application. There are many arguments for using something like Erlang on Xen or HaLVM if the design requirements can justify it but arguing about your other critical statement should be a different thread.

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

#60

Post by bfrog »

rubyn00bie wrote: post #12

Nice article, and for an Elixir fan, provides a nice little snippet on something I've been having issues with but hadn't really put my finger on until I saw it: "[...] and I really dislike that Elixir tries to hide immutability. That does make it slightly easier for beginners, but it’s a leaky abstraction. The immutability eventually bleeds through and then you have to think about it." I don't think it necessarily tr…

Then again, there's NIF libs with Threads for those tasks which are long running and require computational performance. Last I checked all the really fast math libraries were written in C/Fortran/C++ not Java
Post reply on HN