<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
<div dir="ltr">A well written email Tim,<div><br></div><div>I would also add that with development packages such as Maven, building complex Java applications is a breeze. Now personally I think Maven is a royal pain in the ass (XML hell anyone), the ability to bring in dependancies in such a simple way is awesome for product packaging. I've even used it myself - since most of my team are Java developers - for Erlang deployments (see http://erlang-plugin.sourceforge.net/).</div><div><br></div><div><span style="font-size: 10pt; ">I think that what needs to be asked long term is where do we see Erlang been used? Will it just be a niche language, used in certain specific situations? Or do we see it becoming more of a general purpose language?</span></div><div><br></div><div>Of course, it's not ever going to beat Java, C++ or other OOP/imperative languages in terms of number of users, although it would be nice if it would. For one it's off to a bad start with it been functional language. However, unlike Haskell it's not a pure-functional language. Your code can contain little bits of imperative functionality; functions can have side effects for example. In other words it's not too hard to learn.</div><div><br></div><div>I guess I can only speak from my own experience trying to get Erlang accepted into two businesses. Normally there is an existing code base, or a set of users who have been coding in language X all their career. These people are always very reluctant to embrace something new. Many of these people will think that it's going to threaten their future in the company. Many will actively lie and present massaged data to prove their point (I've seen this a few times - for example comparing a simple NGINX reverse proxy that is doing nothing to a full-blown Yaws web-server for example).</div><div><br></div><div>Managers also have the same worry, but also need to look at what it means to retain staff and employ new staff.</div><div><br></div><div>Erlang, unfortunately, often times faces an up-hill battle. </div><div><br></div><div>Something like Erjang can help here. I personally think it's non-ideal for most Erlang deployments, but can be used to get a foot in the door. Deploy Erjang on something that they are familiar with (JVM), have it "natively" talk to Java, and then introduce BEAM later.</div><div><br></div><div>I also agree with other people that Erlang's performance is in most cases more than "good enough" for what it's being used for. But when you have a manager who is already reluctant to use it, and employees who are even less willing to use it, they are going to be even less accepting when they *think* it's too slow (even though that might not actually be the case). Anything that can be done by the community to help here is invaluable.</div><div><br></div><div>I would add that in my experience many issues of poor-performance are often a case of poor code. People not adhering to OTP principles, people not getting to grips with concurrent programming by doing things like implementing a single Erlang process that serializes requests for the whole system. Or in other cases people not using what's available in the language (regex on binary data using binary_to_list and and then the re module, instead of the binary module). In those cases it won't matter a squat what Ericsson do to improve BEAM. But perhaps we need to make an effort to hammer home good programming practice and be more consistent with core libraries (especially with lists vs binaries).</div><div><br></div><div>I guess I'm trying to say that everyone is correct, performance is usually more than good enough. But there is a perception among many non-Erlang developers that that is not the case.<br><br>Matt</div><div><br><div><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">Date: Mon, 13 Feb 2012 12:04:34 +0000<br>From: watson.timothy@gmail.com<br>To: dbarker@camosun.bc.ca<br>CC: erlang-questions@erlang.org<br>Subject: Re: [erlang-questions] The future of Erlang and BEAM<br><br><div class="ecxgmail_quote">Java is ugly and bloated to boot. The JVM though, is actually a pretty fantastic piece of engineering and if you dig into the guts of it, there's a lot that VM teams across the board can learn, especially around self tuning and diagnostic/instrumentation support.</div>
<div class="ecxgmail_quote"><br></div><div class="ecxgmail_quote">I think the point about Michael made about mind-share is a very good one. Also the Java platform, for all its bloated complexity, is more mature in some respects. What I mean by that is, for developing typical business applications, Java (and god forgive me for saying it, the other big unmentionable corporate platform too) offers a number of things that are very beneficial and currently lacking from Erlang's ecosystem. For example, JDBC offers reliable and high performance connectivity to almost every database on the market. There are standardised APIs for working with things like web servers and this makes a big difference to the productivity of *ordinary programmers* who are the target audience for these kinds of development platforms. </div>
<div class="ecxgmail_quote"><br></div><div class="ecxgmail_quote">Having said that, I'd pick Erlang and fiddle with API inconsistencies and the near suicide inducing pain of ODBC on unix any day over Java.</div><div class="ecxgmail_quote">
<br></div><div class="ecxgmail_quote">Going back to what the OP was asking: One of the reasons I don't think that we'll see a competitive implementation of Erlang on the JVM any time soon is that the JVM was built, first and foremost, to host an imperative language. Now the appearance of Clojure does prove that you *can* implement a functional language on the JVM, but Erlang is not just a functional langauge/platform, it is also (as Joe has put it) "Concurrency Orientated", which is about the lightweight Process being a fundamental and first class concept. Java does not have micro/green threads and native threads have limitations. The JVM does not, at its core, support the notion of immutability that we have in Erlang, despite good support for copy-on-write semantics in some (limited) circumstances. </div>
<div class="ecxgmail_quote"><br></div><div class="ecxgmail_quote">The scala crowd can build 'actors' and 'message passing' into their libraries, but these concepts are not part of the JVM. Developers of Scala/Clojure code *can* make their variables, types (and so on) immutable, can implement a syntax for passing around chunks of code in order to imitate higher order functions, but these concepts are not (as of today) part of the JVM. The core concepts for the JVM (and the CLR) are Objects with 'mutable state', native (os level) threads and in Java's case, primitive types that are distinct from objects. You can't get away from those underlying concepts in reality, so 'actors' are Objects and 'message passing' is done by sharing (object) state on a heap and so on. </div>
<div class="ecxgmail_quote"><br></div><div class="ecxgmail_quote">One of the problems people *seem* to be trying to get away from by moving to the JVM is that of raw throughput. We might see a shared heap appear in BEAM some time in the future, for certain special cases, and maybe other optimisations for performance will occur. But as Joe and others have pointed out, Erlang was never built with this in mind. And yet I'm not convinced that an Erlang implementation running on the JVM will really offer great performance benefits, because in order to be *truly like* Erlang, that implementation would *have* to recreate the BEAM emulator running on the JVM. Languages like Scala (and maybe Clojure, I don't actually know) compile down to Java byte code, which means that they're really just syntactic sugar with some runtime library support around it. Perhaps the innovator behind Erjang will pipe in and correct me, but my guess is that you couldn't do that with Erlang without loosing so much of what the langauge/platform is all about. Therefore you're now running a complex runtime environment (i.e., the BEAM emulator) inside another complex runtime environment (the JVM), and fun though they are, the implementations of Jython and JRuby demonstrate that there is a great cost (in terms of performance) when you do this.</div>
<div class="ecxgmail_quote"><br></div><div class="ecxgmail_quote">I'm happy to be proved wrong, but for all the good engineering that resides in the JVM, I suspect it's probably not the right platform for a competitive Erlang/OTP implementation. </div>
<div class="ecxgmail_quote"><br></div><div class="ecxgmail_quote">On 13 February 2012 03:17, Deryk Barker <span dir="ltr"><<a href="mailto:dbarker@camosun.bc.ca">dbarker@camosun.bc.ca</a>></span> wrote:<br><blockquote class="ecxgmail_quote" style="border-left:1px #ccc solid;padding-left:1ex">
As a mere amateur in the erlang world - I've used it a few times in my network programming course, probably bending the rules slightly to do so...<br>
<br>
But I've been programming for a while (first program FORTRAN on an IBM 7090 while still at school in 1968, second program in BASIC on a PDP-8 while taking a course from Maurice Wilkes at Cambridge in 1970) and there's one aspect in all of this thread that has either not been mentioned or at least not made much of:<br>
<br>
the fact that erlang is a functional language.<br>
<br>
For years FP got a bad press, from the early days when the accusation was inefficiency ("LISP programmers know the value of everything and the cost of nothing") to the more recent criticisms that FP is very nice for academics but won't work in the *real* world.<br>
<br>
Erlang clearly blows these ideas out of the water and combines all of the attributes everybody else has mentioned with those of developing in a functional language, with all of its associated benefits, especially of correctness.<br>
<br>
Besides, I think java is a terribly *ugly* language...:-)<span class="ecxHOEnZb"><font color="#888888"><br>
<br>
deryk<br>
-- <br>
<br>
Deryk Barker, Computer Science Dept.<br>
Camosun College, Victoria, BC, Canada</font></span><div class="ecxHOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>
<br>_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions</div></div></div>
</div></body>
</html>