5 ms·
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
by d3ckard 10y ago
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.
- holydude 10y agoThe 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
- izelnakri 10y ago4th one depends on the implementation, and it isn't a disadvantage since most scripting languages have the same characteristic.
- pdexter 10y agoHow many implementations are there?
- izelnakri 10y agoI can give you 3 already: 1- doing it with SQL, 2- Distributed way with processes, 3- Doing it with custom NIFs etc.
- gamache 10y agoSpeaking 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).
- hderms 10y agoWhy did you leave Akka for elixir?
- gamache 10y agoThere 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.
- hderms 10y agoFair 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.
- crusso 10y agoThe 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.
- hackerboos 10y agoAlso not many jobs. I've been looking for an Elixir job in Canada for months.
- d3ckard 10y agoIMHO 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.
- sotojuan 10y agoThis isn't going to change for years. If you want an Elixir job, go freelance.
- d3ckard 10y ago1) 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.
- kitsune_ 10y agoJudging 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.
- hackerboos 10y agoElixir 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.
- kitsune_ 10y agoIf 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.
- macintux 10y agoOh, 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.
- danmaz74 10y agoNo 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 :)
- amalag 10y ago
- aaron-lebo 10y agoIt'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.
- d3ckard 10y agoThis 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.
- twoquestions 10y agoBad 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.
- andy_ppp 10y agoIn 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.
- iamatworknow 10y agoYou 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.
- ibgib 10y agoUnlike 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 ```
- ibgib 10y ago> 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.
- andy_ppp 10y agoI'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.
- sotojuan 10y ago> 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.