Elixir is truly an under-appreciated language. I've only toyed with it, and I'm really impressed with the whole ecosystem. Elixir, Phoenix, Ecto, Hex, etc all make a great ecosystem, and the awesomeness that is BEAM/OTP is just amazing. I loved the hot code deploys, and updating a system while it's running is something I've never seen before in action. Also Rustler is a great way to write CPU intensive NIF code too.
I built a side-project powered by Elixir & Phoenix 1.2, I found it so surprisingly quick and easy to accomplish even complex functionality. Every time I implemented a new feature server-side it honestly felt like "Is that it? Really?"
Same experience here. I have a process that I generally go through to compare languages...I rebuild my blog. It's an exercise that I've done many times and it gives me a time-boxed experience that compares work flow, database interaction, web requests, dealing with CSS/JS/assets, potentially caching, routes, email, search, etc.
It's not a perfect measure but it does a solid job of giving me the whole experience of working with a language on something similar to day to day and separates the "this is viable as a tool" from "OMG! BENCHMARK!" type experiences.
Doing this with Elixir and Phoenix was mind blowing. It was so clean, efficient to work with, efficient in performance and the design decisions around the language almost ensure you'll avoid entire classes of debugging / maintenance issues in the future. I was blown away.
I believe the popular quote with Erlang is that Erlang makes hard things easy & easy things hard. Elixir was built around the idea of keeping the easy things easy. It does so by improving syntax, tooling, documentation & community in my opinion.
I believe I first read this idea in the book, Elixir in Action.
+1 for rustler. Writing NIFs (native implemented functions) in Rust can speed up your Elixir apps significantly. I think Rust & Elixir are a great duo.
I am super-stoked about the potential of Rust and Elixir, but there are some definite gotchas to be aware of. Especially if your Rust code is pretty expensive. Sonny Scroggin's talk about Rustler is really informative. https://www.youtube.com/watch?v=lSLTwWqTbKQ
Yes, I have. I would say it's pretty easy. Had it not been for rustler I wouldn't have touched NIFs since I'm not a C programmer. Also, rustler supplies elegant building blocks, which makes it a straightforward experience.
I've had a few issues with the version of rustler published on hex.pm not working with Erlang/OTP 20, and I've tried using the master repo as a dependency in my `mix.exs`, but that didn't work since rustler repo has an unusual directory structure which fails to compile. And then lo and behold, I've discovered how amazing the `mix` tool is and via `mix help deps` I've learned that you can actually check out a specific directory (via `sparse` option) from a remote repo as your dependency.
Now my dependency listed in `mix.exs` looks like this:
I wonder how the popularity trend of Elixir has been lately. I know you can try to see it through GitHub or Google Trends, but as many members of the Elixir community use Slack I don't know if it's the best way to do it. One thing I'd like to see would be the evolution of downloads of the language and on Hex.
It tough now since the web space is very competitive.
Before that it's just PHP (well it displaced Perl) and then RoR pop out to give it a real competition. For a while you'd think Ruby was going to over take PHP for web dev but it eventually converge to a steady state the growth rate isn't increasing at all. If you look at tiobe index and red monk's for language popularity Ruby have either stayed teh same and move down a few spot. Javascript just sky rocketed after nodejs (this is relative I remember the first year or so where it was slow in term of growth, hype, and adoption).
There are so many web dev pie out there for each language to take a chunk. After RoR was nodejs, this is on top of the other smaller player groovy, python django, java stuff, etc.. a least major players within the startups that I've experiences.
I believe Elixir and Erlang is a very great language for web dev. Unfortunately it comes into a time where the market is very competitive with many alternative out there staking a claim for this field.
At this point the web industry is really really hype imo. And people eat this up like candy.
I can say for sure Elixir is a better concurrency model and better language than NodeJS will ever be for web development. And the hype if there is any is real for Elixir.
> For a while you'd think Ruby was going to over take PHP for web dev but it eventually converge to a steady state the growth rate isn't increasing at all.
Rails downloads almost doubled from 2015 to 2016 (15M -> 24M). Not sure where you see that the "growth rate isn't increasing at all".
I've always thought that this is a consequence of tools like Docker, where each new image installs the gems from the beginning; but I could not prove my theory.
Indeed.com trends[1] show Elixir interest (though not yet jobs) surpassing both Haskell and Clojure right about now, which I found surprising especially given how much newer it is
It's got HN hype and a lot of the negatives that come with that (awful learning materials by people who haven't used it in production) and a decent amount of real world use though nothing major for now.
This seems to be the dominant use case for Elixir; migrate legacy Rails code to Elixir. When deciding between Go and Elixir for our startup I looked at both ecosystems. Go was significantly ahead in all categories: traction, articles on the web, packages on git, git activity, editor support ... I don't regret choosing Go but I always keep an eye out on Elixir. Pattern matching, pipe operator, immutability, supervisors ... I can only dream about that in Go.
I LOVE the pattern-matching/deconstruction/guards stuff. It eliminates SO much boilerplate logic. Just the function head of an Elixir function eliminates a dozen input validation and assignment lines in most other languages. It wouldn't be nearly as spectacular if it didn't pervade the entire language, though (for example, I'm sure you could get partway there in many other languages using a DSL)
Same thing with immutability. If it doesn't pervade the entire language, it feels slapped-on, and you basically lose most (all?) of the guarantees (like removing an entire class of bugs caused by mutability).
I saw what you saw in Go, but in doing my homework, I also saw an astonishing amount of ugliness[1][2][3], and additionally I took a bit of actual offense to the core philosophy of Go's design as stated by Rob Pike himself[4][5] so I am betting on (hoping for?) spectacular Elixir adoption I guess lol, as my current and all future projects for the foreseeable future will be in Elixir.
About the only wart I've seen so far in Elixir is the pin operator[6], but that was necessary to preserve the name-rebinding ability in a pattern-matching context, and it stops seeming like a wart fairly quickly, once you realize why it's necessary.
>About the only wart I've seen so far in Elixir is the pin operator[6], but that was necessary to preserve the name-rebinding ability in a pattern-matching context, and it stops seeming like a wart fairly quickly, once you realize why it's necessary.
I'm interested in hearing more on this, because I find elixir's pattern matching phenomenal. Fully embracing it feels like such a paradigm shift, and along with the rest of elixir it feels like I'm learning programming all over again (and I've been doing this for over a decade). I love it.
Back to the pin operator - the syntax is very light, and it's conceptually simple. As you said it's a natural consequence of pattern-matching. I'm not trying to start bikeshedding here, just wondering if there are some other problems or perspectives with the pin operator I'm not aware of. Thanks.
> I LOVE the pattern-matching/deconstruction/guards stuff. It eliminates SO much boilerplate logic.
I recently ported some simple plaintext operational transform code to Go and Swift to compare the languages, and this is so true. A lack of parameterised enums and a decent match block resulted in the Go code being about 50% larger than the swift equivalent. And the extra size bought me nothing! I find the Go code to be less readable and it had more bugs out of the gate.
Its a shame too, because I adore Go's concurrency features and APIs. Server side swift seems barbaric, and I lust over Go's scheduler and networking APIs.
Maybe its time to give Elixir a try. It sounds like it might be at a nice sweet spot of modern language features, concurrency and a mature ecosystem.
(NB: I'm new at both languages. A more experienced Go programmer might write that code differently. I don't find myself wondering that with Swift because its much more idiomatic.)
Go doesn't quite have the right level of abstraction for building CRUD apps. In particular, working with relational databases is very manual. Even using things like sqlx.
For an improvement of 2 orders of magnitude while maintaining the same level of developer complexity, I'm hard pressed to think of any other web framework besides Phoenix that can deliver this.
Java and C# easily outclass Phoenix i performances, if only because they are statically typed, but also because they run on VM's that are more advanced (and admittedly older, so more optimized) than BEAM.
Java and C# outclass performance in raw CPU work certainly. Phoenix does not do raw CPU work however, it is primarily a web dispatcher on top of cowboy and the BEAM will run circles around both Java and C# systems if they are programmed to anywhere near the same quality of failure handling that the BEAM implicitly supplies (/me has worked with both Java and the BEAM for over 10 years).
Also, the Erlang VM is older than the JVM, initially created in the late 1980's. The JVM, according to wikipedia, was introduced in 1994. Also the BEAM has significantly better GC handling that both the JVM and .NET both since it has a segmented memory model (each actor has segmented memory) unlike the JVM and .NET's monolithic Heap's, this allows it to perform vast optimizations that ensure that the GC is almost never called yet memory is properly and fully reclaimed due to the bounds of the individual Actor heaps, and even when the GC is called it does not stop-the-world or anything of the sort and has multiple layers of GC's that run for specific cases, the system stays running even as the GC's (rarely) runs. The average GC run time even when it does run is measured in the single-digit 'micro'seconds. If anything the BEAM VM is not only just much older than the JVM and .NET VM's, but also more advanced.
Java and C# incur more much more developer complexity for web development than Phoenix.
And as the the sibling comment points out, raw CPU performance isn't the only measure of efficiency. The JVM loves to eat memory, and if you get 100x CPU efficiency but use 10x the RAM, you're still bounded on machine resource usage by that memory usage.
Isn't that just a timing issue? Why chalk it up to HN immediately when it's more likely to be the general interest in the language increasing and more people using it for less time are writing about it? This is a good thing as these people will probably lead the future for its use.
It's just the name I give to languages or tools that get big online and generate a lot blog posts and shoddy learning material. Though most of the time it does start with HN.
BTW I love Elixir and I'm happy to see it grow. Nothing bad about HN hype it just has its positives and negatives.
I think is not that popular yet. Look at this issue for the sublime elixir plugin [1], it's breaks a lot of things and seems stalled for a long time...
Updating a system while running is something that has been around in the Lisp world for a while through the REPL. More recently it's a big part of the Clojure world -- I will usually NREPL into a running production system and "poke" around when there is a critical BUG that is only happening on production.
I'll take a crack at this. Elixir lays a really nice syntax, set of tools, and community over top of Erlang/OTP which are already amazing. While the language is new and increasingly popular, it is arguably not widely/well appreciated how nice and solid the language/ecosystem is at this point in its lifecycle.
