Agreed, it's just an absolute pleasure to use.

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.

Wrote about it here: http://www.brightball.com/articles/insanity-with-elixir-phoe...

Keep in mind, there are a number of things that I did there that could have been done better/cleaner. It was my first experience with the language.

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.

Personally, I'm a fan of the Perl philosophy: make the easy things easy and the hard things possible.

I've heard this said about NixOS: It makes the easy things hard and the impossible things hard. :)

+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

Have you written any Rust NIFs? What's the dev experience like?

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:

    {:rustler, ">= 0.0.0", git: "https://github.com/hansihe/rustler.git",
                            tag: "0.15.1", sparse: "rustler_mix"}

... and problem solved. I guess peeking at rustler's tests helped me a lot.

All in all, the entire Elixir ecosystem is really elegant. Such a joy to write code now!

Oh cool, that's a great mix find.

With the Rustler Rust library, almost blissfully easy. I highly recommend it.

I'll have to hit you up for advice on the forum when I try it out.

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.

Gotta get more people to make noises really.

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".

Source: RubyGems db data dump (more stats here: https://infinum.co/the-capsized-eight/analyzing-rubygems-sta...)

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

[1] https://www.indeed.com/jobtrends/q-Erlang-q-Elixir-q-Haskell... (scroll down to 2nd chart)

on StackOveflow there are more Elixir jobs than Erlang but not Clojure

http://www.reallyhyped.com/?keywords=elixir%2Cerlang%2Ccloju...

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.

Also, Bleacher Report is a pretty large site on it:

http://www.techworld.com/apps-wearables/how-elixir-helped-bl...

They went from 150 Rails servers to 5 BEAM servers "and could probably get away with two" (!)

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.

[1] https://anvaka.github.io/common-words/#?lang=go makes it seem like 50% of the day-to-day code in the language is error-checking due to the lack of exceptions

[2] https://github.com/ksimka/go-is-not-good

[3] http://byrd.im/go-is-poor/

[4] http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

[5] I'm actually a fan of Plan9 and appreciate Rob Pike's work on that

[6] https://stackoverflow.com/questions/27971357/what-is-the-pin...

>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 haven't really seen any. You can't use the pin operator in argument lists to functions... that's the other "gotcha".

> 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.

IDE screenshots:

https://twitter.com/josephgentle/status/876639761166770176

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.

To be fair, if you're running Rails, any different choice of technology will yield huge performance improvements.

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.

Minor correction, BEAM is just as old if not a couple years older than JVM.

https://en.wikipedia.org/wiki/Erlang_(programming_language) https://en.wikipedia.org/wiki/Java_virtual_machine

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.

I believe Discord uses Elixir, and I think that counts as "major."

Yes, and they wrote some interesting blog posts about it:

https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b

https://blog.discordapp.com/how-discord-handles-push-request...

It is also used by Pinterest and Square Enix, as they both open sourced some of the tools they use.

Love Discord

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.

bet365 is major.

Some Hex download details https://elixirforum.com/t/the-buzz-and-activity-around-elixi...

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...

[1] https://github.com/vishnevskiy/ElixirSublime/issues/8

I don't know of many Elixir devs who use sublime for their development. IntelliJ, Vim, Emacs, Atom etc..

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.

How is it "under-appreciated"? I feel like for such a young language it already has a great popularity.

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.

Ecosystems grow a lot faster these days because there's tons of prior art.

I can feel that this feeling comes from perceiving hard-core FP perspective. I could be wrong :)

What percent of new code around the world is being written in it? .25% maybe? That seems not that appreciated to me.

I have very much the same feelings, I've only really been using it the last few weeks but it's been an absolute pleasure to work with.

Massive thanks to the devs who work on it.