Coffee with Robert Virding

Had a fascinating conversation over coffee with Robert Virding at Yow Conference Tuesday 6th December 2011... jotted down some of the things I remembered:

• "erlc" produces a BEAM file which is portable byte code
• Joe's Abstract Machine originally compiled Erlang to C macros which was then JIT translated to machine code on the fly
• BEAM was a complete rewrite to produce portable byte code that "erl" translates to machine code on the fly
• Erjang runs on the JVM so it has the advantage of many years and many people of JVM optimisation... Erlang has a team of 5 developers working on the VM.
• Architecture of Erlang apps
• Processes that do the work don't contain error handling... error handling is done where and when it matters by supervisor processes further up the tree
• Supervisor processes are responsible for determining how to handle different types of errors
• Some people on stack overflow freak out about this idea of letting processes crash but don't realise that approach goes hand-in-hand with the approach of handling errors higher up the process tree
• Error Handling
• Modular approach
• Robert likes to code for all eventualities but often developers take an iterative approach... code the core functionality in processes... run the app, observe how different errors crash the processes... and work out how (and where) they should be captured and dealt with
• Processes are organised in trees.  A supervisor at the top is responsible for working out what to do when different types of errors occur
• Typical approach is to let type errors crash the process
• Erlang movie 
• Robert was the guy who "fixed the bug"
• This patching code fixes while the app is running is possible through module loading
• The app has to be specifically designed with this approach in mind
• Have to be careful... what if the process is already running?  
• A module could  (and typically does) contain both the server code and the client code used to access the server.  So a module could contain code that is running in separate processes - a client process, a server process.  Updating it on the fly is tricky.
• Need to take into account data changes too... a mini data migration might be required on existing state... it's up to the module author what they're going to do
• Sometimes the best approach is to crash the process and restart it rather than carry all that complexity in the code - depends on the scenario.
• Also, restarting the entire app is an option... 
• Or using a load balancer type approach where the router directs the traffic to the new server.
• Some companies use Erlang as essentially a gateway to processes running on other languages
• e.g. a fast server server that accepts many concurrent connections and directs each connection to a backend C process.
• Erlang NIFs (Natively Implemented Functions) are invoked in a similar manner to Java's JNI interface
• Erlang can call into Java code using the JInterface
• I remarked I was surprised that I couldn't call my own function from a guard and I understood this was because Erlang didn't want you doing side effects during a guard statement
• Guards where really just an extension on pattern matching, enabling you to be a little more verbose
• Can't create your own data types but can use a Binary type which lets you compose data out of other Erlang types.
• Can reuse the same binary block with other binary types e.g. if your binary type has Int,String,Bool... you could reuse a variable of that binary type as a different type
• Erjang
• serious implementation of Erlang on JVM
• Robert hopes good things come out of it
• Tricky job though to keep up with Erlang as it is still evolving within Ericsson
• Ericsson's OTP department maintain the Erlang language
• Used mainly for testing
• Surprising that a telecoms hardware company supported the language from infancy and there was initially some tension with others who didn't like it but the OTP team had sympathetic management
• Was Erlang based on Prolog?
• It was originally implemented on Prolog (eventually rewritten in Erlang itself)
• The syntax was influenced a little by Prolog but logic programming wasn't the main thrust - it was more about solving telephony concurrency problems.
• Where did the functional programming syntax come from?
• Realised after a bit that the language needed some of the benefits of FP and so they were added
• Do you find many type errors come out in runtime when a particular piece of code that wasn't exercised during testing is invoked due to the input of different data?
• Not so much... there's a tool called the Dialyser that you run over your code... it actively tests all your types and tells you where there's a programming error in your code - it's able to catch most of the programming errors that could lead to a type error at runtime.
• Hipe:  http://www.it.uu.se/research/group/hipe/
• Popularity of Erlang
• It's been pretty steady... there was a bit of a peak in 2008/09