As a rails developer primarily, and someone dabbling with Elixir/Phoenix on the side, I get this feeling, too. It's taken the best of rails, dropped the annoying parts (e.g.: weird pluralization stuff, magic connection between instance variables in controllers and views, an explosion of path helpers (Phoenix's approach is basically post_path(:index), post_path(:show, 5), etc.)), and then put it on the rock solid Erlang VM.
I remember hearing the "genesis story" of Elixir. IIRC, José was working on ensuring Rails was thread safe. He did so, but was dismayed with the difficulty and felt like he was fighting Ruby. So he stepped back, and thought that if concurrency is the future, he should find a better language for it. He looked into immutable, functional languages (Haskell, Clojure, Erlang), and realized that Erlang is built for an arguably harder problem: distributed computing, and made the connection that concurrency is sort of a smaller case of that. He worked with Erlang for awhile before deciding that it could be improved by building on it.
Going through the Elixir tutorial and seeing how you could "simulate" state, by spinning up an infinite loop in another process and sending messages to it was mind bending. And learning about Erlang's OTP principles has made me really think about robustness differently. I really do hope Elixir/Phoenix become the next big language and web framework.
I don't know much about Elixir but it seems like a really interesting language. The space it's trying to fit is definitely something needed: a good, flexible, high level language like Python/Ruby but with strong concurrency support and a functional paradigm.
Can anyone give more information on the nature of Elixir's type system? Without digging into the docs I see elixer-lang says that its dynamically typed, but how strongly typed, is it robust, does it have ADTs, inheritance, etc?
edit: looking an inch deeper, I see that it has 'protocols,' which seem like typeclasses, and 'typespecs,' which seem like gradual typing
For type-safety, you can (optionally) add what are called type specs to your code with are processed with an analyzer tool called dialyzer [1]. This will identify errors related to types, as well as a few other kinds of errors.
This doesn't work with Elixir directly, but rather BEAM byte code (Erlang VM) which Elixir compiles down to.
I think part of it is that with Erlang it is not as easy to get up and running with a new website.
I'm doing this at present and there is no special difficulty.
And things like package management, build tools, meta-programming, unicode handling and web frameworks are not as straight forward as in languages such as Ruby.
Erlang's module system means that a chunk of the raison d'etre behind language-specific package managers is already alleviated. The rest - dependency management and building, is handled quite well by tools like Rebar. One can also leave Rebar as a dependency tool strictly (which is its primary purpose anyway) and use whatever they like for a build system. Plain old Makefiles can work just fine, and it's not like most language-targeted build systems aren't some shiny variation of make, anyway.
Metaprogramming isn't quite as easy as in many OO languages, but it's hardly out of reach. The parser, the lexical scanner and other components are all exposed as Erlang modules, and there are projects such as the BossDB ORM that use parser transforms to provide features such as parameterized modules, which allow for using Rails-like ActiveRecord patterns, among other things.
Unicode handling? I think this might be a knock on Erlang's string handling. Strings are represented as iolists of Unicode points (integers) which goes with much of Erlang's philosophy in lists and tuples as being the prime data types. Space efficiency and real-world usage usually has strings passed as binaries, but most web frameworks and libs can handle them plainly nonetheless.
Web frameworks? Chicago Boss for a Rails-like, Nitrogen and N2O for real-time and extremely high load applications, or even just plugging in to web servers like Cowboy or Yaws can be enough for a RESTful backend.
> Erlang's module system means that a chunk of the raison d'etre behind language-specific package managers is already alleviated.
Sure, modules provide a way to "package" functions, but that is 5% of what a package manager does. Being able to distribute, fetch and do dependency resolution is certainly the bulk of it.
I definitely prefer my deployments to rely on packages than fetching git repositories from Github and Bitbucket. There are recent discussions in Erlang mailing list regarding packages and the OTP team (the team behind Erlang) is looking into package managers too.
> The rest - dependency management and building, is handled quite well by tools like Rebar.
Sorry, Rebar does not handle dependencies well. Rebar does not even guarantee repeatable builds. Once I fetch dependencies on my machine, my co-worker can end-up with versions different than mine and that is dependency management 101.
Rebar 3 seems to improve in this area but is still alpha. erlang.mk idea of package manager is a file on github in tsv format (and still no repeatable builds).
> Unicode handling? I think this might be a knock on Erlang's string handling.
Erlang needs better unicode support, regardless of using lists or binaries. Strings support only latin1 in literal format. If I want to write my name as a binary, it needs to be written as <<"paweł"/utf8>>. This is nowhere close to acceptable to anyone that has to write strings in formats other than latin1.
Things are getting better in Erlang 18 but there won't be any conveniences for handling unicode. There is no function to calculate the grapheme length (essential if you want to support languages like japanese or korean and do a size validation on an input), to convert to lowercase/uppercase and so on. Be it if the underlying representation is a list or a binary.
> Sure, modules provide a way to "package" functions, but that is 5% of what a package manager does. Being able to distribute, fetch and do dependency resolution is certainly the bulk of it.
Please God the Erlang/Elixir community don't invent another package manager. Pip, easy_install, gem, npm, composer, bundler, bower, maven and all the others I don't know about - we've got enough as users to remember the variations in syntax for. Let alone the duplication of effort in developing and maintaining the package managers, when their clever creators could be working on other problems.
Maybe someday someone will just create one package manager to rule them all, one that's not tied to a specific language, but can instead manage anything running on your computer.
I think you're setting the bar a little high there. Reproducible builds is something that most package managers, OS and language-specific alike, struggle with to this day. Only Nix and Guix have complete solutions, I think.
When I wrote "not as easy" I did not mean simply difficult. It just takes a bit more work with Erlang.
As for Erlang string handling: [175,95,40,12484,41,95,47,175] ;)
The good thing is that Erlang and Elixir can benefit from each other. For instance https://hex.pm which is made in Elixir, but can also be used for Erlang projects.
My point was to ask for clarification as to what said work entails and how it's larger than, e.g. Ruby or another mainstream platform for web applications.
I just tried running Chicago Boss. I followed the quick start guide that had a lot of steps and managed to get a 404 error.
With Rails there are less steps:
gem install rails && rails new path/to/your/new/application && cd path/to/your/new/application && rails server
and you just point your browser to http://localhost:3000 and get a nice welcome page for your new skeleton app.
The reason for the 404 is because by default no action is bound to / in the proplists for the priv/<appname>.routes file. It tells you that quite succinctly. Explicitly heading to /greeting/hello works, as shown in the quickstart. Modifying the routes file is a good next step.
Your complaint boils down to there not being a pretty "Welcome" page. That could be addressed, but it's hardly a major concern.
No it is not how it looks it is that the documentation is lacking. The quick start didn't work for me. If it had been a simple page returning HTTP code 200 that just said OK, it would at least be something.
Sure you can make it work if you invest more time in it, but the point is that there are other platforms that have taken care to make it easier.
In general a lot of people seem to think that documentation is one of the biggest issues with Erlang.
Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go. Or where Go didn't live up to its promises?
Some of this is opinion, but I looked at Go and didn't like its exception model (or total lack thereof). Checking for errors after every possible bit of code that could go wrong seemed like an ugliness to me (disclaimer: beauty is in the eye of the beholder, and I'm certain a Go guy will chirp up here in its defense... which is fine!).
Elixir/Erlang almost couldn't be more different in this regard, which basically embrace runtime failures (things fail, so... "Let it fail quickly"). An uncaught runtime error in Elixir/Erlang causes the node to shut down after logging the error and, if it has a supervisor node (which is quite likely), the node is restarted in a fraction of a microsecond. The developer is expected to monitor the logs and watch for common faults and fix those. This is in fact where the "nine nines" reliability comes from- restarting nodes extremely quickly after runtime errors.
The Erlang philosophy is basically, "these systems exist in the real world, which is sometimes unpredictable and flaky... accept it and allow the code to move on quickly." This happens to be a good strategy for website code- Remember that Erlang was built to run cell networks... How often are cell networks down these days?
I was also a "disenfranchised" Ruby guy, tired of working on classes of bugs that would never even see the light of day in a functional language, which is why Elixir's syntax was appealing (I had already looked at Erlang, but I didn't like its syntax). Again, there's taste and opinion here, of course. Coding has become awfully fashion-driven, of late.
There's a class of programmers who don't care about syntax or don't see the point of it. Ruby/Rails folks are not typically that type of programmer, and that's the first group who will likely migrate to Elixir.
Finally, what really raised my eyebrows about Elixir was its macro facility http://elixir-lang.org/getting-started/meta/macros.html Prior to Elixir, full-fledged macros were only a feature of homoiconic languages (the Lispy ones where the syntax is also a data structure). Elixir came up with a clever way to do macros, while retaining syntax.
> Again, there's taste and opinion here, of course. Coding has become awfully fashion-driven, of late.
I agree and that's a really enlightened view. But I'm quite glad - it means the ecosystem is maturing if we now can be fashion driven, rather than having to care about "does it work?"
I really like this language, I've met Jose Valim and he's a super nice, super smart guy, as is Chris McCord. So I feel naturally motivated to promote it. Also, it's just lots of fun to work with!
> it means the ecosystem is maturing if we now can be fashion driven, rather than having to care about "does it work?"
Well in my case, as I said, I got tired of certain classes of Ruby bugs, and certain, shall we say, "uglinesses" which presented themselves, but only after (sigh) YEARS of working with Ruby. In a way that's an argument FOR Ruby! It will only start to look ugly years after you work with it. ;) More than can be said for MANY other languages!
So far I haven't seen too much "ugly" in Elixir (which is good, as it should be in the "beautiful bouncing baby" phase!). In fact, in some ways it's even more Rubylike than Ruby is, such as with being able to define your own sigils: http://elixir-lang.org/getting-started/sigils.html And of course the macro facility is pretty much the ultimate definition of Ruby's oft-touted "metaprogramming." Chris McCord already has a book out on it, actually: http://smile.amazon.com/Metaprogramming-Elixir-Write-Less-Co...
> Given some were touting Go as the next big language what - 12-18 months ago - can anyone enlighten me why Elixir would be different to Go.
Its a completely different language, with a completely different set of people thinking it is the way to go going forward. They have very little in common.
> Or where Go didn't live up to its promises?
As there are in the present, there will probably be more than one significant web application language in the future. Its not impossible that Go and Elixir could both be among them. Its not really an XOR type of situation.
I think it's too early to tell whether Go will live up to it's promises. However, the promises of Go are generally shit: Go has promised to help us relive the horrors of static code generation and empty interfaces in exchange for being able to compile our shitty code quickly.
I'm also not sure elixir is so great (not enough experience with the language and no time to try it right now) but at least at a glance it seems to put a cleaner face on some of Erlang's strengths, so at least it brings something new to the table.
I used Weber when I first got into Elixir a little over a year ago. It was a cool framework and I even contributed to it (mostly keeping it up to date as new versions of Elixir were released).
But... the last commit was 9 months ago. Weber is dead. If you're interested in doing web stuff with Elixir today Phoenix is what you want.
2. Uses Javascript (tons and tons of developers know at least enough to use Meteor)
3. Sane templating engine.
4. Same wow effect I had when I first started Rails.
5. Fantastic build system.
Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. Looks interesting but that's the reality.
1. "Realm-time" isn't baked in. It certainly comes easier to write real-time programs (for some definitions of real-time) than in some other environments, but real time programming doesn't come for free in any environment. You're overreaching with this claim.
2. Tons of programmers know JavaScript well enough to avoid it. A language originally thrown together "to make the monkey dance" is generally a poor choice.
3. Sane templating engines are a dime a dozen. I could probably find 5 in Python alone.
4. Same later realization that it's really good at a few things at the expense of others, I'd bet.
5. Okay I'll cede one point.
> Pheonix and Elixir may be the bees knees, but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages. Looks interesting but that's the reality.
That says more about you than about the quality of tools involved. I'd rather have quality of mindshare than quantity.
> but unfortunately because it uses a functional language, it drastically cuts down the mindshare of developers. I don't even know any developers in real life that use functional languages.
1) Once upon a time, almost no one used object oriented languages except for Smalltalk weirdos.
2) Ruby, javascript and a host of other languages have "functional" features. Does your language have a "lambda" feature, where you can define nameless functions and pass them around as arguments to other functions? Then you are already working with functional language paradigms. There's nothing really "magically hard" about it, you're overselling how hard it is. This is not rocket science. Most existing programmers can handle it.
The hardest thing I had to wrap my mind around when switching my work to Elixir was letting go of mutable state. And attributes and methods on objects. And guess what... It seems that it's a good idea, generally!
If you see enough bugs that are only there because something modified an attribute in some unpredictable way which impacted upstream code... You will realize mutable state is bad.
If you still aren't convinced that mutable state is evil, watch this Rich Hickey presentation http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic... which basically proves that mutable state actually makes state a function of a hidden/conflated "time" variable, proving it's not just wrong from a practical standpoint (in the form of extra bugs that are hard to reason about, and all this brittle mutex code) but from a theoretical one, too. Mutable state comes from a time when memory was expensive, and it's time to ditch the training wheels so we can get the real work done.
Both Javascript and Ruby use mutable state extensively, and it's unfortunately not something you can just slap onto the language after the fact (although ClojureScript must make a valiant effort!) And if the high-level language wasn't built with it from the get-go, then you're stuck dealing with legacy libraries using the poorer-written code (see: Ruby gems).
Another fad brought up for the sheer fashionability of it.
Saying "mutable state is bad" is just as inane as saying "immutability is bad". There are tradeoffs for either. There is absolutely no reason to pretend that one trumps the other in all cases.
Nobody's "pretending" that immutability trumps mutability. Rather, we're observing it firsthand. By making immutability the rule rather than the exception thereof, one eliminates a huge swath of bugs and makes an even bigger swatch much more difficult to achieve.
That said, you're right that there are tradeoffs, which is why languages like Rust - while defaulting to immutability - allow a programmer to define variables as mutable, and why Elixir (unlike Erlang) allows variables to be reassigned (though the data stored in those variables is still immutable; this is something that's enforced by BEAM).
And of course, you can still get many of the benefits of immutability with mutable variables by being careful about how you're using those variables; the difference, however, is that a language which assumes immutability will be able to catch those bugs more easily, forcing the programmer to fix them (either by making the variable mutable (in applicable languages) or refactoring until mutability isn't necessary).
I spent over 10 years writing and working on (and debugging... many hours of debugging) Ruby code.
Towards the end I started to write all my Ruby code, as much as possible, as so-called PORO objects (Plain Ol' Ruby Objects). These feature zero inheritance, and are initialized with all the state they need to do their work. I started doing this because I found that writing code that way produced more easily testable, more maintainable, more stable code.
Then I realized that functional languages basically all already forced you to do those things, by not holding state anywhere, forcing you to pass it around.
These were all logical steps (with the end goal optimization of "useless work elimination"). There was no faddiness involved, other than having "a good feeling" about working with Elixir (over, say, Clojure, Haskell or the other options out there).
JavaScript has functions. The list pretty much ends there. There are some libraries that provide "functional features" like functions over collections, persistent data structures, promises. The language itself and the environment it's running in (DOM or Node) do not have a lot going for them in terms of functional programming essentials.
I like Meteor and have been learning it but it's not without it's drawbacks. It's basic design of loading a javascript app which then receives data from the server and renders the page makes load times kind of sluggish - compare HN and https://crater.io/ which is Meteor's HN equivalent. I've yet to find a Meteor site that's snappy. Also the design makes things like uploading photos a pain. If you look at the user pics on crater.io they are hosted on Twitter and Wordpress I think partly because doing that on a Meteor server is awkward - I've been writing a Meteor photo uploader and it can be done but most Stackoverflow answer suggest to give up and use S3. I wish them luck though.
plus, you can use (or mix&match) other languages that compile to JS if you want. Coffeescript is the most popular choice (I code in literate coffeescript by myself), but stuff like livescript adds some more functional features as well.
Elixir has first-class support for defining custom types and adding type annotations (specs) to functions. There's also a tool that makes it very easy to run dialyzer on your code: https://github.com/fishcakez/dialyze
I thought Erlang was abandon within Ericsson, and it was Open Sourced so people can continue to use it.
Can anyone explain what is Erlang Public License? Why not something like Apache, GPL or MIT?
> I thought Erlang was abandon within Ericsson, and it was Open Sourced so people can continue to use it.
It was temporarily "abandoned" because Ericsson had (has?) a policy forbidding the use of non-free languages. In response, the Erlang devs open-sourced it, and now (IIRC) it's not banned anymore.
> Can anyone explain what is Erlang Public License?
It's derived from the Mozilla Public License. It differs mainly in terms of legal jurisdiction (i.e. Swedish law being specified as the applicable legal jurisdiction).
> Why not something like Apache, GPL or MIT?
Good question. The answer's probably similar to the reasons why Mozilla created the MPL (partial copyleft, in contrast with the GPL's strict copyleft, and with the Apache's and MIT's and BSD's and crowd's copycenter/copyfree).
Erlang/OTP is being developed continuously, primarily by a team at Ericsson. They ship one new major release roughly once per year, with a few minor releases in-between.
I've been monitoring Elixir on HN for a while now, looks like an interesting direction to take.
I wanted to know which direction Elixir is going to take? Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir?
Is there a plan to change Rails enough to run on Elixir?
How does the community feel about Elixir? I'm certainly interested in the concurrency aspects of Elixir (ie. no GIL) and everything else that Erlang has to offer.
The developers of Elixir were core Rails developers so please forgive me if I'm getting the wrong impression here.
> I wanted to know which direction Elixir is going to take? Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir?
Elixir is not even approximately compatible with Ruby, nor is it intended to be. It just has syntax that is very loosely reminiscent of Ruby. Someone might one day write a Rails-like framework for Elixir, but it will never be the same Rails that runs on Ruby.
OTOH, if you want something no GIL that can run Rails, there is always JRuby.
> Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir?
Most likely not. However, it might be possible to run Ruby programs in OTP-style supervision trees, thus managed by a supervisor written in Erlang or Elixir of LFE or some other BEAM-based language and thus made able to leverage some or all of the advantages of Erlang (a good potential proof-of-concept would be a replacement for Puma or Unicorn or Passenger - in other words, a Rack-compatible web server (or wrapper around an existing web server, like Cowboy) written in Elixir or Erlang or LFE or what have you).
> Is there a plan to change Rails enough to run on Elixir?
Also most likely not; most of the Rails community is currently heavily dependent on the Ruby ecosystem, and there's not really much of a point in changing that.
That isn't to say that there's no place for Elixir in a Rails development framework; there are plenty of Rails shops that use Erlang for dispatching requests to Rails instances (I believe Github is one such shop).
> How does the community feel about Elixir?
The Elixir community obviously feels elated :)
The Ruby/Rails crowd is a bit harder to read. I personally work for a Rails consultancy, and right now my coworkers don't seem universally interested in it quite yet. That may change in the future, though, especially as more folks realize the merits of using Elixir and Ruby side-by-side and more packages (whether from the Ruby side or the Elixir/Erlang side) are developed to allow easy communication between those two worlds.
The Erlang community seems to be mildly positive about it. At least one of Erlang's original creators has expressed a modestly-positive opinion of Elixir's direction (with a particular excitement about Elixir's Clojure-inspired "|>" (pipe) operator - something that a lot of Elixirists seem to like using, myself included). There's some deviation from the more Erlangy ways of doing things, however, and it's not as mature as Erlang itself, so (from what I understand based on my observations of the Erlang community - particularly mailing lists and conference recordings/transcripts) there's still a bit of resistance there.
Rails is just one way to solve data problems. I don't see Rails being written in Elixir as it is not a functional way to solve that problem. Nothing against rails it is a good way to solve the problem in a modern object oriented way though Active Record has it's issues as well.
Not about Elixir specifically, but don't people get tired of switching languages? What, people will now have to port all Ruby libraries to Elixir (or, at the very least, relearn them), and then a few years down the line to the next thing? Isn't this a huge waste of effort? Not to mention the poor CTO who gets a job at such an early-adopter company in 15 years, and finds out the codebase is made up of 7 different languages, four of them have been defunct for years? I mean, a language's benefit must at least cover all the switching costs, the fractured codebase costs and then some to justify adoption. Are all the new languages such huge advances over older ones that they do that?
> Are all the new languages such huge advances over older ones that they do that?
I don't know about other languages, but having personally migrated from Perl and Ruby to Erlang/Elixir, I at least believe that to be the case in that particular circumstance.
A big part of it is that parallel programming is starting to catch on as mainstream rather than something to be shunned or avoided; whereas in the past folks were conditioned to avoid having to deal with threading or forking because of having to think about thread safety, there are now languages like Erlang (and its kids Elixir and LFE), Rust, Go, Scala, Julia, etc. that are meant to make parallel computing easier to reason about or less dangerous (or sometimes even both).
On top of this, though, Erlang-and-kids' reliability features allow them to achieve the legendary "nine-nines" of uptime (99.9999999%) relatively easily (I say "relatively" because - while you certainly still have to think about it (particularly if you're trying to push a change to, say, how data is represented on the (D)ETS or Mnesia or CouchDB or SQL or whatever side of things) - it's much easier than with a lot of other languages). That level of availability has huge implications for a company's bottom line, particularly those companies that measure downtime in "thousands of dollars per second" instead of just seconds. A well-written Erlang/OTP (or Elixir/OTP or LFE/OTP or anything/OTP) application can do this on the software side rather effectively (on the hardware side, you'd still want redundancy wherever possible/feasible, including on the network side of things; most well-run hospitals, for example, will have connections with at least two different ISPs so that if one goes out, they still have the other, and will only lose connectivity in very extreme circumstances).
In the case of Elixir, it makes for a very solid migration target from, say, a Rails codebase; the syntax is a bit more modern (I personally prefer Erlang's in many cases, but Elixir's pipe operator is a godsend) and familiar to Rubyists ("do" blocks, more flexible pipelining with the |> operator, etc.), while being fully compatible with the existing Erlang and growing Elixir ecosystems.
Don't get me wrong, it would be great if all Ruby developers switched to Erlang/Elixir, but what next? I mean, does switching a language more often than once a decade result in net benefit to the industry or net loss? I fear it's the latter.
Most of these switches are driven by a shift to some new programming paradigm. We started with procedural programming, then made a big shift to object-oriented programming, and now we're starting to see a big shift toward functional/declarative programming. Who knows what'll be big next?
If this happens too frequently, then there are certainly going to be problems, yes. The current trend, however, indicates that it's not happening too frequently, at least not yet; the current shift from object-oriented imperative to functional/declarative programming (with some object orientation here and there, though this isn't very pronounced in Erlang and its family tree) seems to be by necessity rather than adopting shiny for the sake of shiny, and I think that's what makes the difference here.
Basically, the more dramatic the switch is, the more likely the switch to be a net gain rather than a net loss, since it indicates that the switch was truly necessary. Switching from Python to Ruby, for example, would be a net loss, since - while they have different syntax and in some cases different programming styles and ecosystems - they're both imperative scripting languages and you're not really changing all that much besides a bit of syntax and semantics. Meanwhile, a switch from Python to Haskell, for another example, is more likely to be a net gain, since you wouldn't even consider that switch unless you felt the need for the massive paradigm shift that's required to make such a switch.
As a disclaimer, my claims above are mostly conjecture, though I think they correspond well with reality, at least by my own observations.
> Most of these switches are driven by a shift to some new programming paradigm.
Most of the switches should be driven by one thing, and one thing only: reducing the cost of software development (or increasing the quality, which is really the other side of the same coin). Whether a new programming paradigm actually achieves that or merely advertises itself as achieving that is the cause for the very high churn in fashion-driven SV and low churn elsewhere (where people are actually interested in cost reduction only).
> the current shift from object-oriented imperative to functional/declarative programming
As someone familiar with the software industry, I can tell you that there is no such shift happening other than in the minds of some wishful-thinkers. Are functional concepts being adopted by OO languages? Sure! (although Gilad Bracha would tell you, correctly, that most of these concepts were already in some OO languages -- i.e. Smalltalk -- long before people in the industry started using the term FP). But people aren't really switching languages outside those sectors that have made switching languages every few years a lifestyle choice.
> Basically, the more dramatic the switch is, the more likely the switch to be a net gain rather than a net loss,
I completely agree with that.
> since it indicates that the switch was truly necessary.
But not with this. Dramatic changes do have the potential to make a dramatic impact, but 1/ they rarely do, and 2/ when they do, it's mostly in the runtime -- not the language. Erlang is certainly an excellent runtime that has a big impact (though personally, I prefer the JVM, which can do anything BEAM does only better), but Haskell? Haskell is a very, very unproven language. I remember that about 15 years ago everyone was talking about it, saying how it's going to be the next big thing. 20 years into its existence, though, the largest single Haskell program is still its own compiler, which is not particularly large. The truth is that nobody really knows Haskell's actual benefits (in terms of real impact to project development) because in twenty years no one has tried to actually use the language for anything big (and small projects are usually cost-effective in any language). Its impact could be great but it may well be negative. Nobody knows. So if anyone tells me they've switched to Haskell out of necessity, I call BS.
But switching to BEAM is always a good idea (sooner or later) for large projects (unless you're already on the JVM), although if you're making the switch, I'd advise on the JVM, as it's a safer bet (both in terms of future, as well as likeliness of addressing the needs you may actually face; BEAM is a slow runtime, and many Erlang shops rely on C for important parts of their code).
> though personally, I prefer the JVM, which can do anything BEAM does only better
In my experience, this couldn't be farther from the truth. Java's threading model is bloated and slow compared to Erlang's process model, and that process model - the ability to spin up processes so lightweight that they make even Java threads look heavy in comparison - is the key to its success when it comes to parallel and distributed computing.
Now, this isn't to say that a JVM implementation can't do the things BEAM can (otherwise, projects like Erjang wouldn't exist), but I've found Erlang applications with BEAM to perform far better in that domain. This isn't particularly surprising, seeing as BEAM was designed to run declarative, distributed, concurrent languages (like Erlang and eventually Elixir and LFE and the like) right from the start, whereas the JVM, .NET CLR, etc. were originally designed for imperative languages (like Java and C#, respectively) and have been gradually adapted for fuctional/declarative programming (like with Scala or F#, respectively).
> no one has tried to actually use [Haskell] for anything big
Maybe because the equivalent Haskell codebase to a "big" project in most non-declarative languages ends up being "small" in comparison? Or are you talking about importance?
> the ability to spin up processes so lightweight that they make even Java threads look heavy in comparison - is the key to its success when it comes to parallel and distributed computing.
Except you can do the same in Java -- see Quasar or Erjang -- the JVM is so powerful that true lightweight threads -- just like Erlangs -- can be added as a library.
> I've found Erlang applications with BEAM to perform far better in that domain.
I've found the exact opposite. Java with Quasar fibers handily beat Erlang code. The more actual work being done, the bigger the difference (BEAM is excellent at scheduling, but pretty terrible at running user code; it's notoriously slow, which is why all important Erlang library functions are implemented in C, and why heavyweight Erlang shops do a lot of C coding; when you do Erlang, it's often Erlang and C if performance is important).
> whereas the JVM, .NET CLR, etc. were originally designed for imperative languages
So was your machine, yet BEAM runs on it just fine. You can like the imperative style or not, but it's more general than the functional one when it comes to implementations on real hardware. BEAM runs on an imperative, shared-state machine, and creates a nice abstraction. You can do the same on the JVM without loss of generality, and, as it turns out, with a nice boost to performance (because HotSpot's JIT and GCs are state-of-the-art). The only advantage BEAM has over the JVM (or at least HotSpot) is a better level of isolation between processes (i.e. it's a bit harder for one process to impact the performance of another, because they have sort-of separate heaps). But again, BEAM is a fine, beautiful runtime that is perfectly suitable if you need good concurrency but aren't worried about processing speed.
> Maybe because the equivalent Haskell codebase to a "big" project in most non-declarative languages ends up being "small" in comparison? Or are you talking about importance?
Well, both. Haskell has never been used to write a large ERP, airport management system, manufacturing automation, an air-traffic control system, device drivers, an OS, a database, a banking system or a large social network -- take your pick. It may have been used to a small extent for some specific projects in banking, but that's about it. The only large, complex, "interesting" from a cost estimation perspective ever written in Erlang is its own compiler (and possibly other compilers). Now, I may have missed one or two specific projects, but their rarity only demonstrates the problem. Go, a much younger languages, is already more battle-tested than Haskell and even Go is far from being truly battle tested, so this says a lot.
> (BEAM is excellent at scheduling, but pretty terrible at running user code; it's notoriously slow, which is why all important Erlang library functions are implemented in C, and why heavyweight Erlang shops do a lot of C coding; when you do Erlang, it's often Erlang and C if performance is important).
That's really useful to know - I'd not heard about this before, only that Erlang was fast!
> Not about Elixir specifically, but don't people get tired of switching languages?
Are you a developer because you don't want to keep learning? Maybe you walked into the wrong room? ;)
> What, people will now have to port all Ruby libraries to Elixir (or, at the very least, relearn them), and then a few years down the line to the next thing? Isn't this a huge waste of effort?
In this case, Elixir actually has a selling point, as Erlang has existed for over 20 years and has its own fairly mature box of tools (which are all easily accessed from Elixir).
From a bigger picture, a lot of code construction of late has moved to a SOA paradigm, in which case you can still call into perfectly-working Ruby codebases, except as a client from another language.
> Are you a developer because you don't want to keep learning? Maybe you walked into the wrong room? ;)
Don't you rather be learning new concepts rather than new syntax/APIs? Not that Elixir doesn't bring new concepts to Ruby developers (it does), but even so, I think switching a language for production code has a terrible cost/benefit ratio compared to learning a new algorithm or even a new approach without switching a language.
Since when has "learning" in CS meant adopting a new language?
If we would all just have used Lisp from the get-go, then none of this would have even been necessary. ;)
> Don't you rather be learning new concepts rather than new syntax/APIs?
I ran out of new things to learn in Ruby, around the time I wrote a fizzbuzz implementation using pure functionals without any conditionals. And the mutability issue was bothering me in a very real way (I spent a month, A MONTH, tracking down a dropped-session issue which ended up being a stray mutation of the gigantic ENV variable in the middleware stack... That class of bug would not exist in Elixir/Erlang). Elixir/Erlang provided very brand-new things to learn... pattern-matching instead of complicated nested logic, explicitly passing around state instead of holding it everywhere, macros, OTP, I mean pretty much everything underneath is different except for the syntax. ;)
You can't learn something like macros in Ruby, at all. If certain things aren't core language features, it's just difficult to learn them, period.
> I ran out of new things to learn in Ruby, around the time I wrote a fizzbuzz implementation using pure functionals without any conditionals.
I am not a Ruby developer, but if Ruby is Turing complete I can think of a great many things you can learn. Have you implemented a B-Tree? Edmonds-Karp? Linear programming algorithms? Dynamic programming?
Why are you limiting your learning to different styles of implementing a trivial algorithm? That's pretty much the same as learning new languages, and programming language concepts occupy a tiny, tiny bit of computer science (like, 4% tops).
The programming language or the style you're using -- imperative, pure-functional, whatever -- is just something to express an algorithm. To me, what you said sounds like: "I've learned all I could about writing with pens -- I've tried all the colors to write 'the quick brown fox'-- so now I must switch to pencils".
I have some bad news for you (and for Edsger W. Dijkstra, who you would probably be a fan of)- In the "real world" of programming work, you will likely rarely encounter most of those things. Real-world dev is NOT about "computer science proper". (Unless you're building a language from scratch. Which is like 0.01% of all programming work.) You should of course be aware of them and what they do, and when you think you need them you should Google them and learn them then (and of course be able to do so).
Sometimes you need to switch languages- Perhaps you want the "look and feel" of pencil art which you can't do with pen-driven art without A LOT of work.
You can implement immutable data structures in Ruby- for example, see the Hamster gem here https://github.com/hamstergem/hamster - but 1) it is much, much slower, 2) none of the other gem code you will call into will use Hamster 3) you actually have to code differently to Hamster data structures than to the built-in Ruby ones.
Just because you CAN make pencil-art with pens, doesn't mean that's the "happy path."
And just because you can represent every possible computer operation as a series of lambda functions (see "Programming With Nothing" here, great article: http://codon.com/programming-with-nothing) doesn't mean you should.
I've been developing software for about twenty years now (as well as overseeing teams of developers), and at one point or another I needed each of the things I mentioned. I have never, however, been required to implement any of them using a functional style (or any other specific style for that matter). And if you like learning languages, that's great (I do too, from time to time), but I find algorithms to be so much more useful (yeah, in the real world). Like I said, I have never written more than a few lines of Ruby code, so I can't comment on the merits of that particular language, but if you find that you have to switch your main programming language more than twice a decade (even twice is probably too much) you're either spending time on the wrong thing, or picking the wrong languages to begin with. Languages that provide significant advantages over existing ones (that justify the very high switching costs) don't get invented more than once a decade. So, if you have to switch, think hard whether your new choice is one of those few that are likely to age well.
One is that, without much fail, I seem to be able to pick the winners of the next horse race in technology. I don't know if it's some kind of sensation of some kind of powerful embryological energy of tech ideas or what, but I sometimes see that things might go in a certain way, and I am usually correct. :) (Ruby I spotted REALLY early. When Rails came out I knew it was gonna happen. Apple did have me worried for a while before the iOS devices, but pulled through.) It's definitely a certain intangible energy, I can say that. Perhaps not unsurprisingly, I am involved with startups (and now despise working at large companies), and am semi-successful there.
I think that there's a type of developer who is an "introducer" of new ideas/concepts/products/things and I might be one. I know I enjoy mentoring, too, and I'm told I'm good at it.
If I had to write a new garbage-collection algorithm, I would probably suck at that.
So there's basically room for everyone, the algorithmists, the language hipsters, and everyone else. ;)
Everyone nontechnical who knows me thinks I'm "The Machine Whisperer." When I'm around, things "just work", and I can fix most things pretty quickly. One of my earliest memories is taking things apart to see how they worked... I was fascinated by electric motors... Magician in training. ;) I remember diagramming a regenerative braking system in AP Physics class out of boredom (the school's physics lab ended up getting named after me, for being the first person in the history of the school to get both a 5 on the AP test and 100 on the Regents). Now I drive a Tesla. ;)
But first, I had to flunk engineering calculus in college to realize I wasn't bound to be a physicist. THAT was a reality check.
I remember walking past that physics lab when I was only in 8th grade or so, and getting a weird feeling... Same as when I tried the first Macintosh, the first iPhone, and wrote my first Ruby code... when I dialed out with a modem for the first time, before the Internet... and when I tried NCSA Mosaic.
Anyway, I still get that weird feeling now sometimes. Elixir did it. ;)
> So there's basically room for everyone, the algorithmists, the language hipsters, and everyone else. ;)
Oh, absolutely. But I'd keep language hipsters away from important software (although any language built on a solid foundation like BEAM or the JVM is a much safer bet than one that isn't). :)
> I seem to be able to pick the winners of the next horse race in technology... Ruby
Wait, you consider Ruby a winning horse? I hear it's a fun language -- probably a great one -- but it's already beginning to fade after hardly having left a mark on anything but web apps (a very small portion of the software industry, and the least technological). If we coldly consider results I think it hardly qualifies as more than a relatively extended fad. It's not even nearly as popular as Delphi was in its heyday, let alone top-ten languages like Java, C, C++, C#, PHP, VB and JavaScript. In fact, I think that of all languages that could be considered Ruby competitors, Ruby has done the worst (it never threatened PHP's dominance in its field and was easily overtaken by Python -- which has been used in many more domains).
Fads are often self-fulfilling prophecies, often gaining brief popularity on sheer novelty alone; but important codebases last for decades. And don't mistake the tiny Silicon Valley software startup scene for a representative of the software industry. Most software developers in the world have never even heard of HN.
> Wait, you consider Ruby a winning horse? I hear it's a fun language -- probably a great one -- but it's already beginning to fade [...] it never threatened PHP's dominance
If a winning horse is one that earns the rider more money (while also being more fun to ride!), then for me and all the Ruby devs I know, Ruby is a winning horse compared to PHP.
> important codebases last for decades.
Yes, and the author did well to avoid naming their article "Elixir - The next big language for important codebases that will last for decades". :-)
You are correct. In me learning Elixir I have taken the patterns and write very different Javascript, php, and C# because of it. Every language I learn I learn new approaches to coding in all the languages I already know.
I think the issue is that many CTO's don't take all of these factors into account when they do decide to switch to or add a new language to the companies codebase. It seems many are shortsighted and simply see A > B without evaluating all of the costs of switching from B to A.
I remember hearing the "genesis story" of Elixir. IIRC, José was working on ensuring Rails was thread safe. He did so, but was dismayed with the difficulty and felt like he was fighting Ruby. So he stepped back, and thought that if concurrency is the future, he should find a better language for it. He looked into immutable, functional languages (Haskell, Clojure, Erlang), and realized that Erlang is built for an arguably harder problem: distributed computing, and made the connection that concurrency is sort of a smaller case of that. He worked with Erlang for awhile before deciding that it could be improved by building on it.
Going through the Elixir tutorial and seeing how you could "simulate" state, by spinning up an infinite loop in another process and sending messages to it was mind bending. And learning about Erlang's OTP principles has made me really think about robustness differently. I really do hope Elixir/Phoenix become the next big language and web framework.