Elixir vs. Erlang: a question of momentum
journal.dedasys.com
journal.dedasys.com
I was intrigued by Elixir, coming from a ruby background, but one of the key points for me was the robust and battle-tested Erlang VM and OTP. And as I've played with my Elixir app, I've found myself looking at Erlang code.
Erlang is one of the main draws of Elixir, and conversely the enthusiasm around Elixir will be hugely beneficial to the Erlang community.
It is easy to gain huge percentages of momentum (if you could ever measure that) when you have little to start with. That's the case with Elixir. That's the same situation languages like Factor and even Haskell saw seven years ago. The former is more or less dead and and the latter still never "broke out".
When Elixir is competing library-wise and ecosystem-wise with the likes of existing languages like Python, Ruby, Java, Javascript, and then some of its major selling points are in competitors like Go (though not 100%) or Clojure/Scala (which can leverage the JVM), it really, really has to distance itself.
As great as Elixir is, it is hard to make a bet on it ever crossing the threshold of "this is really cool" to something you can goto because library x y and z are available.
I think the real problem is overly broad generalizations about languages in general. I'm just a sysadmin, so I have to keep up with the big picture overview of things, and one thing I have learned is that certain languages have momentum in certain areas of application where they don't in others. The devs in one area see language A as awesome and language B as sucky for their work, while the devs in another see it the opposite. Elixir/Erlang for example has concurrency that is only challenged by a small set of languages like Go. (Henning Diedrich got 877k TPS with Erlang and VoltDB. )
Anyway, my point is that for those of us more specialized and deep instead of jacks of all trades, we need to keep in mind our biases when we speak so broadly about languages. Also, when it comes to momentum, some languages can pull others behind them. For example, I am recently fascinated with Racket, which seems to me a perfect way of pulling Scheme (SICP) into a modern setting. Elixir may have enough momentum that it brings Erlang with it, etc.
Crossing the Chasm strikes again. In general, grabbing the early adopters doesn't inherently mean you'll be successful.
(Not that everyone wants to cross said chasm. Haskell's motto has been 'avoid success at all costs' for a while now, if I remember correctly.)
Kind of a nitpick, but "breaking out" was never a goal of the forces behind Haskell, and in fact contrary to their stated desires. Much of Haskell's value was always (and continues to be) its variety of tools for expressing the semantics of the problem the code tries to solve — features which we now see spreading rapidly among mainstream languages. The rest of its value (and its primary purpose) was as a research tool for developing such features. There's still a lot of work to be done in exploring that frontier.
That said, if you have to understand a sufficient amount of math concepts to code in a language... that's an impediment. (Perhaps an empowering learning curve, to be sure.)
Why does Ganeti use Haskell?
Ganeti first used Haskell as an experiment when we needed a compiled language that could perform fast computations on cluster metadata. Eventually, we found that Haskell had advantages in its type safety that made it easy for us to develop better code with fewer common errors without having to write extensive “type-specific” unit tests. At this point, we decided to expand our use of Haskell.
As of January 2014, we plan to convert only “infrastructural” code (job queue, locking) that was already very complicated in Python to Haskell. We’ll continue to use Python for Logical Units, backend RPCs, and hypervisor, storage, and networking implementations.
There are two main reasons why Haskell constitutes a low barrier:
- Haskell doesn’t have any runtime dependency on the target systems.
- For setup, Haskell only requires a development environment.
[0] https://code.google.com/p/ganeti/wiki/GanetiFAQ#Why_does_Gan...
http://devintorr.es/blog/2013/06/11/elixir-its-not-about-syn...
I think it's silly that we have a generation of programmers who are unwilling to learn a language without a C or Ruby like syntax.
But I must admit that I find Elixir easier to read and more comfortable than Erlang.
I don't think so at all. I see elixir gaining a groundswell of momentum very much like the early days of rails and node. Of course it's the beginning, but I see a whole different crowd of people interested in elixir - the "gets things done" crowd rather than the "this is cool/elite" crowd I see playing with factor or haskell (sorry, but it's true).
Elixir does not compete with Python, Ruby or JS - it solves a whole different problem, which is the "massively multiplayer" requirement the apps world is obviously moving towards. No-one I know likes Go or Scala. Clojure is a genuine competitor, you are right about that, but it lacks the ruby community spirit showing itself in elixir. Say what you want about ruby but its community moves mountains.
It's early, yes, but I know a lot of good rails devs who are embracing elixir and they're all "smart and gets things done" types. A lot of torque is building behind taking elixir mainstream, and there's excitement in the air. Time will tell, but it's a bet I'm increasingly ready to make.
I think it does, actually, though not intentionally. José Valim was a Rails core dev and as far I can tell he took on Elixir to address concerns with performance.
In http://elixir-lang.org/blog/2013/08/08/elixir-design-goals/ he says, "Given my previous background in Ruby, it is natural that some of the constructs added were borrowed from Ruby. However, those additions were a by-product, never a language goal." He follows this with a comparison of Ruby code to Elixir.
I'm heavy into Ruby but looking forward to Elixir gaining strength.
You may be right, but what I meant is that every rubyist i know looking into elixir is after massively persistent connections. Websocket, basically, to thousands or more clients. They are leaving ruby because it simply cannot offer that (I don't care what DHH says. No-one big is doing EM WS in production, nor should they).
Phoenix has a steeper learning curve than rails but is addressing the new paradigm of persistent duplex connections. Rails remains unapologetically a request-based framework, ActionCable notwithstanding. That is fine. 99% of today's apps don't that. Right tool for the job! But to me, the future is very clear.
I'm heavy into ruby too, but speaking pragmatically, it and elixir are playing different games in different ballparks. That's why I said they don't compete.
Are you kidding me? Look at Pusher, which is literally EM sitting behind Route 53
1) Immutable data throughout- prevents certain classes of bugs
2) 10x faster- obvious benefit
3) Actual macros- the ultimate metaprogramming: http://elixir-lang.org/getting-started/meta/macros.html
4) Functional paradigm- encourages decoupling of code by forcing state to be passed around explicitly as arguments, this also aids unit testing, it also reduces bugs further
5) Instant "forking" without having to worry about thread safety, and good semantics around it
6) Potential 99.999999999% uptime reliability (thanks to Erlang's OTP)
7) Hot-swappable code upgrades with no downtime
8) Pattern-matching reduces the amount of "switch logic" code greatly. In Ruby code I often saw complex logic branches with no test coverage- it's easier to cover those in Elixir when every "branch" is a different pattern-matched function
9) A bunch of neato things such as build-your-own-sigils, which felt even more "Ruby-like" than Ruby's own capability (or lack thereof) here: http://elixir-lang.org/getting-started/sigils.html
10) Trendy Actor model built-in from the get-go ;)
I like custom sigils, those are pretty cool, e.g. def sigil_i(string, []), do: String.to_integer(string)
But, having to put that char into the method name rather than argument, doesn't that limit the characters that you can use? Seems like would be better as arg.
Given Erlang is sometimes slower than Python [1] I am surprised if it's 10x speed improvement over Ruby.
1: https://news.ycombinator.com/item?id=9417453 (start at last comment & work up)
I believe for the sort of thing typically done in these sort of languages (which usually boil down to doing lots of string processing) Elixir may well be 10x faster.
The reason?
Lack of dynamism.
Function calls in python/ruby? SLOOOOOW
Function calls in Elixir? Hella fast, because it's all resolved at compile time, there's no dynamic lookup, no creating a locals dictionary for each call, etc.
(PS: Most typical web frameworks make a LOT of function calls - all that data sanitizing, templating, and formatting has to happen somewhere)
It's true that Elixir is slower if doing numerics heavy code since it can't just call out to a highly tweaked numeric library like NumPy.
(This is all talking single threaded, of course. With a parrallizeable task you won't even be in the same zip code.)
Erlang does not know the types flowing through a call site in advance and therefore has to do dynamic dispatch.
In particular, Erlang has a "code server" that all calls throughout the system must thunk through, versus a statically typed language where a call is optimized to a single JMP instruction. Smarter JITs, like Java's HotSpot, can also do this, and HotSpot is smart enough to inline both virtual and dynamic dispatch at runtime. BEAM can't.
Erlang's closest thing to a JIT (HiPE) cannot inline calls across modules, has no support for deoptimization, and is in effect a naive, crappy, AOT compiler which does the bare minimum to work in an otherwise dynamic environment.
Source: I made this... it was basically Elixir before Elixir:
These days I like languages that can actually avoid this overhead through the use of static typing, like Rust.
Note that it isn't necessarily bad that Erlang works this way. When it comes to Erlang's core strength: coordinating the concurrent activities of a massive number of processes/clients, it really does shine. Just don't use it for anything CPU-intensive.
I don't have much understanding of programming language internals but why we don't thing see low level stuff like distributed file system written in Erlang.
I genuinely interested in knowing why this is not tried by someone?
If your're looking for more traditional server stuff, there's RabbitMQ.
I get a lot of recruiting interest from my time at Powerset as an erlang engineer, from the most surprising places. Game companies come up a lot.
Please put down the kool aid. If you can't back statements like this up, you're not helping anyone.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
http://www.bigdatalittlegeek.com/blog/2014/7/10/ruby-vs-elix...
I liked Elixir a lot too, but when trying to pick the right tool, the learning required around Elixir/Erlang, the VM, and OTP didn't make sense when writing a production system that needs to handle 1000 req/s or more with a small staff. Go handles what we do fantastically.
Now you know someone. :)
At any large scale what becomes more important is fault tolerance. Even though Go has goroutines and sane and modern concurrent IO handling, goroutines still share memory. So then even a super fast 1M req/s system is no good if it is down 50% of the time because it crashed.
Also theres a good writeup on how Erlang was used for some of Call of Duty's infrastructure. http://www.erlang-factory.com/upload/presentations/395/Erlan...
Sounds like you're already committed to Go, but just wanted to make the case. Concurrent, fault-tolerant, highly scalable systems is Elixir's sweet spot.
[edit] One more, great talk from the Elixir Conf on how Martin Shurrer used Erlang to build a multiplayer card game. This one is particularly good because it deals with scaling, game states, and is very practical: http://confreaks.tv/videos/elixirconf2014-otp-in-production-...
Go was familiar from the jump, and easy to reason around coming from primarily Objective-C, C, Python, and C#. Considering timeline, it wouldn't have made sense to be so behind the learning curve.
With more time or breathing room, I think Erlang would be a space I'd jump into with both feet.
Edit: I know Martin through common colleagues and have worked with him in Austria. He's a great dev, and that was a good watch. Thanks for the link.
More importantly, I think, for some reason so many programmers just can't get past erlang's syntax. I've never seen any really good criticisms of erlang that made sense-- other than the syntax. While it was fine for me when I was doing erlang all the time I did spend a couple years away and find it frustrating again. So Elixir fixes that.
Further, there is no other language/platform that does distributed computing correctly, or on such scale, and with such battle testing. Haskell may do it correctly (I'm not sure) but it's very new. Go, Node.js, every "actors" library you can think of, they are single-threaded-thinker's attempts to scale, and they are not correct.
Yes, in computer science there is such a thing as "correct" and "not correct", and way too many young programmers seem to think popularity determines correctness.
IF you haven't learned Elixir and you want to write code that runs on multiple machines without a lot of hassle, and you've seen how tough this is to do on other platforms, head over to http://elixir-lang.org and learn. It's really a delight!
Edit: Fixed some typos. Oops. Want to add, my intention is not to bash languages like Go. Go has some good ideas and is appropriate for certain use cases. It's just frustrating to see these things being pitched as "distributed" when they have not incorporated the lessons learned building erlang over 20 years ago, and the 20+ years of development since.
Go, Node.js, ever "actors" library you can think of, they are single-threaded-thinker's attempts to scale, and they are not correct
Could you elaborate, or point to a resource comparing the different scaling strategies? What makes the Erlang approach correct?
https://pragprog.com/book/pb7con/seven-concurrency-models-in...
The book recommended by the other replyer is probably good. I'd also suggest you check out Joe Armstrongs thesis or his ProgPRog book "Learning Erlang".
There are many necessary things to do things right. It's not a single feature. Erlang the language, the VM, the OTP platform are a collection of all these choices...
All support parallelism as well as concurrency, and all can do so with an actor paradigm (and predictably, Node's support is the weakest).
Erlang's solution is more exciting because it offers a transparent mapping between local and remote code, so long as "transparent mapping" ignores the performance overhead.
Erlang's solution shines (in addition to reasons you cite) because of its efficient scheduler. That's something that you can't have in another language without essentially building Erlang itself.
1. Garbage Collection. Garbage Collection on the JVM is not isolated to actors. One actor causing a lot of memory churn will prompt a garbage collection and prevent all other actors from executing until the Garbage Collector is finished. BEAM (the erlang VM) has per process (aka per actor) garbage collection, so actors will not interfere with each other during garbage collection.
2. Shared Memory. Since the JVM does not provide proper isolation guarantees, actors can in fact access shared memory. Safety in concurrency is accomplished via best practices rather than guaranteed by the VM. The BEAM VM does not allow shared memory. It is impossible for two processes to write to the same memory. While this matches the convention in Akka, it is enforced at the VM level.
3. Scheduler. In Akka, actors are oversubscribed to threads. That's why you can have hundreds of thousands of actors on a single system. The abstraction is great, but the implementation means that calling Thread.sleep is going to tie up a thread. If you do that often enough then all the threads will get tied up and the rest of the actors will be unable to make progress. The BEAM VM handles this scheduling at a much lower level. Calling sleep on an Erlang process is no big deal. While sleep is a contrived example, the effect on the ecosystem is pretty big. Using a blocking HTTP client on Akka is a bad idea. You have to use something like Dispatch or Spray which is essentially callback based (via monadic Futures). In Erlang, you just make the blocking call and the scheduler takes care of it. Since the synchronous code is easier to reason about than asynchronous code, the Erlang solution is simpler, easier to maintain and often more performant.
I've spoken with a number of seasoned Scala/Java programmers who basically tell me "Of course you shouldn't do that, just do X or Y". With Erlang, I find there are fewer situations where you need to be an expert to avoid screwing things up.
But it's weird to call out actors oversubscribing to threads in Akka as a bad thing when that's exactly what Erlang's runtime does! And by the way, it's not difficult for even C to match the classic "quarter million execution threads" claim. Java certainly can with competitive memory overheads.
Competitive memory overhead in the Erlang world for a quarter million processes is 700MB (just sleeping). You can't do that with POSIX threads, where the default pthreads stack size on Linux is 2MB. Java adds more overhead on top of POSIX threads. As far as tuning PTHREAD_STACK_MIN on x86 is generally 16K, which is quite a bit bigger. So either you aren't in the same ballpark (factor of >5) or you have basically built a scheduler yourself (which is what Akka did).
I mean it can if you use their libraries. You just suggest that because calling out to a different I/O library is possible that we should only evaluate it in that context. This is basically a condemnation of ALL languages that host multiple abstractions.
> or you have basically built a scheduler yourself (which is what Akka did).
Riiiiiiight.. so... what's the problem there? Someone did what the erlang folks did on the JVM. Why is that used as a refutation here?
> As far as tuning PTHREAD_STACK_MIN on x86 is generally 16K, which is quite a bit bigger. So either you aren't in the same ballpark (factor of >5)
My comment was in regards to building a scheduler yourself (erlang doesn't have that many threads of parallel execution either) or using a technique with less demanding semantics like Fork-Join.
A lot of people have mixed up a lot of concepts here in the attempt to discuss why they like Erlang, but the truth is that it can't be nearly so efficient at scheduling and executing parallel computation as the average Java program appealing to java.util.concurrent, but is tuned for greater concurrency. It's also true that for some classes of computation Erlang's strategy works great, and for others it'd require substantial engine improvements to make competitive.
The impression given on this thread is that Elixir is the answer. I don't like that impression being left for people new to the discipline, because it's not how most people who are good at distributed systems or massively parallel AND concurrent programming think about the problem.
I just think it's not wise to try and represent the use cases that actor based excels at as primary for our industry or even somehow privileged.
It is true that you should not do this, and it's a fair point. Of course, you don't do it with Erlang either! Erlang carefully takes all file I/O out of their actor model and has it so that one (and only one) process can interact with a file handle. Operations to this have to be serialized by the actor. Since there is only one implementation of I/O and it's non-blocking, this works fine, but if your application is an actor pipeline you run exactly the same risk as your mailbox overflows. Needham's Duality is real.
And naturally that ignores the fact that JVM concurrency and parallelism can handle that outcome perfectly well (and in fact Akka appeals to these primitives). It's absurd to suggest that java.util.concurrent doesn't have great tools for parallel anything, let alone parallel I/O.
Golang, by the way, doesn't have this restriction. The runtime supports non-blocking, parallel-friendly I/O from the ground up.
And as for Node.js, well the general abstraction here is the most parallel of all. I'm not a huge fan of it and I agree it's a bit leaky, but Node's cluster stuff is serviceable and used by many. You cannot argue the actor model is essential, threadpools and actors ultimately model the same process and as Go has shown can do so with similar sharing semantics.
Finally, Erlang's scheduler is not black magic nor an arcane work of wisdom. It uses well-known, well documented principles and techniques. Quite frankly, its not the secret sauce of Erlang. Erlang's secret sauce is the HUGE some of very good code for building a distributed system with all the robust goodness that OTP provides.
Erlang's great, Elixir is interesting (albeit it took one stinky old syntax and exchanged it for another stinky syntax). I wanted to reply to that prior post and talk to why Erlang has a magical recipe for distributed code, not parallel code. Quite frankly, Erlang's parallelism story only makes sense in the context of its decision to make remote and local execution indistinguishable at the call site.
Callbacks and futures are very different modeling techniques and I'm not sure why you'd suggest they're inherently inferior. They have their uses just like the Actor model.
People obsess on the existence of blocking I/O (proponents of Node.js do this too) and I find it strange that this is still a subject of conversation. It's by and large a solved problem.
> Golang does solve these issues fairly well except for GC issues (which I've heard have gotten better).
Golang's GC issues were no to much about GOMAXPROCs as just needing a really good optimization pass. As a younger language, it's unsurprising it needs some time to reach production readiness. Erlang has the benefit of many years of testing in anger.
He's not saying it isn't possible. Everything is possible with assembly, it doesn't mean assembly is a good choice for distributed programming.
> and all can do so with an actor paradigm (and predictably, Node's support is the weakest).
There-in lies the problem. The main benefit of actor programming programming is about programming with isolated actors. Such that one actor doesn't see the heap or memory of another one. Because at a large enough scale fault tollerance start to become more important than other things. If a single goroutine panics and takes down other 100K connections, it doesn't matter that it is lighting fast or cool or whatever, it will be broken.
In other words langauge that claim "Erlang-like concurrency" never get is right. They put a queue and a thread together in a class and call it "Erlang". But that is not Erlang. The closest thing to Erlang's model is probablh the operating system with its processes.
It even makes sense to think of your code in that way -- your langauge platform is an OS for your code. If you write in Erlang or Elixir you are writting on a modern sane OS like Linux, Windows, OS X. If you are running with pthreads or goroutines, you are back to Windows 3.1.
That's not really right.
> It even makes sense to think of your code in that way -- your langauge platform is an OS for your code. If you write in Erlang or Elixir you are writting on a modern sane OS like Linux, Windows, OS X. If you are running with pthreads or goroutines, you are back to Windows 3.1.
That's not true at all. I have no idea why you'd try and use such an emotionally loaded argument. Just earlier in your post you made a point that different tools have different sweet spots.
The Actor model is useful for some things, but not all. There are many effective techniques for parallel computation that do not rely on the actor model. There are several ways to model distributed computation that are not the actor model.
My principle objection to this entire thread is that people are making a mistake ignoring these other techniques and in fact directly misrepresenting the state of the art for the sake of their rhetoric about Erlang. By and large, the Erlang community itself tries not to do this!
Also "new" is one of those things that I think changes perspective with age. Probably when you're younger newer things seem more established than when you're older and looking at a longer time horizon. No offense meant to haskell. :-)
Here come Elixir and so far it have decent momentum. It got mix, ecto, etc.. tools. And all of a sudden the creator started to contribute to Phoenix framework. It got 2 books now and an OTP books coming out.
In general, I think Elixir is executing pretty well. If pheonix hit 1.0 that is comparable to RoR and can make restful service dead simple with oAuth, elixir might have a chance.
edit:
From what I've gathered:
The blog posts and online community of Erlang is mostly technical. The community at the local meetup is very against new ideas, they're stuck in a cycle of continuing the same path while complaining about how to get adoption rate up for Erlang...
I like N2O a lot: https://github.com/5HT/n2o
I have considered in the last year learning Erlang 1 or 2 times just after stumbling upon it again in my history and being very impressed by feature lists and basic stats.
I even saw a sample Elixir project. Very cool stuff.
For what it's worth, it already does: OTP.
I don't agree with this. Erlang has already frameworks but that is not the selling point of this language and environment. For me the reason to use Erlang is the concurrency patterns and the tooling. RoR is great to get you off the ground but when you hit bigger scale you have to replace it with something that is more memory efficient and supports high number of concurrent connections. Several companies proved this including Twitter, Opscode etc. Erlang on the other hand lets you to use the same environment from day 1 to the time when you have 10M+ active users. You have to work on it but it is possible and there is no need to ditch the entire system because you got popular.
I'm happy for Erlang to never have a decent web framework. I prefer Erlang (I don't write webapps) but point everyone to Elixir and Phoenix if they want to do webapps.
Have you looked at Chicago Boss yet?
I'm curious what will happen in the longer term, if at some point the 'upstream' providers of the erlang ecosystem will take notice of elixer and will start to cater to it and then maybe actually adopt it. Until then I'm on the fence, elixer could be great but it also could end up being abandoned as more and more warts in erlang are taken care of.
And most of those warts are cosmetic rather than real problems, the lack of libraries will hurt both languages just about the same and it would be much nicer if new libraries were written with interop in mind.
That way they will have staying power regardless of which language will eventually become dominant/stay dominant.
The erlang vm and ecosystem are very well thought out, battle hardened and solid beyond what most programmers that came into the profession past say 1998 or so are familiar with but it is clearly showing its age and elixer solves some of those problems. A more open process around erlang itself could easily take the wind out of elixer's sails.
Time will tell, it sure is interesting.
And thanks David, excellent post.
edit: it could actually be that elixer will drive developers to erlang in the longer run, the syntax is a minor nuisance easily understood after a little bit of work and the 'strings' issue is mostly a different take on an old problem that you can either work around or simply accept as part of the deal. It can throw you for a loop but not worse than the things other languages will force on you and if you think about it is actually an elegant solution, re-use the same data structure to make life easier.
If under the hood those lists would be replaced with something like the clojure ones you might be able to get rid of the performance issues entirely without affecting the code already in production (unless it was C code operating directly on internal structures of erlang).
I've mentioned this before but I'll daybit again. Protocols and Macros are the game changer. The Enumerable protocol absolutely changes the way you write code and solve problems. Doing the same thing in Erlang is just not the same.
Elixir is gaining popularity _because_ of the Erlang VM and libraries. Yes, macros, protocols, syntax, etc may attract a first glance at the language, but I believe people stay and evangelize Elixir because of the power of Erlang/OTP.
Likewise, I think Elixir popularity will only drive Erlang, Joxa, and LFE popularity forward as the initial roadblock of grokking the Erlang VM and how OTP works are overcome.
There is no descriptive text on the landing page aside from "Build Better Erlang" which i guess narrows this down to some sort of erlang developer tool. The Getting Started page has no mention of what we are installing actually does aside from a snippet in their console output log "you can use rebar to build OTP-compliant apps". So its a build tool? Not until "Basic Usage" do I find out in writing what rebar potentially is:
"Rebar3 comes with templates for creating applications, library applications (with no start/2), releases and plugins"
So it's a project templating tool? Does "comes with" mean it has more functionality than just templating? On the sidebar I see some terms that lead me to believe it can do more than that but I would love something on the landing page that told me exactly what the tool's purpose or function is.
From my understanding it is a tool similar to Leiningen?
Rebar3 is the next version of it.
But you're entirely right, the page and documentation is lacking to people unfamiliar with the Erlang/OTP ecosystem.
How so? A framework can very much be (and often is) a reductionist endeavor: the sum of its parts connected by entry points. Particularly ones that are loosely coupled, as the one you alluded to (Chicago Boss) is
If someone is not well versed in Erlang, they should probably learn Erlang before starting a project in it. Chicago Boss still makes implicit much of OTP, the process model and records that it's easy for beginners to jump in, though.
Their friend, using Elixir, will at least have something up and running in short order.
Once again, this is just as applicable to Erlang.
A package management system, “hex”.
Do people even know why they want/need a hundred language-specific package managers anymore, or is it just a cargo cult thing to do? No, a module system, a dependency resolver (Rebar) and release management may push you out of your comfort zone a bit compared to the typical do-everything package manager blob, but it's very much doable.
Ecto database driver, with Postgres as the first database integrated (yay!).
Ecto looks more like ActiveRecord, but there's nothing particularly wrong with BossDB. The fact that BossRecords are serialized as proplists means you can perform relatively complicated operations by using list comprehensions alone. Oh, but you have to learn some Erlang. No avoiding that.
Ecto migrations.
I might grant that. BossDB migrations aren't particularly advanced. Not sure how well Ecto fairs in to it.
Porcelain, for working with external processes, where Erlang is somewhat lacking
https://github.com/msantos/alcove
https://github.com/msantos/perc
Latter is old, but the point remains. Port drivers and NIFs can easily bridge the gap from the Erlang VM to the host OS, and it seems that Porcelain uses exactly the former, at least.
No, they aren't, they were "the simplest thing that possibly worked" for my needs (I wrote that code).
One problem with boss_db is that it uses some heavy duty compiler magic that none of the "pure Erlang" kinds of folks really want to touch because it produces un-Erlangy code. This leaves it in a no-man's land: the Erlang people don't want to deal with it, and the people coming in from Ruby or whatever are just going to go straight to Elixir which looks more familiar anyway.
It's not really an indictment on Erlang, though. The situation you present is unwinnable.
My wish is that Ericsson's Erlang development team became more transparent to the outside world, shared their bug tracker, code reviews (Go team does this wonderfully) and did all development in the open. Then we would not have these situations https://github.com/erlang/otp/pull/687 and it would save me ton of time couple years ago chasing after ssl bugs.
It caused a bit of hassle, but not much, really. It was a feature that many Erlang people did not like much in the first place, so heavy use of it put them off to begin with.
Reminds me of Microsoft's .NET development process from 10 years ago, huge corporation drives development of a platform behind closed doors with very few people from the outside having any idea what is coming in the future.
But pmods shouldn't be used like an example of them going against the community in driving the language forward. Very very few people in the community objected to their removal. Many of us were happy and thought it should have happened much earlier.
It seems they have been planning it for a while. One of the things that looks nice about Elixir is that there is a lot of doing, as well as planning.
Any language nowadays that doesn't have a package manager has kinda already lost as far as practical development goes.
It's nice to see Erlang folks adopting Hex in places.
Adding hashes to erl is a good start, and joeerl seems very open to more. There is certainly more to come in both camps, and that's good for everyone.
[1] https://github.com/h4cc/awesome-elixir [2] https://github.com/drobakowski/awesome-erlang
What are the things Erlang has traditionally done well? In what domains is it generally used now?
For a language that has been there for 29years, it's very hard to get such momentum.
I actually wrote about Erlang's "strange birth" - for an open source language, at least - here: http://journal.dedasys.com/2009/06/18/the-erlang-paradox/ and what it has meant for the language. Basically, that it was born into a production environment and therefore very difficult to change much once it was released into the wild.
IMO Elixir does a great job at reducing the inherent complexity of the Erlang syntax, while keeping its powerful features (Erlang-procs, horizontal scalability, fault-tolerance).
And an unnecessarily verbose one.
def foo(bar,baz) do
...
end # foo
If you really don't like `end`, you can also (at least with Elixir) use the shorthand form:
def foo(bar,baz), do: ...Alternately: what's wrong with `end`?
This is already possible with other VM-centric ecosystems (particularly the ones surrounding the JVM and the .NET CLR), but it feels like the BEAM ecosystem is making that sort of interoperability more of an explicit goal.
Ok, the syntax is weird (and sometimes infuriatingly so), but I didn't find it that hard to learn, and I had never seen a functional language (I came from mostly PHP, with some perl, and a small amount of C and/or C with a C++ compiler, and a little bit of Javascript). Single assignment is new and different, but really the only thing that really causes problems with is something like a for loop; and you learn the two or three ways to do a for loop differently pretty quickly. C, Perl, PHP and Java all have function pointers too, you just don't use them as often.
The important thing is starting to learn Erlang on a project that has a lot of concurrency, so you're making that part of the project easier in exchange for having to learn to think a little differently.
See also this related thread on the Elixir mailing list https://groups.google.com/forum/#!topic/elixir-lang-talk/ft6...
[1] https://github.com/jeremyjh/dialyxir
[2] https://groups.google.com/forum/#!topic/elixir-lang-talk/yDX...