Elixir Release v1.0.0
github.com
github.com
Syntactically, it's a pleasure to use as a long-time Ruby guy, which I suppose is no surprise given José's presence in the Ruby community.
However, all of this aside, what makes me the most excited about Elixir is José, himself. It's been my experience that when a language/framework has a BDFL, something of that person gets infused into its community. Anyone who's interacted with José will tell you he's an incredibly friendly, humble, and downright thankful person.
Elixir is set up for success in so many ways, but the community aspect is the one we just can't afford to ignore.
I vastly prefer Erlang syntax to Elixir's, but IMO it's way too early in the game to say this. In the unlikely event that the people who were attracted to Elixir because they couldn't handle Erlang's syntax can manage to grasp OTP, I imagine that Elixir would ultimately kill Erlang dead. An Erlang that has the same power and expressiveness, runs on the same VM, and is completely compatible - but looks like Algol - would be an irresistible force.
Elixir is more visually similar to Ruby, sure, buts its substantively not very similar, so the visual similarity is, if anything, a detriment, IMO.
For the typical programmer coming outside the Erlang/Elixir environment, Elixir is by far the more familiar and easier to pick up.
In any case, yeah, I'm not saying that my personal Erlang vs. Elixir response is anything more than my personal response (or that Elixir isn't valuable; its certainly something I'd like to find time to explore more deeply and I think it has a lot to offer.)
The meta-programming on the other hand may well be a huge draw to Erlang shops.
My company is currently looking for Elixir/Erlang devs to help us build a new decentralized communication platform. Based in London/SF.
If you or anyone is interested, please ping me at ryan@spatch.co.
If I wanted to quickly prototype some highly concurrent service, I'd probably use Go. If I wanted to engineer something that is incredibly scaleable and fault tolerant, I'd probably use Elixir.
The C-ish-syntax and procedural nature of Go is likely to give it more mindshare in the programming community, however, and that can't be ignored.
[1] http://joearms.github.io/2013/05/31/a-week-with-elixir.html
- funs have an extra dot in the name: not fixed because that will lead to inconsistency [1]
- send operator: removed earlier this year and the operator is reincarnated as comprehension operator (comprehension being more ubiquitous [2]); although, the proposed syntax wasn't adopted
Not sure about funs and def. It appears that not much was discussed about versions in source file and docstrings inside function definition (module doc is already inside); the later one can be dismissed being a common bikeshed in PL design.
So, yeah, most of the proposals couldn't make it because of complications.
[1] https://groups.google.com/d/topic/elixir-lang-core/_kEBXO0NR...
[1] http://confreaks.com/events/elixirconf2014
[2] http://confreaks.com/videos/4119-elixirconf2014-opening-keyn...
I started when I was first learning Elixir. Was already a pro with Ruby and had around 3 months of Erlang experience at the time. The first video was nearly my first experience with Elixir ever. Some of the more fun projects I've built with it have included synthesizers, API clients, and websites.
The release of 1.0 gives me goosebumps. José's done great work, and always does.
The Erlang VM is a beautiful piece of engineering - anything that brings people into its orbit is good for programming.
Phoenix is a great example that has used Exilir to create a DSL that is similar to Ruby on Rails.
http://www.littlelines.com/blog/2014/07/08/elixir-vs-ruby-sh...
I think I can very closely relate to Dave Thomas when he expressed his excitement about Elixir and how similar it was to what he felt when he first encountered Ruby. Early last summer I took a fairly deep dive into Elixir and discovered that it left me with the same feelings as when I started to explore Ruby at the suggestion of my then boss many years ago. It just made sense. From the structure of an application to the way pattern matching works and even the larger ecosystem. I know a lot of people compare Ruby and Elixir because of the superficial syntactical similarities but there's something deeper there that makes me almost giddy: once you know the basics a lot of the rest just sort of seems to fall into place. Unlike a lot of other languages the learning process isn't filled with head-tilting moments of confusion, just lots of nodding up and down while thinking "Of course that's how it works!"
I'm kind of wondering whether Go is not already eating into Erlang (and Scala). I am not an expert, but I understand that Go is not at par with Erlang today, but I am wondering about a 3-year bet for a startup.
Go can try to reach parity with Erlang one day...but Elixir already is Erlang...That combined with the fact that Elixir's package management already feels light years ahead of Go's disaster and I think it's a winner. I'm sure I'm wrong and the flames of Go lovers will engulf me in the responses, so take this with a mountain of salt.
I may be short sighted, but I seeing the ecosystem around Go to be much more ... accelerated than Erlang.
Advantages over Go:
1. Reliability (OTP, supervisor, pre-emptive scheduling)
2. Clean code (error handling, higher order functions)
3. Far superior package management
Advantages over Erlang:
1. Extensible (Macros)
2. Familiar syntax for Rails developers
That being said, Go definitely has the advantage when it comes to marketing/hype (Google, Unix daddy etc), which as you can judge by the success of Node and Mongo, sadly trumps technical merit even in the tech community.
It's an incredibly cohesive language that doesn't appear to have any serious flaws, as far as I can see. It's impressive that it's come so far along in such a short amount of time.
I was following their progress and there was a constant and steady stream of changes over the last years.
Disclaimer: I studied Erlang before Elixir, so I don't have a fresh perspective.
By "programming model" I mean things like immutability, concurrency, fault-tolerance, and the way you design systems with OTP.