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