Live data from Hacker News

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

medium.com

81–87 of 87 posts

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

#81
post #78

Earlier quoted context omitted.

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…

Becoming ultra popular isnt an advantage at all. Look how much crap gets produced with JS or PHP, tons of crappy libraries shallow the few good ones, people write throwaway code like there is no tomorrow and real (tm) developers have to maintain this mess. And yes, I have seen code in my day job written in Java or Scala that was nearly impossible to even understand. Much Code.

Again it's obvious that the JVM is dramatically more in use than BEAM, but I like it so far. Up to now people only stumpled upon erlang when they actually needed it, now with elixir & co a few others discover that BEAM might be exactly what they need. This shows in the ecosystem, and the community of #elixir is by far the nicest I have met so far.

Just personal experience, yours might differ (obviously). Just to reiterate: Becoming too popular results nearly everytime in garbage for everyone. Just look how much stuff gets crammed in JS nowadays.

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

#82
post #43

Earlier quoted context omitted.

> avoiding the bullseye currently on Java. That bullseye exists only in the minds of some HNers. Here is a very (very!) partial list of companies running primarily or largely on the JVM: Google, Twitter, Netflix, LinkedIn, Box, IBM, SAP, Amazon, eBay. > They just want easy scaling, distribution, and fault-tolerance. ... So they write chunks of their code in C. That would be completely unnecessary if they'd just run E…

Oh no, it exists in the form of CVE's and actual compromises. Java compromises were coming into my news feed at a higher rate than Windows despite all its native code. Got bad enough that Krebs on Security simply recommended taking Java off one's machine unless they absolutely need it. Nice that you named many top tech firms with smart, well-funded NOC's and security teams as the counter-example. Harder for individua…

How many end users have an Erlang runtime installed that is invoked with untrusted code by way of a browser plugin? If there are no potential targets, don't be surprised about a lack of published Erlang VM exploits.

I'd guess that the number of JVM CVEs is in the same ball park as the other sandboxing platforms, Web browsers (JavaScript) and Flash.

In 2015 it's good advice to uninstall JVM (and Flash!) browser plugins, since they provide negligible value with current browsers. But generalizing that to the server side, where all code that runs is trusted, is dubious.

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

#83
post #43

Earlier quoted context omitted.

> avoiding the bullseye currently on Java. That bullseye exists only in the minds of some HNers. Here is a very (very!) partial list of companies running primarily or largely on the JVM: Google, Twitter, Netflix, LinkedIn, Box, IBM, SAP, Amazon, eBay. > They just want easy scaling, distribution, and fault-tolerance. ... So they write chunks of their code in C. That would be completely unnecessary if they'd just run E…

Oh no, it exists in the form of CVE's and actual compromises. Java compromises were coming into my news feed at a higher rate than Windows despite all its native code. Got bad enough that Krebs on Security simply recommended taking Java off one's machine unless they absolutely need it. Nice that you named many top tech firms with smart, well-funded NOC's and security teams as the counter-example. Harder for individua…

> Java compromises

99% of those are Java browser plugin compromises and have nothing to do with server-side Java.

> Erlang on the JVM currently gives same scaling, real-time properties, easy distributed apps, and availability as BEAM?

As currently there is no "Erlang on the JVM" (other than a little-maintained experiment), the answer is no. If you're asking whether an Erlang implementation on current JVM would do that, the answer is no, either; it's not the same, but much better (otherwise I wouldn't have suggested it).

> And without one of the commercial VM's you seem to be assuming (but not stating) for eg real-time?

Yes, of course. Azul would be much, much, much better. Stock HotSpot would just be much better.

> More people would accept your claim if you demonstrated it.

Obviously, demonstrating it would require some effort, and as the Erlang ecosystem is so small, there is little reason for the JVM ecosystem to prove it (growing the ecosystem by another 0.1% doesn't justify the effort, no matter how small). In the meantime, you can look at the Erjang, bearing in mind that it doesn't use the new JIT, new GCs (although you can try), and new scheduler.

OTOH, if Erlang wanted to expand its reach by orders of magnitude, someone in that community should give it a try. Obviously, the fact that the world's largest, most technically-savvy companies rely on the JVM means that it's a good choice. If the Erlang community doesn't want to try -- hey, it's their loss... If they want to convince themselves they're making the right choice, that's fine by me, too. But if they want to do that by believing (and perpetuating) false notions regarding HotSpot, I'm just correcting their errors.

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

#84
post #83

Earlier quoted context omitted.

Oh no, it exists in the form of CVE's and actual compromises. Java compromises were coming into my news feed at a higher rate than Windows despite all its native code. Got bad enough that Krebs on Security simply recommended taking Java off one's machine unless they absolutely need it. Nice that you named many top tech firms with smart, well-funded NOC's and security teams as the counter-example. Harder for individua…

> Java compromises 99% of those are Java browser plugin compromises and have nothing to do with server-side Java. > Erlang on the JVM currently gives same scaling, real-time properties, easy distributed apps, and availability as BEAM? As currently there is no "Erlang on the JVM" (other than a little-maintained experiment), the answer is no. If you're asking whether an Erlang implementation on current JVM would do tha…

Exactly. Erlang + BEAM vs Erlang + Java is all speculation at this point. I already told you I think HotSpot would perform better than current BEAM minus determinism. Latest updates might or might not help on that. Meanwhile, they can use what they have with diversity benefit or ride along with Oracle's I.P. with associated benefits and risks. Either is a valid choice with me favoring diversity and trying new designs.

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

#85

Earlier quoted context omitted.

Oh no, it exists in the form of CVE's and actual compromises. Java compromises were coming into my news feed at a higher rate than Windows despite all its native code. Got bad enough that Krebs on Security simply recommended taking Java off one's machine unless they absolutely need it. Nice that you named many top tech firms with smart, well-funded NOC's and security teams as the counter-example. Harder for individua…

How many end users have an Erlang runtime installed that is invoked with untrusted code by way of a browser plugin? If there are no potential targets, don't be surprised about a lack of published Erlang VM exploits. I'd guess that the number of JVM CVEs is in the same ball park as the other sandboxing platforms, Web browsers (JavaScript) and Flash. In 2015 it's good advice to uninstall JVM (and Flash!) browser plugin…

It's a benefit I call security by economics. The bad guys focus limited energy to produce attacks with maximum ROI. Makes them aim at most popular stuff. Simply choosing less mainstream, yet high quality, tech avoids many attacks as a side effect. Erlang is currently benefiting from this. So, I list it as a side benefit over Java.

It's not a high assurance system designed from ground up for security. It's a commercial system designed for availability. It will have plenty of flaws for malware writers to find. Meanwhile, they ignore it and smash Java instead. Gotta be a weight off Erlang crowd's mind.

Truth be told, I'd be getting my codebase in secure shape during such a time. Would look higher quality when attacks appear.

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

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

This is a recurring theme. The Java proponents' alternative to the FREE BEAM VM is $8,000 per machine or some other high priced stuff. I could afford an extra IT person just by switching to BEAM on several machines!? Sign me up!

The pricey alternative is if you want the absolute best. The free alternative is already (with high probability, based on Erjang and more recent improvements) much better than BEAM. Not to mention the costs you save by not writing C code and having an immense selection of high-quality libraries to choose from.

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

#87
post #86

Earlier quoted context omitted.

This is a recurring theme. The Java proponents' alternative to the FREE BEAM VM is $8,000 per machine or some other high priced stuff. I could afford an extra IT person just by switching to BEAM on several machines!? Sign me up!

The pricey alternative is if you want the absolute best. The free alternative is already (with high probability, based on Erjang and more recent improvements) much better than BEAM. Not to mention the costs you save by not writing C code and having an immense selection of high-quality libraries to choose from.

Do you have proof that Erjang is better than Erland/BEAM with real-world benchmarks? Far as libraries, I'd agree with you that there's more. The quality part varies per library.
Post reply on HN