15 ms·

Would you still pick Elixir in 2019?

• xvilka 8y ago
  Very interesting language (and OTP platform), I wish I learned it earlier.
  • tscherno 8y ago
    Thanks for your work on Milestone/Droid ;)
    • xvilka 8y ago
      Haha, thank you!
• gpmcadam 8y ago
  Love Elixir. But every other word being emphasised in this article was tiring to read.
  • bicx 8y ago
    I agree. If you emphasize too much, it feels like you're trying too hard to convince me, kind of like news headlines IN ALL CAPS.
• andrenth 8y ago
  What an awkward introduction with the ideological pronouns.
  • deleted 8y ago
    [deleted]
  • rsynnott 8y ago
    You mean the use of singular they? Absolutely standard English, and nothing ideological about it.
    • andrenth 8y ago
      Only with an indeterminate subject. Definitely not the case here.
• StreamBright 8y ago
  Elixir just really nice. I gave it a shot again and it is super smooth experience nowadays. Distillery, mix, iex <3 Also most of the libraries I care about are 2.0+ and now this: https://github.com/aws-samples/aws-lambda-elixir-runtime https://github.com/aws-samples/aws-lambda-elixir-runtime The only downside is that the out of the box performance is subpar for http services but it is still acceptable.
  • _asummers 8y ago
    Cowboy measures its latency in microseconds, what bottlenecks are you running into specifically?
    • RobertKerans 8y ago
      I assume perf comment is in relation to AWS Lambda, for which the Elixir example they've put up is severely below par perf wise
      • StreamBright 8y ago
        I am talking about raw HTTP request handling performance. Elixir/Cowboy/Plug is in the middle range of web servers. Again, it is good enough for most use cases.
        • RobertKerans 8y ago
          Ah, fair enough, apologies for misconstruing. Definitely good enough for a very wide range of use cases; it's not a language built for speed and power anyway.
    • StreamBright 8y ago
      Not really, you can't have a microsecond latency talking over a network. I understand localhost microbenchmarks are nice but real life scenarios are much better. The setup for the test: - provision node A for being the server - provision node B for being the client - open X (16..16000) connections from node A and use http pipelining start to send requests to node B I use wrk2 as the test client it is pretty amazing and looking at the latency distribution graphs. Tools that clear winners of performance: - https://github.com/valyala/fasthttp https://github.com/valyala/fasthttp - https://www.rapidoid.org https://www.rapidoid.org Elixir/Cowboy/Plug is in the middle range, kind of like what Techempower[1] guys saw during their tests. [1] https://www.techempower.com/blog/2018/10/30/framework-benchmarks-round-17/ https://www.techempower.com/blog/2018/10/30/framework-benchm...
• cygned 8y ago
  Interesting perspective on the JavaScript ecosystem. I never had any debugging issues in particular, but the dependency hell drives me nuts, too.
• _asummers 8y ago
  Yep. Would bet on it again. It's proven itself to me and my employer, and has increased developer productivity and joy dramatically. Bad code looks bad, good design emerges organically, and macros let you hide the plumbing where needed, and optimize things away at compile time. Not even mentioning the wonderful world of OTP.
• nickjj 8y ago
  Sure. I am building a quite involved video learning platform as we speak with Elixir and Phoenix. No regrets so far, and if anything as time goes on, I'm becoming more and more happy with the decision. The community is really great and there's a lot of quality libraries available. Not just libraries, but entire production systems too. For example https://changelog.com/ https://changelog.com/ is written with Elixir / Phoenix and their platform is open source'd at https://github.com/thechangelog/changelog.com https://github.com/thechangelog/changelog.com. There's so much good stuff in that repo to learn from. Also the Elixir Slack channel has 20,000+ people in it and the official forums at https://elixirforum.com/ https://elixirforum.com/ are very active.
• ai_ia 8y ago
  I started read Programming Elixir and Programming Phoenix. Elixir is amazing.
• xena 8y ago
  I would like it a lot more if it wasn't forced on me by my coworkers.
• mooreds 8y ago
  If you are coming to elixir from a rails background, how does it compare? I looked a year or two ago and the number of packages was far smaller with elixir, which turned me off of it.
  • latch 8y ago
    I think Elixir is quick to learn, long to master. You start off building web apps in Phoenix, being relatively productive from the start, and thinking to yourself "well, there's definitely some magic I don't understand, but this feels a lot like Ruby." You'll immediately notice and learn the smaller differences (immutability and pattern matching). Then one day, you'll need to store and mutate data in process. And then you'll learn about GenServers and Supervisors. Then one day, you'll want to have some base functionality but for whatever reason, composition isn't a good fit, so you'll start to dig into macros. Fundamentally, Go is much more Ruby-like than Elixir (Ruby and Go have shared heap, global GC, array-based data structures, same evaluation strategy, mutability, ...). Elixir is very different. But it's discoverable.
  • pmontra 8y ago
    There is more or less everything now. My complaint was the lack of and authentication framework and Coherence filled the void. I have no trouble finding modules to solve problems without coding the solution from scratch.
• flixic 8y ago
  Yes. I prototype in Node, but then usually move all the important stuff to Elixir.
• mrspeaker 8y ago
  Could someone give a more concise reason for using Elixir? I have a "rule of 3" for checking out things - the third time I hear it mentioned and it seems interesting, then I'll go check it out. Elixir is past 3 times - so I will check it out for sure! - but this article didn't seem to actually say anything (seemed more like a PR piece that was trying not to be technical, and the main argument appeared to be "well, it's not javascript!"). The part that actually talked about Elixir listed some Pros that didn't seem that unique. What's the "killer feature" of Elixir - or is it just a combination of "good features"?
  • dlkinney 8y ago
    It is an ergonomic language built on top of a stable, performant, proven runtime with a lot of features built-in. It's a nice ecosystem with a good culture in a language that promotes pretty good programming practices. The only major downsides (if they even are for you) are that it's dynamic--not good for number crunching, though you can connect to compiled binaries--and is not strongly typed--which can lead to runtime bugs. That said, part of the philosophy is to enable fast failure without taking down the whole application. In communications, it's not considered the end of the world to drop or fail on one connection, so it works well for web services, chat, etc.
  • andy_ppp 8y ago
    I would say it's about developer happiness while coding and that all the decisions made by Jose and the core team tend to have been the correct decision. So taking Phoenix as an example you look at the framework and every time they find a problem i.e. Presence instead of saying that's a difficult problem and moving on they fix said problem in a really scalable way [1]. The same could be said for things like data processing with Flow [2] or even things like Ecto (semi official database wrapper) or even third party libraries like say ex_money [3]. Then you start looking at the packages and language and see that there are rarely thousands of bugs or that the infrastructure (mix, hex, docs etc.) is really nice to use and that the language is really stable, yet still provides you with useful but clear abstractions. Or that you can spin off processes and tasks inline without too much worry, or that you can use 20+ years of Erlang libs transparently, or that it's immutable and has the best concurrency primitives of any system available, or that it allow you to supervise processes and let them crash if needed without bringing down your app, or that you can transparently get multi machine out of the box, or that message passing is build in as the default way to scale the system. Or pattern matching or |> or the amazing community. [1] https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://phoenixframework.org/blog/the-road-to-2-million-webs... and https://dockyard.com/blog/2016/03/25/what-makes-phoenix-presence-special-sneak-peek https://dockyard.com/blog/2016/03/25/what-makes-phoenix-pres... [2] https://www.youtube.com/watch?v=XPlXNUXmcgE https://www.youtube.com/watch?v=XPlXNUXmcgE [3] https://github.com/kipcole9/money https://github.com/kipcole9/money
• symboltoproc 8y ago
  The JavaScript Fatigue argument is not good. There's simply no data that backs it and nobody is forced to use new libraries only because they use JavaScript. I've seen third party dependencies churn on Elixir as well (packages that are no longer maintained or alternatives that are better) - I think it's an inherent problem with using dependencies and has nothing to do with the programming language in which those dependencies are written. > As a developer I just want to get on with my work, not have to read another Hackernoon post on how everything from last week is obsolete because XYZ framework My recommendation is that you don't read Hackernoon. This seems like a very ineffective way to level up your developer skills. Edit: I agree that Elixir is very nice and would pick it over JavaScript for backend heavy applications without thinking. I just don't think this argument makes any sense in that context.
  • IloveHN84 8y ago
    "backend" and "JavaScript" quite don't fit together in the same phrase. I would never work on backend with JavaScript or any other interpreted language, due to error proness.
    • marcinzm 8y ago
      You're free not to work on backend javascript (or other interpreted languages) but many people would (and do) disagree with you.
    • deleted 8y ago
      [deleted]
    • klibertp 8y ago
      > interpreted language, due to error proness. There is no connection, at all, between a language being interpreted and it being error-prone to write or run. You either mean something else or are mistaken.
  • forty 8y ago
    > nobody is forced to use new libraries only because they use JavaScript. It's not completely true IMO for 2 reasons: 1- the nodejs standard lib is quite poor compared to say, Java's, Scala's or python's, so you generally need quite a lot of modules to do anything 2- the npm ecosystem is much more amateur. To do anything you have a ton of poorly supported by hobbyists or not supported at all modules. This can force you to change modules/libs regularly. This is to be compared to the Java ecosystem for example, were more people are working together to build well supported/high quality libs (Apache libraries for example)
• faitswulff 8y ago
  If the erratically emphasized text bothers anyone else, you can get rid of it by running the following JS in console: document.querySelectorAll('em').forEach(el => el.replaceWith(new Text(el.innerText)))
  • jmknoll 8y ago
    Great, thank you. I have no idea what the author was trying to achieve there, but it made the article really difficult to read
• trashhalo 8y ago
  I keep wanting to be hyped about elixer but the performance benchmarks confuse me. If you look at the tech emperor benchmarks[1] phoenix makes the list at #46 registering 16% of the performance of the top framework. I'm willing to sacrifice performance for readable maintainable code but it just surprises me that its that slow. Anyone know whats going on there? 1. https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=fortune&l=zg24jj-1 https://www.techempower.com/benchmarks/#section=data-r17&hw=...
  • mattferderer 8y ago
    I don't know the exact specifics here but I know a lot of communities that rank high invest time contributing into the open source Tech Empower tests for their framework. This way they can tweak & make sure their stack runs at optimal speeds. At the same time, Elixir (and Erlang) are not meant for raw speed. It is best used for real time communication, lots of users & handling errors. At least that is what I have read.
  • djm_ 8y ago
    >Anyone know whats going on there? Yup, many things. It's worth reading this very long thread about exactly this, from 2016. Look for Sasa Juric and Chris McCord's comments in particular. [1] tl;dr benchmarks are hard, not all benchmarks are implemented well, Elixir folks haven't heard back from Tech Empower re: details of errors rates etc. It's an unfair analysis, and not just for Elixir. [1] https://elixirforum.com/t/techempower-benchmarks/171/44 https://elixirforum.com/t/techempower-benchmarks/171/44
  • hnra 8y ago
    Simply looking at its position in that list will tell you nothing without looking at what is above and below. I don't use Phoenix or Elixir but from what I understand Phoenix tries to be for Elixir what Rails is for Ruby. That is, it is a full web framework. The number one position on that list is a "Asynchronous PostgreSQL driver". This would be a more apt comparison: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=fortune&c=6&o=e&f=zik05z-zik073-zik0zj-zik0zj-zhxjwf-zdk8an-q2xtz3-qmx0qn-e3 https://www.techempower.com/benchmarks/#section=data-r17&hw=...
  • 8y ago
• bicx 8y ago
  I use Elixir daily for the past 8 months, and I love it. For my personal projects, I use a great Heroku-like service called Gigalixir (https://gigalixir.com/ https://gigalixir.com/). No restarts or connection limits for the free tier, and it runs on your choice of Google Cloud or AWS behind the scenes. Elixir doesn't have as many easy cloud deployment options as, say, JS, so this service is really helpful.
• qwerty456127 8y ago
  Isn't Elixir the most efficient thing available?
  • ninjakeyboard 8y ago
    no elixir/beam is very slow for any computation-heavy tasks.
    • qwerty456127 8y ago
      But what about not so computation-heavy tasks like parsing HTTP requests, interacting with databases, generating and serving responses based on the input, templates, reasonably simple logic and the data? And if it's not fast then why even consider it when there are more well-established alternatives like Ruby for those who like the syntax, ASP.Net/Core, Python/Django, Node/Express, Scala/Play for the FP lovers etc? I've been previously told it's key features are it's super fast, functional and Ruby-like.
      • pmontra 8y ago
        Super fast, no. At least not in the C++ way. Faster than Ruby or Python, yes. Functional, yes. Ruby-like, yes, as German is English like (mostly guessable vocabulary.) Then you discover that the two languages work in totally different ways and your Ruby skills don't really matter anything when working in Elixir.
  • SahAssar 8y ago
    Elixir is pretty fast, but far from the fastest or efficient. IMO if all you need is CRUD server that operates efficiently then elixir is probably the wrong choice unless you already know it. It does have some nice features within distribution and real-time stuff, but if you don't need that and don't know erlang or elixir I wouldn't use it.
• bnchrch 8y ago
  I've been using Elixir to build applications for production use for 3 years now my summary is I and my whole team can (in contrast to languages I've used in the past): - Ship faster - Write simple, readable, reliable and fast code - Scale easier and with less resources - Onboard and train new hires into the code base quicker I know I'm making it out to be a panacea which to be clear it isn't as the deployment story still has some final pieces for the core team to work through but I will say I'll continue to use it to build in the future
• artellectual 8y ago
  I’ve been programming in elixir for about 2 years now. I have to say it’s hard to go back to something like Ruby or JavaScript. In elixir you really get the full power of multi core and support for distributed computing out of the box. Code that would have been beyond my pay grade or wouldn’t even imagine to write in Ruby or JavaScript is now easily reasoned about and maintained in projects. I can write succinct code that is easy to read, is fast, able to take advantage of multiple cores, less error prone, which I can scale to multiple machines easily. The erlang scheduler is so damn powerful and it feels amazing to be able to execute your code on multiple machines with a simple distributed task which is built in as a standard functionality of the language. I’ll end this note saying that, look at the problem you are trying to solve. If you need multi core and distributed features (which is generally more common than you think) elixir is truly your friend. I can say without a shadow of a doubt the project I’m building right now would not be progressing as fast as it is if I picked anything other than Elixir. You get a lot of bang for your buck when it comes to productivity in the domain that elixir solves for.
  • arcticfox 8y ago
    > If you need multi core and distributed features (which is generally more common than you think) elixir is truly your friend. Is it though? At least in my line of work I don't think I've ever run into this. I feel like I've always been able to distribute just fine with workers/queues. If I even suspected it would I'd look into it more, but generally I find distributing across systems to be a software architecture-level and not language-level work; perhaps I'm missing something, however.
    • quaunaut 8y ago
      Until I used Elixir, I thought workers/queues were enough. But after the last nearly-three-years, I've actually fallen into a place where workers/queues are almost always strictly inferior. Workers/queues in languages like Ruby have problems like, * Require very specific ergonomics(for example, don't hand the model over, hand over the ID so you can pull over the freshest version and not overwrite) * They require a separate storage system, like your DB, Redis, etc. This doesn't sound big, but when doing complex things it can turn into hell. * They have to be run in a separate process, which makes deployment more difficult. * They're slow. Almost all of them work on polling the receiving tables for work, which means you've got a lag time of 1-5 seconds per job. Furthermore, the worse your system load, the slower they go. * You can't reliably "resume" from going multi-process. Lets say you're fine with the user waiting 2-3 seconds to have a request finish. With workers/queues, you either have to poll to figure out when something finished(which is not only very slow, but error prone), or you have to just go slow and not multi-process, making it into a 8-10 second request even though you've got the processing power to go faster. So, you've got all that. Or in Elixir, for a simple case, you replace `Enum`(your generic collection functions) with `Flow` and suddenly the whole thing is parallel. I mean that pretty literally too- when I need free performance on collections, that's usually what I do. Works 95% of the time, and that other 5% is where you need really specific functionality anyway, and for those, Elixir still has the best solution to it I've ever seen.
• nixpulvis 8y ago
  Tangent: It's proposed that Elixir has better error handling than Rust... but this doesn't sit well with me, and I know the Rust community is in flux here as well. I personally like not having exceptions. It's very easy to trace where an error is coming from when it's a value like anything else. Yea it might be a bit more typing... this is the conflict. Rust does have an issue with the boilerplate involved with writing error types, but there are already attempts at fixing this as a crate: https://github.com/rust-lang-nursery/failure https://github.com/rust-lang-nursery/failure
  • qaq 8y ago
    ? OTP and Supervisers give you powerful tools for building fault tolerant apps but at the lang level it would be hard to argue that Elixir has better error handling
  • thedoops 8y ago
    Different tools for different jobs. Rust is more of a systems language for close to metal performance and memory safety. Elixir is memory safe from a functional perspective utilizing the actor model. Elixir is good for real time concurrency and higher level systems.
• sb8244 8y ago
  I've been fortunate to work with a CTO that sees the value in Elixir and also letting us push forward with it. It has been excellent. At this point we have about 20 engineers who have chosen to work in it close to full time for their services. It's hard to pick one big draw, but I'd say the biggest for me is that everything I wanted to do in rails has been possible in Elixir and then additional functionality not easily possible in rails is trivial in Elixir. I often consider the distribution techniques as "enhancers" as you could work around them with global locks and data stores, but you don't need to. I'm very bullish on Elixir and I'm curious to see where it will go. Looking forward to giving my talk about bringing Elixir into production (from a human and technical standpoint) at Lonestar Elixir conference.
  • pmarreck 8y ago
    > everything I wanted to do in rails has been possible in Elixir and then additional functionality not easily possible in rails is trivial in Elixir I also noticed that every functionality I write in both Ruby and Elixir is both more concise (less code) in Elixir as well as 5-10x faster :)
• cjhanks 8y ago
  I guess I feel like the annoying formatting is indicative of the community, immature. Web developers seem to follow trends; Perl -> DJango|RoR -> Node.JS -> Scala -> GoLang -> Elixir -> Something. Or, something like that. To me, it's like buying a $500 pencil and expecting that you should be capable of writing a better book. If you get in bed with that crowd, don't expect that your program and 3rd party dependencies are going to be stable in 2 years.
  • sb8244 8y ago
    A lot of individuals I've seen in the community so far haven't been the type to quickly jump onto a trend. People have been thoughtful with their application design and have chosen Elixir instead of alternatives. Given how drastically different the BEAM is from these other languages, I have a hard time seeing some of the people I've met (and myself) jump to something else. My guess is that if it does happen to others, it is because they switched jobs and cannot get buy in. Pretty unfounded comments regarding stability of packages long term. As with any community that makes it easy to publish packages, there will certainly be package churn over time. However, core libraries show 0 sign of this and Phoenix in particular has taken a very mature stance on new features.
    • cjhanks 8y ago
      Yes. And in 3 years (or so) when the hype-train moves on, and all that is left is the core users. It will be a much more viable choice for development, in my opinion. I don't think anything negative of the language or core libraries.
  • davydog187 8y ago
    Let’s not generalize the community over one blog post. The Elixir community has been very mature in my experience.
• phtrivier 8y ago
  Elixir has great things "of his own": * the syntax is well though-of (`with`, destructuring, `|>` are powerful * message passing has great use-cases And then it has problems that are not necessarily "elixir-y", but are there nonetheless: * it's hard to model an application around the Actor model. It's very easy to abuse it. * it's hard to maintain / refactor a large application without help from the compiler before run-time * it's hard to maintain an application in a language with a young ecosystem and no "seamless" integration with a better established one (ports are not seamless.) Quite frankly, I'm looking forward to writing a backend in Rust, to have a point of comparison.
  • thedoops 8y ago
    I've found CQRS and DDD designs fit well with OTP and elixir. The actor model with pattern matching ends up cutting away a lot of the classical OOP DDD details. The issue I see is carryover from other ecosystems taking paradigms that aren't necessary and don't fit into libraries and patterns. It feels like there are still conventions to settle on.
  • guscost 8y ago
    Thanks for these notes. I’m suspicious of unconditional praise for any technology, and a lot of the goodwill for Elixir seems like it’s biased by the intention to promote adoption of the language, or like it’s from people who haven’t encountered or paid attention to its problematic aspects. Seeing fundamental problems listed like this does more to convince me that it is a real and serious technology (one with a compelling set of strengths, no less). As for Rust, do try it out. Haskell-esque type checking, the “anti-OO” interpretation of C-style conventions, and memory safety without garbage collection are a seriously potent set of features, but it can be frustrating when you find out yet again that your whole day of R&D leads somewhere incompatible with its philosophy, and is therefore a dead end. I’m building a Rust webservice framework as a hobby/learning project, but it wouldn’t be my first choice for a production API under active development. On the other hand I’m not aware of a better choice for an embedded daemon process or a stable microservice.
    • pdimitar 8y ago
• therealmarv 8y ago
  Elixir is a niche (that's the truth). Also in the article it is written 'Relatively difficult to "recruit" developers with existing experience in Elixir'. Why would a SW company invest in niche languages where the resources (software developers) are really expensive and really hard to get? Technologically it's all great but economically that's a nightmare.
  • bicx 8y ago
    If you have a solid background in software development, it's not too hard to become proficient in Elixir in a few weeks. If you recruit good talent with a demonstrated proficiency and willingness to learn, you will be fine. If you need to switch languages or systems in the future, these devs will still be of great use to you.
    • therealmarv 8y ago
      Ok, that sounds good. My overall experience is only for most companies (I'm working as a contractor for many years) that they don't really want to invest in you. Either you fit for the job or not (and competition is not easy sometimes).
      • markkanof 8y ago
        I can’t argue with this point in general, but your first question was from the perspective of a company. There certainly are companies, that are willing to use things like Elixir (like my company for example) because we believe that an experienced developer should be able to come up to speed quickly with Elixir. What really takes the time is learning our business domain and our existing codebase. Or looking at it another way, I wouldn’t want to hire someone that was a Rails dev, I would want to hire someone that was a strong dev in general and may have happened to be doing Rails most recently.
  • sb8244 8y ago
    I have been involved with bringing it to my company as the primary proponent. The truth is it hasn't been hard to teach people it and they can produce decent code pretty quickly and good code a bit longer than that but still acceptable. We have found a few people who knew it already and were looking for a job, but that is fairly rare. Instead, we know we can bring people up to speed on it quickly and also it signals to people that we're willing to give them some language options (Ruby or Elixir) within some boundaries. Having these options is good for ownership of an area.
• qaq 8y ago
  Depends on the project. I have a project that heavily relies on headless chrome for scraping dynamic pages I'd rather stick to Node and Puppeteer for this particular project. In general Elixir is a joy to use but some of the trade-offs BEAM(Erlang VM) makes might not match your requirements e.g. if you don't need live code upgrades but project could benefit from static typing you might want to consider something else.
• cuddlecake 8y ago
  I love Elixir. It's the first language I genuinely enjoy reading and writing even in my private life. If I wonder about the internals of a library I use, I can just look into the code and kind of understand what's happening. Never had that with JS or anything. I'm just a genuine fanboy. Only drawback I feel is: Some libraries that would have been quite developed in JS are not that well developed in Elixir. Some libraries are quite dead and it's hard to find alternatives (mostly obscure stuff) But on the other hand, it often seems manageable to just write it yourself, or fork it and move on.
• atonse 8y ago
  From a technology perspective, a thousand times yes. And the same for Ember JS (my other go-to). But from a talent and recruiting perspective, I'm less enthusiastic. Elixir, yes, there's growing talent. But Ember, boy it seems like nobody is doing it, and I've had to convince potential candidates that it'll be worth their time for future employability to learn Ember.
• pjmlp 8y ago
  From someone that comes from Java/.NET land, I hardly see a benefit, specially given the wealth of programming language options on those platforms. Now for someone starting new, maybe the Erlang eco-system might be a good bet, and Elixir an entry point. Still, not everyone has Ericson scale problems to solve.
  • klibertp 8y ago
    Erlang (and, by extension, Elixir) is still one of the very few systems which offer this exact (or even just close enough) mix of features AFAIK. Whether this set fits your use-case or not, and whether it would give you an advantage over your chosen technology, are both very important points, but there's also something to be said about how good and well-implemented it is for some use-case(s). To be honest, I first learned Erlang along with Prolog, Forth, Lisp or J - out of curiosity about various paradigms and the most "pure" implementations of them. Erlang was at the time the oldest, actively developed, open-source system for concurrent and distributed programming. Today I think I'd go with Pony, which implements Actor-model on the language-level too, but also with support for it in the (static) type system. Anyway, what I wanted to say is that Erlang is first and foremost a fault-tolerant language and system, of which both distribution and concurrency are by-products. As an example of a "fault" that the creators of Erlang had in mind, Joe Armstrong often cites "being hit by lightning": the only way to ensure the system will still function after that is to have its copy running somewhere else, hence distribution. Another type of fault I think explicitly mentioned in "Programming Erlang" is dealing with hardware failures, sensors and outputs getting disconnected and reconnected, etc. - hence concurrency and per-process error isolation. Finally, "programmer errors" are also a kind of a fault (as impossible to completely avoid as lightning or flood), hence immutability, versioned rolling upgrades and rollbacks and live introspection into any node from anywhere in the system (among other things). That is not to say that the by-products aren't important or nice to have, just that many of the design decisions in Erlang start making a bit more sense if you look at them from this angle. It also helps to decide whether Erlang is the right tool for you: it's going to save you many, many years of effort if you need a nine-nines guarantee for a system you'd otherwise have to write a few million loc of C; it can still give you a bit of an edge if you are able to make use of its unique features like a built-in distributed data-store or if the Actor-model with preemptive scheduling fits your app very well. Outside of these pretty specific use-cases (although, to be fair, I'm just giving examples - Erlang/OTP is a large (in terms of built-in functionality) system and Elixir adds even more stuff, so there are many more good use-cases for it) you may struggle to realize any positive outcome with Erlang: unfamiliar everything, no libraries, a runtime system always ready for connecting to remote nodes even if you're writing command-line script, immutability has a performance cost and overall performance is not impressive and so on, each of this things could potentially bring down your project if not carefully considered.
• lopatin 8y ago
  Does anyone have experience with Elixir as well as Scala/Akka. Afaik, these are the two largest Erlang inspired systems out there. I only have experience with Akka, and I'd love to hear a comparison.
  • ninjakeyboard 8y ago
    I have experience with both. I have recently been working with Elixir. It's okay. I find the lack of static typing to be some thing I celebrate and curse. Elixir is VERY simple and beam is VERY slow at computation. I wouldn't recommend anyone working with scala/akka look at elixir unless you want to understand how BEAM works but I would recommend _everyone_ working with elixir learn different functional programming languages. Ultimately I'm much happier writing scala with akka. I get more done faster (except things like handling json sometimes because it's hard with types), can refactor the code more freely, and release less broken code to production.
    • ninjakeyboard 8y ago
      Also, I have to say that elixir developers are generally not very experienced with it and seem to be generally less desirable than the people who are working with scala. You get rubyists that have some interest in working with elixir because there were some blog posts saying it's the new hotness. Scala seems to attract more comp-sci savvy people. And generally those people will refuse to work with elixir when there are Scala job out there that will pay. Startups should use scala for these reasons. Elixir may be a mistake for the resource pool alone. One thing that's trecherous is that rubyists can bring whatever they believe to be the right way to do things and assume everything should be exactly the same, especially with regards to ecto vs active record. Elixir isn't ruby. Ecto isn't rails active record. Not anywhere close. It just happens to look like ruby and there are some influences in the design but Ecto tells you not too implement STI like rails does for example so don't assume you're going to do it like you would in rails. I'd argue ruby is more like scala than it is like elixir as it has multiple paradigms. Elixir is squarely functional, just a very very simple functional language. The skill ceiling is pretty low and it should take very little time for someone to get up to speed which is important because you won't find a big pool of rockstars using it in the job market so you'll have to hire good people without experience and hope they will be okay using elixir and not jump ship to go work with strong typed languages.
• diminish 8y ago
  I wouldn't pick Elixir because: Rails has revolutionized web application development on Ruby, with Sinatra as the minimalist version and a lot of "me too" frameworks have been developed, and somehow I like them all. * On Python, Django and Flask * On Elixir, Phoenix * On Crystal, Amber * On Javascript Express js for Sinatra. But on JS we didn't get a successful Rails clone, but a storm of front end frameworks, finally Vue JS/React and endless others. I wouldn't pick Elixir because The world is elsewhere: My choice is on JavaScript ES6, Vue, and a simple Express.js, Sinatra, Flask for most projects.
  • thedoops 8y ago
    If all you're doing is CRUD apps, there's not much more to gain from Elixir. But if you're doing things like pulling in Redis or Sidekiq, or building around realtime use cases - Elixir has so much more to give you.
  • rootlocus 8y ago
    > The world is elsewhere The world is everywhere. Other people have pointed out Elixir is very good at taking advantage of multiple cores and writing distributed applications which are easier to reason about, less error prone and very efficient. I wouldn't say the same things about javascript.
  • seanhandley 8y ago
    > I wouldn't pick Elixir because The world is elsewhere People said the same thing about PHP when Rails was first on the scene and there are still way more PHP web apps out there. You could say the world still runs on PHP but that's not a good enough justification to choose it.
• arvidkahl 8y ago
  I've been working with Elixir in a single-developer production system for over a year now. I'm running it in Docker containers on Kubernetes, in the cloud. It has been extremely stable, scaling has been a non-issue. Error reporting has become easier and easier, now that companies like Sentry and AppSignal have integrations for Elixir. Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediately, while still serving the static parts of the application. PDF generation wonky? Same thing. Incredibly fast on static assets, still very fast for anything else. I've had nothing but fun with the language and the platform. And the Phoenix Framework is just icing on the cake. I've been fortunate to have been to many community events, and meeting (among so many others) José and Chris at conferences has made me very confident that this piece of software has a bright future. The Elixir slack is also VERY helpful, with maintainers of most important libraries being super responsive. I would not start another (side or production) project with anything else than Elixir.
  • hombre_fatal 8y ago
    > Elixir is VERY fault-tolerant. DB connection crashing? Ah well, reconnects immediately, while still serving the static parts of the application. PDF generation wonky? Same thing. I still don't understand this. I don't think I've ever built a web server in any language where this wasn't true unless I specifically wanted hard failure. The amount of fault tolerance would be a per-app design goal rather than something that seems to be a language feature. I've worked in apps in all languages that range from any failure being a hard failure to being impossible to crash, and this is due to business requirement. For example, regarding your examples, just about every web server I can think of will automatically turn uncaught exceptions into 500 responses unless you opt otherwise.
    • arvidkahl 8y ago
      It's less about how it handles exceptions but rather how the BEAM makes sure that things that break don't crash the whole system. The magic is in the supervisor pattern, explained here for erlang: http://erlang.org/documentation/doc-4.9.1/doc/design_principles/sup_princ.html http://erlang.org/documentation/doc-4.9.1/doc/design_princip... It is hard to describe why this "feels different" in Elixir than it does in Express.js or a Tomcat running a Java application. It's all experiential for me, but maybe I can put the sentiment in words: I always KNOW that whatever part of my application may break, however much and for whatever duration, the scheduler and the supervisors will make sure that the rest of the system runs exactly as intended, and the broken part of the system will be back up eventually. I did not have this feeling (as strongly) prior to working with Elixir. But I will admit this is a very subjective position. And I am not sure you'd experience it the same way were you in a similar situation.
• dev_dull 8y ago
  > No "native" type for JSON data. You always have to parse JSON into a Map and there are excellent libraries for doing this. I guess the better question would be why is there not an easy, standard lib for doing this in any language in 2019?
  • klibertp 8y ago
    I didn't read the article, but intuitively, from the quote you posted, I'd say it's about having JSON(or close to)-literals in the language and/or having Map/List types with semantics close to that of JS. For example, in Python dict and list literals are perfectly valid JSON if you remember not to use single quotes (' vs. "), and the semantics are also pretty close to JS. In Elixir this is not the case: the Map syntax could pass for JSON if you squint hard enough: %{key: "val", key2: [1, 2, 3]} but the semantics here are actually something like this in JS: {Symbol("key"): new Int8Array(/*utf-8 encoded*/ "val"), Symbol("key2"): new LinkedList([1, 2, 3])} you can get rid of the `Symbol()` part in the translation, but then the literal becomes: %{"key" => "val", ...} so, basically, the gap between JSON and Elixir is wider, both syntactically and semantically, than it is in some other popular languages.
• zerr 8y ago
  Considering progress in statically typed languages with regard to programmer ergonomics, does it still make sense to go with dynamic languages?
  • mrdoops 8y ago
    Between pattern matching and typespecs you get a lot of the "hey you're doing something wrong" checks at compile time to avoid errors. Definitely not a complete solution; a language like OCaml or F# will be better if you're concerned about type safety. The dynamic typing in Elixir/Erlang is a trade-off for Actor model message passing. You get a state of the art run-time for fault tolerance and concurrency, but the messaging aspect makes typing problem-prone. A co-dependency on a custom type is coupling you want to avoid when sending messages around. You don't want a long running process that knows about Type_v1 sent a message from a newer process messaging with Type_v2. The Aeternity team is building blockchain systems with Erlang for nodes and infrastructure. However since smart-contracts necessitate so much type safety and formal verification - they're designing an ML flavor functional language just for that.
• neathack 8y ago
  I have never used Elixir, so maybe it's a great language, maybe not. But I have to question the reasoning of the post simply going by the comments about other languages in the "Conclusions" sections — some of which I did use extensively. Really, Go "is the choice if you need to 'sell it' to a 'Boss'" and the imperative programming style leads to more complexity? And Python/Django can only be used if you "don't need anything 'real time' and just want RESTful 'CRUD'". I get it, you guys like Elixir, but painting the world using such broad strokes doesn't really sound like "kaizen learning culture" to me, but more like "Negative Nancy".
  • PopeDotNinja 8y ago
    I really like Elixir. There are a lot of practical realities that can make Elixir not the best language to use in many situations, and the same is true for any language. Just ignore the hype train, because you'll find one for every language. I'd say Elixir's killer feature in today's day & age is concurrency. I'd argue that using concurrency is appropriate in most programming situations IF your language's concurrency model isn't a pain in the ass to use. You can write completely non-blocking, async code in Elixir (and Erlang) without losing your mind. The preemptive scheduling is nice, too. I love a lot of other stuff about Elixir, too. Pattern matching, process supervision, tooling, documentation, etc.
  • petre 8y ago
    Phoenix speed/scalabity is quite on par with Go frameworks like Gin. I wouldn't use Django in 2019 for a new project. It's not even async/non blocking.
• chmln 8y ago
  This went past me as the post is filled with a lot of claims with no reasoning to back those up. It is not a critical evaluation of the language, but rather sounds like a "fanboy" piece, for the lack of a better term. > Memory efficiency is much better than most other languages (with the exception of Rust, but Elixir is miles better at Error handling than Rust, which is a more practical feature IMO How exactly are arbitrary runtime exceptions better? Any elixir function you call has the potential to crash. Meanwhile with Rust, your function returns a `Result` if it can error, and callers are then forced to handle those by the compiler, either via pattern matching or ergonomic error propagation. Rust has runtime panics, but those are for rare unrecoverable errors and are not at all used for conventional error handling, reserved usually for C FFI, graphics code, etc.
  • nelsonic 8y ago
    @chmin thanks for the great feedback! ;-) I did not write the post for general consumption, more as a reply to the question from the person as indicated in the first paragraph of the thread ... I really did not expect it to end up on HN. ¯\_(ツ)_/¯ 100% Agree that there is a lack of "critical evaluation" and it borders on "fanboy" ... It's not a scientific or statistical analysis because I did not find any data I could use to make a an argument either way. My experience with Elixir, JavaScript, Ruby, Java, PHP, etc. is based on doing the work in several companies big and small and I don't consider myself an "expert" in any of these languages. I have felt the pain of having to maintain/debug several large codebases with incomprehensible/impenetrable and untested code over the years and I find Elixir to be the most approachable of the languages I am fluent with. I wish there was an objective way of assessing the day-to-day experience of living with a language ... have you come across such a measure that isn't based on the opinions of, as you say, "fanboy" users? You appear to have superior knowledge/experience of Rust. Have you written any tutorials or blog posts sharing that knowledge? I would love to read your work. Is this you: https://github.com/chmln https://github.com/chmln ? If it is, https://github.com/chmln/asciimath-rs https://github.com/chmln/asciimath-rs looks cool! (nice work! :-)
    • chillaxtian 8y ago
      I really think that you don't need to utilize italics to make yourself appear like you care.
• phil_s_stein 8y ago
  Why does the "author" love "quotes" so much? Makes me "discount" the "article" when every other phrase is "quoted".
• whalesalad 8y ago
  This post is killing me. I’ve been really really loving Elixir and for a while was fighting the “everything looks like a nail” syndrome once I learned it. But now I have a contract that would really benefit from the runtime. That being said the existing environment has a lot of python expertise and I don’t have enough production Elixir experience to have confidence in myself to deliver something of the right caliber. It’s a damn shame. This system has to process hundreds of thousands of API calls for workloads against a half dozen third parties that all have different rate limits and failure modes. It’s the perfect job for Elixir. It needs to be as fast as possible while isolating failures to the smallest unit possible.
  • quaunaut 8y ago
    Honestly? I'd still encourage you to do it. The thing that's nice about Elixir, is that it gives you the tools to screw up and make good on it. This isn't to say you'll write great Elixir from the beginning. I'm on a codebase now that was from back before the semantics of good Elixir were really well known(2016). It's not uncommon for me every week or two to rewrite a portion of it to look cleaner, and be more performant. The crazy thing though? Holy shit did it scale. We're doing event processing for an application that is processing nearly 100m events per week. At times, it needs to process 1500 per second. These events need to check the DB multiple times, fan out to multiple services, and make discreet HTTP calls of their own to external servers. We're still on one box. We still have plenty of the old, harder-to-read, less-performant code. And it still takes under 10 minutes to understand the deepest inner workings of any one feature in the system. I think you'd be pleasantly surprised.
    • jashmatthews 8y ago
      > The crazy thing though? Holy shit did it scale. We're doing event processing for an application that is processing nearly 100m events per week. At times, it needs to process 1500 per second. These events need to check the DB multiple times, fan out to multiple services, and make discreet HTTP calls of their own to external servers. Frameworks make a huge difference here rather than language. Phoenix and Ecto have done a really great job with performance. Ruby will deliver the same performance on a similarly light framework like Sinatra/Roda + Sequel but definitely not Rails. Once you get a high performance service running on Phoenix + Ecto or Sinatra + Sequel, the gains from moving to compiled languages are a lot smaller unless you invest a huge amount of time in optimisation.
• plainOldText 8y ago
  Yes! And most likely in 2020 as well. I've been programming intensively in Elixir for the past two years and it's a wonderfully productive language, which allows one to write elegant systems that leverage the multi-core architecture of today's machines effectively. In addition, the networking capabilities and fault tolerance of the VM make writing systems which spawn machines and services a breeze; not the mention the ecosystem only gets better by the day. So yeah, Elixir is one of my main tools when I want to get things done elegantly and productively. And if for some reason I need to speed things up a bit here and there, I just add a little rust into the mix. [1] [1] https://github.com/hansihe/rustler https://github.com/hansihe/rustler
  • hadsed 8y ago
    What sort of work have you been doing with it?
    • plainOldText 8y ago
      I've been writing a social collider for real life social interactions on demand. The backend is written in Elixir (which is a collection of services e.g chat subsystem, telemetry, authentication, rate limiting, etc) and the client is an iOS app, so Swift, which is also a nice language btw.
• jondubois 8y ago
  >> Node is a single-threaded event loop, if the process crashes for one user, it crashes for all the requests being handled by that process. i.e. one user can crash the server for hundreds/thousands of people! This is a terrible design flaw This is a design flaw on the part of the team who is using Node.js incorrectly and not a flaw of Node.js itself. There are many ways to implement error handling properly in Node.js so that a user cannot crash a whole server/process and there are a lot of frameworks which implement this by default. Elixir is over-marketed and over-hyped. It's obvious that there is a big money machine behind it. The entire community is obsessed with evangelizing; they're not getting organic growth; they have very aggressive marketing but it's mostly founded on exaggerations and flat out lies. In addition to what I've pointed out above, to say that someone can learn Elixir in just 1 week is another example of a lie. It takes years to fully understand the nuances of a language to the point that you can be good at it; there are always a lot of patterns to learn; especially for functional programming languages. The Elixir ecosystem will never be as significant as that of Node.js because Elixir's ecosystem is founded on hype. Part of the greatness of Node.js is that reality tends to exceed expectations; so-called 'thought leaders' and 'bloggers' have been working very hard to discredit Node.js from the beginning but they failed (see https://news.ycombinator.com/item?id=3062271 https://news.ycombinator.com/item?id=3062271). I'm not going to consider using Elixir while it's so clearly over-marketed and over-hyped.
  • subfay 8y ago
    Couldn't agree more. Just look at Google Tends. Because Elixir is dying they do more and more content marketing: https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0pl075p https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F0pl... In their Slack channel they orchestrate organized upvotes of such post like this one, they collectively downvote people like the parent and post fanboism through several accounts. Elixir is a solution without a problem.
• butterisgood 8y ago
  Did this article claim Haskell was slower than Erlang/Elixir?! That’s never been my experience and I’ve shipped both!
• hartator 8y ago
  Was very excited by Exilir coming from Ruby, however found 2 issues that made it hard to work with: - Pipelines are hard to debug. You can’t just throw a debugger just before the line with the issue. - Phoenix is very bad at serving static files. It was a nightmare to import a new CSS template requiring to convert everything to work with bower first, or dump the files in the /priv directory to make it work.
  • andy_ppp 8y ago
    Both of these points are False, point 2 I’ve been integrating a bootstrap framework and sass and it’s super simple; I put the files in assets, add npm install —save sass and that’s it! Then debugging a pipeline is as simple as dropping in IO.inspect between statements as it returns the content as well as printing. thing |> stage1 |> IO.inspect |> stage2 Not that difficult!
    • hartator 8y ago
      > I put the files in assets, add npm install —save sass and that’s it! It takes forever if your assets are large. Just serving random static files shouldn't take long. > IO.inspect It's nothing like a real debugger.
      • rehemiau 8y ago
        I agree about the inspect / pry not being a real debugger but could you expand on your problems with the debugger and pipelines? Are you using the Erlang :debugger module? The only "problem" I see is that we can't set a breakpoint on the first line of a Elixir pipeline, but to see the value of variable from that line we can set a breakpoint on the last line of the pipeline. To see why that happens we can try stepping through a pipeline with the debugger: First "executed" is the last line of the pipeline, then the second line, then third etc and it looks like for the debugger the first line of the pipeline never happened. I don't think this is a big problem to be honest.
      • andy_ppp 8y ago
        I’ve not found this, are you on windows? Inspect is fine as in Elixir you don’t have any hidden state. Use the :debugger if you need more than this.
• bsaul 8y ago
  Question : How does OTP work together with things like kubernetes in the real world ? Designing around actors with OTP spawning and respawning part of the actor tree, while at the same time provisionning / deprovisionning VMs if load is going up or down, sounds like either a dream if it works well, or a nightmare if there's just a single glitch somewhere.
  • subfay 8y ago
    Best question in this thread and I am looking fwd to an answer. I guess that just very few mastered Elixir and k8s.
• abledon 8y ago
  can people give real world business use cases for where they are using elixir? What industries are you working in? what actually gets done in the real world at the end of the day with the system you're working on? e.g. are more ads served to web users? are you monitoring methane on IOT things strapped to cows in farm fields?
  • romanhn 8y ago
    PagerDuty has standardized on Elixir as the backend language of choice after a couple of years of incremental adoption with new services. Developer happiness definitely helped get the word spread. https://www.pagerduty.com/blog/elixir-at-pagerduty/ https://www.pagerduty.com/blog/elixir-at-pagerduty/
    • abledon 8y ago
      Ok so they use Elixir there to make dashboards. cool.
      • romanhn 8y ago
        Highly available critical services comprising the PagerDuty infrastructure, actually. Cool dismissal though.
        • abledon 8y ago
          what are some concrete examples?
  • di4na 8y ago
    www.lovethework.com run on elixir. Data transfer and transformation from an old system, web frontend (we are refactoring a lot of the current javascript stuff recently), ecommerce, the admin stuff on the back office too. Mostly good old web stuff.
  • rehemiau 8y ago
    - chat / IMs backends - multimedia streaming - multiplayer game servers Generally soft real-time systems
• subfay 8y ago
  no it's premature optimization, you won't find any devs, 99% of elixir can be done in node + k8s.
• troquerre 8y ago
  What kind of problems are people using Elixir to solve in production? My impression is it’s mainly useful for highly networked applications with real-time features (i.e. chat), but it seems like for most applications you’d be better off picking rails or nodejs for the community/ecosystem.
  • petre 8y ago
    > for most applications you’d be better off picking rails or nodejs for the community/ecosystem Only to find out they do not scale very well after your application is mature and used by a growing number of clients.
  • digitalzombie 8y ago
    I dislike coding in javascript for large project. The language was originally for small stuff. NodeJS bought it to backend and the language itself weren't meant for it. Since then ECMA5 and stuff tried to fix these shortcomings. But you can't expect me to love javascript's weakly type versus elixir or python's strong type (strong not static, as in it doesn't implicitly type convert stuff like javascript). It's a nightmare and concurrency model in NodeJS in my opinion is subpar compare to Elixir's.
• heurist 8y ago
  Our team has had great success with Elixir over the last year and ported core node services to it over the last few months. We are very happy with the results. There are some things we haven't been able to do with it, like intensive data processing (for which Python is still used), but if those libraries existed we would switch our Python services ASAP and be an entirely elixir backend.
• rthille 8y ago
  Sees post recommends https://nerves-project.org https://nerves-project.org for IoT Clicks thru Sees that Nerves is an excellent platform for IoT and only requires a base of 12MB and Linux. Quickly backs away.
  • pmarreck 8y ago
    Do you have an actual rational counterargument? It is a completely stripped-down Linux that boots directly into BEAM.
• undersheet 8y ago
  This feels like an orchestrated upvoting and content marketing flash mob from the Elixir Slack channel. Google Trends shows that Elixir is declining. I love new languages but don't like to be fooled.
• GordonS 8y ago
  Has anyone had experience of both Elixir and F#? I've dabbled with both - but really fell in love with both of them! I come from a C# background, so the static typing of F# is a big pull. OTOH, the simplicity of Elixir was an absolute delight - after just an afternoon, I felt like I had a decent grasp of it. I'm conflicted, and would value some other opinions?
  • himaraya 8y ago
    Depends on what you want to do, I think. The pros of the BEAM likely outweigh the cons of Elixir's dynamic types for distributed messaging systems, e.g., Discord. Otherwise, F# and the SAFE stack probably can serve other backend needs more safely with better library support from .NET. Elixir does seem more trendy than F#, which has lagged somewhat due to second-class support from Microsoft and lingering dislike for .NET -- hopefully things will improve as .NET Core matures.
• atombender 8y ago
  I love Erlang's OTP, but I would never go back to a dynamically typed language. Most of my current work is in Go, which is a fairly strict language, and I value perhaps more than anything the ability to verify my program at compile time -- for one, I can do large-scale refactoringest, safe in the knowledge that my program won't run until everything is again sound. Go still leaves a lot to be desired, so I've been exploring options. I've started picking up Rust. I love the idea of zero-cost abstractions, though at the moment I find the mental overhead of a lot of the constructs (lifetime annotation, implicit operations that happen due to what traits you implement, the many baroque syntax choices, etc.) a little annoying. It brings to mind modern C++, which also has a lot of rules that you have to remember, from copy constructors to what the order of "const" in var/arg decls mean, to the awkward split between functional and imperative styles. Modern C++ looks interesting, and I've used it for a few projects. What bugs me the most is the warts still not fixed by the "modern" iterations: Include files (leading to long compilation times), lack of modules, unsafe pointers, etc. While I appreciate and understand template mechanics, I'm not overly impressed with some developments -- Rust traits and Haskell typeclasses just seem so much less messy than the current situation with type traits and concepts. There's a tendency in "modern" C++ to offer multiple syntaxes for the same thing, none of which are very intuitive. I've occasionally written small things in Haskell and OCaml, and I've considered doing a future project in OCaml now that multicore support is getting close. I looked at F# for a bit, too, but it comes across as having too much .NET/Microsoft flavour for me. Same with C#. I've looked at Nim, but it's too niche -- for the projects I'm going to work on, I'd have to write libraries for functionality that just isn't there yet (e.g. gRPC). Back to Elixir, though; the problem is of course that none of these other languages offer anything like OTP. The closest may be Haskell, with it's Distributed Haskell project. But I'm not sure it's anywhere close to being as mature. Maybe Pony is comparable, but that also seems quite niche at this point.
  • himaraya 8y ago
    > I looked at F# for a bit, too, but it comes across as having too much .NET/Microsoft flavour for me. Mind elaborating? F# seems like a decent fit from what you've said. I'm hoping the language will grow less stagnant as .NET Core matures.
• rs86 8y ago
  I have mixed feelings about using Elixir (or Erlang); as far as I understand the platform, it is about building fault tolerant systems/high availability, specially in the presence of hardware failure. I think those are handled well by cloud service providers; they didn't exist during the 80s. I think performance is better compared to Ruby and Python, but then again my experience with web applications is that the domains are best modeled using classes. For writing networking code and protocols, the binary pattern matching is amazing, though. The Plug libraries are a pleasure to use also.
• honkycat 8y ago
  Elixir is the best programming language I have ever worked with. I absolutely love it. Elixir has totally spoiled me. The meta-programming ALONE is something I miss constantly when I have to use other languages.