[erlang-questions] The future of Erlang and BEAM

[Matthew Evans]

Yes, I could write an essay on this one..
The other thing to remember about all these Java (and C++) libraries is that there are, frankly, so many of them. Each time you look at one it's a whole different set of semantics that need learning. With Erlang you have a single set of concurrency principles that need learning that are core to the language, and who's behavior is well understood. It makes for code that is easy to reason about, especially when things go wrong. I also worry that many of these Java libraries are only going to be supported until something shinier, newer or better comes along. I should add here that I have recently started learning Java, and quite like the language, especially compared to the effects that C++ has had on my hairline. ;-)
Having said that there is a valid criticism of Erlang in that it is often perceived to be too slow. As Joe said, you can't have all the features of resilience and reliability without some cost, but when trying to "sell" Erlang it's often the first argument against Erlang that I hear. The pointy haired managers look at things like the Alioth shootout and see Erlang perform poorly for most tests. Now, most Erlang users will correctly say "well, Erlang isn't designed for those types of highly serial tasks, use C, C++ or Java for that instead, and use Erlang where it makes sense". But this now means that a company needs to embrace 2 (perhaps more) languages to do a job. This isn't necessarily a bad thing, but can make for pain when hiring, training and retaining staff.

My point is that I don't think Erlang will ever be as fast as Java and certainly never as fast as C/C++, but I would like to see a greater focus on performance, perhaps get it into the top 10 languages for performance. I'm happy to see that work is been done WRT to JIT in the Erlang VM, and LLVM+HiPE, so maybe future releases will address those concerns.
I've also often wondered if it makes sense to implement some of the Kernel and STDLIB modules as BIFs instead of in Erlang. Would that improve things?
Matt________________________________
> Date: Sat, 11 Feb 2012 13:20:54 +0100 
> From: poprosturadek@REDACTED 
> To: ulf@REDACTED 
> CC: erlang-questions@REDACTED 
> Subject: Re: [erlang-questions] The future of Erlang and BEAM 
>  
> # the same as above, sorry for inconvenience 
>  
> Hi Ulf, 
>  
> thank you very much for answer. 
>  
> I understand that Erlang has been created in purpose of managing  
> coordination complexity and it does it's job well. 
> But, maybe I'm a bit of devil's advocate, let's say that we (by which I  
> mean mostly OTP team because of their knowledge of Erlang intrinsics  
> but others too) could follow similar direction that Clojure's creator  
> Rick Hickey took. Which means, to build Erlang on JVM, using tools that  
> we already have (like earlier mentioned Java libraries, etc) and  
> optimize it for using with JIT. 
>  
> Of course, it's not obvious that (despite being big effort) it would  
> bring desired performance (although, it seems it would) but some  
> advantages for sure, like ubiquity of JVM, wide gremium of  
> supporters/maintainers, ease of deployment (even single .jar maybe),  
> access to huge variety of other languages and libraries, and even some  
> minor things like proper module managament, etc. 
>  
> As I said before, I'm rather novice in Erlang world (still digging  
> through Erlang and OTP in Action) so all above may be  
> wrong/incomplete/etc. I had this idea some time ago so I finally took  
> decision to write about my concerns here. 
>  
> Greetings, 
> Radek 
>  
> _______________________________________________ erlang-questions  
> mailing list erlang-questions@REDACTED  
> http://erlang.org/mailman/listinfo/erlang-questions 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120211/6f6c2125/attachment.htm>