Hacker News Reader

Comment by d3ckard | Hacker News Reader

Funny thing is that I have yet to see the other side of argument - when people had a bad experience with Elixir. It seems so nicely fit into its problem domain that basically everybody that starts doing it is happy with results. I guess that says something.

View on HN

Judging from past experiences here on HN and other programming echo chambers, I'd wager that Elixir is currently at the beginning of its hype cycle (somewhere between 'technology trigger' and 'peak of inflated expectations' if you go by Gartner). So I'm almost certain that you will eventually see "Why Elixir was bad for us..." posts upvoted on here or in other places.

Elixir hasn't gone through the usual hype phases because it's just syntactical sugar, less boilerplate and more modern than Erlang making it more palatable for Ruby/Python devs.

The BEAM VM is what makes all this possible and the BEAM VM has been around for decades.

If you search for Elixir on HN and sort by popularity, 10 of the top 20 results were submitted during the past 12 months (Which in itself might be just related to an increase in users here on HN, but compare the results to languages like Java or Haskell).

Many of my dev friends with hipsterish inclinations jumped on the Elixir hype train in the past year or so. I really don't see how this is different than past "hype phases" of other technologies.

Oh, sure, there'll be some people who regret it, but the key difference is that it isn't going to run into some of the same problems that plague other new languages because it fundamentally isn't a new language.

No matter how good Elixir is, at some point the hype will reach a point where many people will try it having wild expectations, and will get disappointed. This is just the way hype works :)

It was interesting reading some opinions from older Erlang folks. They are mostly supportive but disliked a few things about Elixir such as reassigning variables which they thought broke immutability.

I think if you replace Elixir with Erlang, the beginning of the hype cycle argument goes away since now we are talking about rock solid software backend that is decades old (from the 1980s) and powering a large chunk of the telephone switches in the world.

If I am not mistaken Elixir is primarily a front end that generates code for the Erlang VM (BEAM) supported by the Erlang OTP backend.

Having said that the questions remains, why doesn't Erlang get the same hype? I am hazarding a guess that a majority of developers still work in the imperative style and switching to the functional side takes a bit of relearning in the way you think.

Elixir has a much more "standard" syntax so its naturally gonna have a lower barrier to entry.

It's not really the syntax. Elixir's semantics are simply better than Erlang.

Erlang accumulated a lot of worts, but it never really got rid of them.

I don't think Syntax matters all that much. Smalltalk's syntax is pretty odd, but its regular and simple to explain/understand, so people quickly come to like it. Smalltalk's VM's though are a huge barrier to entry.

Erlang is the reverse: great VM... great architectural decisions... great libraries.... questionable language semantics.

I don't understand this argument. Elixir is still its own distinct thing, the fact that it compiles to BEAM byte code is secondary in assessing whether it is currently in a hype cycle or not. Just like Clojure, Eta, Scala, jErlang or the myriad of other languages that run on top of the JVM can be hyped independently of the JVM or Java.

Erlang did get the same amount of hype, probably multiple times in the past 20 years. So did many, if not most reasonably well-known languages, programming paradigms, architectural solutions, databases, frameworks and so on.

I do not make any judgement about the merits or maturity of Elixir itself. Elixir is perfectly fine.

As developers we should have a healthy dose of skepticism when it comes to blog posts that claim 10x speed improvements with technology X. Was it just the rewrite? Does your use case match mine? And so on... In short: Everything is a trade off, and there is no silver-bullet.

It's early in the adoption cycle.

Not that Elixir is bad, but if you are writing something in it today you are ahead of the curve. As soon as there are a lot of mediocre developers (if we get there) that start using Elixir because they heard it can do no wrong, you'll hear complaints.

This is undoubtedly true. One thing to note though is that I believe that Elixir/Erlang model of programming just fits well with the demands of web applications. There is a lot of cognitive load you're relieved from just because the used abstractions actually seem well suited for the task.

Bad side: you have to do everything yourself.

Ruby on Rails, ASP.Net, Django, they all have a million and one StackOverflow answers, blog posts, and books written about them. I found out the hard way that Elixir and Phoenix docs aren't as prolific. That and the names are less Googleable.

Some people may like that challenge, but it does add a level of difficulty.

In my experience reading the Phoenix source code is much simpler than Django or Rails so less need for stack overflow or help. There is much less to go wrong as well.

You do realize your experience isn't typical, right? Most developers aren't going to look through the source code for the framework they use to answer a question about usage. They're going to google it.

Unlike with past languages, I've also found myself looking at the source code with Elixir, but it's because docs are first-class citizens. I think this is atypical of languages in general, and it's actually why the source code comes up when googling for the info. The answers are in the code in the form of:

``` @doc This is some useful, markdown documentation, which actually contains usage info.

  ## Usage
    
  ## Examples

```

> I found out the hard way that Elixir and Phoenix docs aren't as prolific

Odd, because I have found the opposite to be true about the docs. I've found the docs proper to be quite prolific, well maintained and well-written with examples. This stems from docs being first-class citizens of the language, a dead-simple docs generation tool, and their dogged commitment on excellent documentation (which is why docs are first-class citizens to begin with).

> That and the names are less Googleable.

That said, the _SO/Google_ aspect (not docs) is _significantly_ less prolific - I totally agree with that. But I've found where with other languages I often find myself on SO (C# and JS mainly), I haven't even needed it because the docs are just so well maintained (and versioned). This, plus their community is _extremely_ active, on the elixir forum and github (also slack, but I use that less).

So now, when I google for elixir info, I'm basically googling to get to the official documentation quickly. If there is any question I have beyond that, I check the elixir forum, rarely (but sometimes) needing to post a new question. Perhaps I've just had a different experience wrt this.

You're right, I should take a look through the source more often.

I chalk it up to my C# dev background, where source code was either completely impenetrable, a Sacred Thing that nobody should feel privileged to look at, or both.

I'll have to give it another look sometime.

Yes, I also grew up with C# (after Delphi, which was basically C#'s unmanaged memory version, largely architected by mastermind Anders Hejlsberg). So looking at source just wasn't a thing. Now with Elixir, not only is it a thing, but they have a super active community and great source code/repository maintenance.

I've tried to get other people to get involved with Elixir but most people don't understand Functional Programming and haven't encountered the problems Rails/Ruby or say Python has.

I think people coming from OOP find FP hard and seem to struggle with things like Ecto and definitely Macros.

Once you have mutable state everywhere and problems with the GIL and throughput on routes being slowed down too much so you start moving everything into queues (celery or rabbit). Then you realise that all of this could have been avoided and made much much easier to test if it were all written in Elixir.

> I've tried to get other people to get involved with Elixir but most people don't understand Functional Programming

I really don't get this. Elixir is barely FP—just immutability and first class functions. Is it really that hard for a lot of people? It's not Haskell or Clojure (""weird"" syntax).

I'd argue the hard part of Elixir is OTP and taking advantage of distributed computing.

> haven't encountered the problems Rails/Ruby or say Python has.

This is a good reason, honestly. If Ruby is fine, why change? It'll just make learning a new paradigm and OTP less fun because there's no need to learn it.

The bad side

1) no support from mega corporations 2) not that many developers to choose from 3) while based on BEAM it's still too "new" 4) too slow for raw money crunching

4th one depends on the implementation, and it isn't a disadvantage since most scripting languages have the same characteristic.

How many implementations are there?

I can give you 3 already: 1- doing it with SQL, 2- Distributed way with processes, 3- Doing it with custom NIFs etc.

Speaking as someone who came to Elixir from Scala/Akka on the JVM, yes it is absolutely a disadvantage, and no there is no implementation of the Erlang VM which rivals the JVM for speed. In Erlang/Elixir you get speed through horizontal scalability (which is easy) and/or writing parts of your code in another, faster language (which is harder).

Why did you leave Akka for elixir?

There were a few reasons. I never loved Scala, and I especially didn't like the let's-write-Haskell-in-Scala obsession with static typing that affects half the community. The JVM and Akka both have a lot of knobs to tweak, whereas the BEAM seems to have saner defaults.

I didn't need rocket fast performance and I didn't need any JVM libraries, but I did like the actor model of concurrency and process supervision, so when it came time to look for greener pastures, Elixir was a solid choice. I've been using it in production just over a year, and it's been excellent.

Fair enough. I've dug into the haskell-as-scala stuff and found it academically interesting but somewhat divorced from reality with respect to how immediately useful it would be to most projects.

The reality is that raw money (number?) crunching is rarely the problem for modern sites. Even when it is, the number crunching code is often easily isolated and can be modularized using another more performant language and then Elixir can call that module as needed.

Also not many jobs. I've been looking for an Elixir job in Canada for months.

IMHO the best way to start working with Elixir is to persuade people in your current place to give it a try. In the age of microservices it should be doable and later on it creates the market. That's what I did anyway.

This isn't going to change for years. If you want an Elixir job, go freelance.

1) You can argue that it makes tech much less dependent on needs of one particular entity. It can be a good or bad thing, depending on your views. 2) This one I do not agree on principle. I wish we finally stopped judging devs by "language experience" and start judging them by "domain experience". For early stage startups it might be a disadvantage, all the rest should not be concerned about it. 3) Actually it's pretty stable. It's constantly being expanded (i.e. GenStage, but I've been working with it for year and a half now and never had issues with breaking changes. 4) True, but this is a niche. Number crunching is important in some domains, but what you need from web app is usually making things work in predicable way. Everything else is more of a specialized problem which needs custom solutions.

Reply on news.ycombinator.com