18 ms·

An Elixir adoption success story

• kaladin_1 5y ago
  Nice story. Reminds me of how I picked up Elixir. I haven't been able to use at work though only for personal things. But the documentation is an absolute delight :) I really don't understand the obsession of some teams when they are recruiting about infinite years of experience with a certain stack. I just don't get it! Even the person that designed the tool wasn't using it before it came into existence. Anyone with enough patience and energy can grok any tool. But NO, recruiters still want someone with "10years" of React or "30yrs" of Java {:( as though your job would ever involve a single stack.
• masijo 5y ago
  I really wish there were more remote Elixir job offers. Seems like such a great productive language to use, and Phoenix with LiveView is just great.
  • brightball 5y ago
    They get posted all the time in Elixir Forum and I also see them advertised in the various email newsletters.
  • lucis 5y ago
    You might wanna check https://elixir-radar.com/ https://elixir-radar.com/
  • cpursley 5y ago
    It seems like most Elixir jobs are remote these days.
    • waynesonfire 5y ago
      most jobs are remote these days.
    • pawelduda 5y ago
      You could say they are asynchronous!
  • ch4s3 5y ago
    If you're in the US(I know, I know), PepsiCo Ecomm is hiring.
    • arcturus17 5y ago
      They’re building all the eCommerce capabilities from scratch in Elixir? Or is the latter just part of the stack?
      • chemeng 5y ago
        I’m interested as well. But having built out a complete e-commerce stack in elixir, I can say I found it particularly well suited to this use case.
      • ch4s3 5y ago
        It's a mix of things. A lot of the b2c stuff uses big partners that are already dominant in eGrocery. However the tooling around the ad placement, fulfillment, product cataloging, b2b sales, sales intelligence and consumer profiling all make use of Elixir. Basically we use React for most front ends, Python for data engineering/data science, and Elixir for everything else.
  • pawelduda 5y ago
    I feel that there are more remote Elixir jobs than ever. I get a lot of offers without actively searching, most often it's sole Elixir or Elixir + Ruby (unsurprising) combo.
  • rubyn00bie 5y ago
    Wow, this is the exact opposite of my experience. I can't imagine a company trying to hire Elixir developers and having any success unless they're willing to hire remote developers. I know a lot of folks in the community and literally everyone is remote...
• arcturus17 5y ago
  I run a growing agency and we run primarily on React + Django, but I really want to give Elixir a shot at some point. I find its concurrency features, purported developer productivity, and it’s positioning as a “niche but popular” tech (these can be nice to acquire technical clients) very appealing. Does anyone have any experience running an Elixir consultancy / agency / software house? Or freelancing? How is the market and your general experience?
  • ipnon 5y ago
    Anyone who knows Rails or Django can pick up Phoenix and anyone who likes Elixir is going to be the kind of person you want to hire.
    • deleted 5y ago
      [deleted]
    • cutler 5y ago
      Not so fast. Rubyists vary in the extent to which they fetishise OOP. Those that do are going to run a mile from Elixir once they peer beneath the surface/syntactic similarities. The Rubyists who revel in Ruby's procs, blocks and lambdas will find Elixir tantalising.
  • rubyn00bie 5y ago
    I would probably recommend against this for most things if you're running an agency. Hiring experienced Elixir developers is not easy nor cheap; and for your clients, if they want to hire developers, at some point, are going to have a really difficult time.
    • R0b0t1 5y ago
      Solution is to relax hiring requirements. The strength of the languages is what they do inherent to themselves due to their VM and standard library. You need people who know how to use them directing the effort, but once the design is there most people can pick it up.
• babelfish 5y ago
  > The need for concurrency and fault-tolerance made Elixir an obvious choice for this application, but that alone wasn't enough to seal the deal. What? Why does this make Elixir an obvious choice? Most (if not all) major languages offer concurrency primitives (e.g. goroutines), and fault-tolerance is included as a requirement by default for any sufficiently complex distributed system, but has little to do with the languages/frameworks used to build that system. Not seeing why these requirements make Elixir a better choice than any other language
  • pawelduda 5y ago
    I think it's because Elixir runs in Erlang VM which was built from the ground-up to satisfy these requirements... And it's been around for a very long time with very good track record.
    • jimsimmons 5y ago
      That really doesn’t answer the question. What does the BEAM VM provide that cannot be implemented in Rust or Go or even Python.
      • brightball 5y ago
        Immutable memory, preemptive scheduling, per process garbage collection with isolated heap and a 0.5kb memory footprint per process for starters.
        • jimsimmons 5y ago
          Immutable memory — writing functional Python or Rust can come close. Pre emp scheduling — I assume this is to prevent deadlocks? This and everything else is very nice but do we need a full VM for that? I’m not trying to be a jerk but I want to understand why this isn’t a feature implementable as a runtime.
          • SirGiggles 5y ago
• ozmaverick72 5y ago
  All these stories can be distilled into - "I picked something I liked and we made it work. Yay team"
• eric4smith 5y ago
  We use elixir 24/7 on all projects. All the new programmers that ever worked with us never knew Elixir in the first place. And all of them picked it up in a couple of weeks to a level where they could start making changes to code. I think we are overestimating the amount of time it takes to learn a new language. The hardest thing to grok with FP is immutable data. Once you get past that, you're rolling. But the speed and concurrency is no laughing matter. Miles and miles and miles ahead of ruby, python, etc in that matter. Task.start(...) Spin off a background process from a web request where you don't care to get back something. Basically eliminate Redis or caching. Just need Postgresql/Mysql. If you're wild eyed you can use Mnesia without the databases. Run jobs across a cluster sanely with a good job library that only needs Postgresql. The story goes on and on. Unless you have tons and tons invested into what you're doing right now, it makes a lot of sense to start to spin up things on the edge of your monolith or SOA with Elixir. New projects should be started with Elixir. The idea that it's "hard to find programmers" -- does not really stand up. Because anyone who can't grok a new programming language in a short time, is not really a good programmer.
  • gameswithgo 5y ago
    elixr vs clojure? f#?
    • macintux 5y ago
      Clojure if you need JVM integration. F# if you need to run on Windows (the BEAM runs under Windows, but it's to the best of my recollection not a point of emphasis). Elixir if you want a robust concurrency story and a rock-solid way of handling errors without lots of code cluttering up your business logic. I'd pick Erlang myself, but Elixir is compelling.
      • RexM 5y ago
        I’ve had no issues running the BEAM on Windows.
        • 5y ago
• xupybd 5y ago
  Wow that is insane to do that much in 3 months. I'm not sure how big the team was but I'm impressed.
  • rahimnathwani 5y ago
    7 engineers
    • pantulis 5y ago
      More impressive then ;)
• colesantiago 5y ago
  Just curious, seems to see a lot of Elixir posts crop up on HN lately. I know a startup that did £75K+ in sales in the first week with only just using node + heroku. Could the same be applied to Elixir if it is really that good? Are there any pitfalls that one should know about?
  • bastawhiz 5y ago
    Your tech stack is going to have 99.99% less to do with your first week's success than your business plan and execution.
  • RobertKerans 5y ago
    This seems slightly bizarre -- sorry for /s but if you have engineers who are familiar with {language} rather than Node then they'll probably generate more sales for your company building an application in {language} than they would building in in Node. The pitfalls would be that it'll be slower to get an application in {language} to production if the engineers know how program Node but not {language}.
  • vendiddy 5y ago
    Elixir on Heroku is just as viable (we're still running on a single heroku Dyno and postgres instance on Elixir). Not having much info, my guess is many languages would worked out for that startup.
• cutler 5y ago
  https://uk.indeed.com https://uk.indeed.com title:elixir / UK = 11 jobs The trouble with Elixir is that it's never going to be mainstream.
• krishvs 5y ago
  Looking for some advice. We have written several microservices primarily for websockets in Elixir. They are great with literal zero maintenance costs..but how do Elixir developers handle the following when going all in: 1. Long running workflows - there do not seem to be popular frameworks like camunda, jbpm, temporal or cadence for elixir 2. Integration libraries - similar to apache camel 3. Inbuilt scripting engines to run user scripts like nashorn, graaljs or groovy We really enjoy working with rails and would like to go all in into elixir. But the ecosystem of available frameworks seems to always come in the way and makes us choose spring boot or rails.
  • lostcolony 5y ago
    Pre-emptive caveat: I do not know much about the three things you mention. THAT SAID, I'm familiar with Erlang, and moderately familiar with Elixir, so wanted to still give you some areas to explore. For #3, you probably would need to NIF out to something. You can also execute an uncompiled script of Erlang using escript, but that, obviously, is not something you'd expect most users to learn (and not sure you can execute it in a running Erlang context, rather than from an external shell). You can also evaluate a string, and/or compile and load new Erlang code from a running Erlang program, but these are suuuuuper dangerous if it's user supplied. For #1, I've never seen anything, but if you just need something that allows you to change out or customize logic on the fly you can do so in a pretty straightforward manner. Because it's a functional language, you can do stuff like have a stateful process template that you can swap out on the fly, i.e., submit a list of function identifiers a la [read_data/1, transform/1, write_data/1], and now whenever you call run(data), it spins up a new actor that effectively calls write(transform(read_data(data))). Technically you can even provide new code snippets (using one of the mechanisms from #1, or, if opening up an Erlang shell to the running instance, supplying it directly as a lambda), but you'll need to be mindful about persistence. I am not that well versed with workflow engines, but that partly comes from the fact that I haven't really seen the point given how easy many languages make it to create and customize workflows without having to learn special semantics. I am not at all familiar with apache camel, but I think your concerns here aren't easily addressed; certainly, the library support for Erlang/Elixir isn't anywhere close to the JVM. But I -will- mention that sometimes writing the integration(s) you need to enable using a different technology are worth it.
• rishav_sharan 5y ago
  Lots of posts here are talking about Elixir's concurrency and performance, but in benchmarks like techempower, Elixir comes fairly low. Can someone help me rationalize this discrepancy? Also, in general, for a Digital Ocean droplet, how many requests per second (db query based) can Elixir handle while maintaining a sub 200ms latency?
  • jrsj 5y ago
    Well it’s pretty competitive if you limit it to dynamic languages + eliminate some outliers (weird non-Node JS runtimes, web frameworks mostly written in C that happen to be called from Python/PHP, etc)
  • jtwebman 5y ago
    Almost no business application is written for performance at raw request speed. What Elixir brings is far more the that. Watch this if you want to understand why so many people fall in love with it. https://youtu.be/JvBT4XBdoUE https://youtu.be/JvBT4XBdoUE
  • di4na 5y ago
    See my comment at https://news.ycombinator.com/item?id=27685026 https://news.ycombinator.com/item?id=27685026
• leke 5y ago
  > We had two viable choices for the new application that needed to be built---Rails and Phoenix. The team to which we were delivering the project had no Elixir experience at all, so a choice to build a Phoenix app represented a choice to adopt Elixir. *Laravel and all the other PHP frameworks waving their hands frantically... Hello, Hello!
• codeptualize 5y ago
  I find it strange how always the "mainstream" and "not popular enough " arguments comes up in any Elixir related post. Does tech have to be "mainstream" to use it? I would say it doesn't. Take Erlang, or OCaml, or F#, I wouldn't call those mainstream but they are great languages that solve real problems, and people using them seems generally very positive about them. All you need is enough popularity and enough companies using and backing it for it to be maintained. I think Elixir has this. Can't speak to the hiring situation but I wonder how problematic it can be given all the stories of how easy it is to onboard people and plenty of posts and comments of devs wanting to do Elixir. Even if, it depends on your situation, you don't always need a big workforce to do big things, see Whatsapp for example.
  • brightball 5y ago
    FWIW I think that this is because it was the main selling point of adopting Go instead for many companies. I was at a company 6 years ago that was looking at introducing a language with a better concurrency profile. It was between Elixir and Go. Go ended up winning out because “Google makes it more mainstream”. That was the crux of the decision. Don’t get me wrong, Go has plenty of selling points but there were a lot of supporting articles making that claim. Denouncing Elixir as “not mainstream” is probably just a result of the built in defensiveness from people who argued against it for a while. Elixir’s fantastic. It has made me a much better programmer.
  • joelbluminator 5y ago
    I mean being mainstream helps. More blogs, more Stackoverflow answers, more battle tested libraries. A Java or Python business are 100% positive they will find devs 20 years from now and the ecosystem won't die. Php, Go, Ruby? Lets say 80% sure. With Elixir its very hard to say what's going to happen. Its quite possible it will go the way of Perl eventually. I don't know what F# or Ocaml are good for but if you are starting a business you need a pretty compelling reason to use those instead of something mainstream. Being mainstream helps a lot I wouldn't underestimate it.
    • sergiomattei 5y ago
• mouldysammich 5y ago
  I wish there were more roles for elixir newbies/general newbies out there. I've been learning some elixir basics and it seems like itd be a tonne of fun to work with.
• jatins 5y ago
  Folks who have used Elixir in a team environment (as opposed to for personal use), is the lack of types an issue in navigating big/unfamiliar codebases?
  • lawik 5y ago
    Not for me. To be fair I didn't have types in PHP, Python or JS either. I wrote about my onboarding thoughts on Elixir here: https://underjord.io/onboarding-to-elixir.html https://underjord.io/onboarding-to-elixir.html
  • strzibny 5y ago
    No, but I don't come from a typed language. For me, it was an upgrade, because the beautiful docs have type information for most main modules you'll use.
  • aej 5y ago
    I came to Elixir from another untyped language (python) but I've never had any issues. Elixir code often relies heavily on pattern matching return values (ok/error tuples or Structs) so that helps along with typespecs. The fact that the language is compiled is also a big help when it comes to avoiding run-time errors while developing locally. The other thing I appreciate about elixir coming from python (more specifically Django) is that most application-specific code is just modules and functions. There is none of the indirection and abstractions-upon-abstraction I used to have to grok in big python codebases.
  • erinan 5y ago
    I just switched from a Python (with mypy) codebase to a full-time Elixir position a few weeks ago. I thought I'd miss typing but due to the functional nature of Elixir and its pattern-matching, I found out that the code is much simpler to grok. In this case I think that having readable idiomatic code trumps the need for typing. If needed there is type hinting with @spec but it's not used very often (or mostly in libraries?). I can definitely say that it's very fun and productive to work in a Phoenix mono-repo. The development experience is great and I'm really having fun programming again.
  • juhatl 5y ago
• ciconia 5y ago
  Off topic: Am I the only one who finds the stock photos in the article off-putting? They have nothing to do with the subject matter, except in a very indirect, sort-of-metaphorical way. I would take the article much more seriously if they weren't there.
  • LeonidasXIV 5y ago
    One of them is mirrored and the way Canon is unreadable on the camera is vaguely annoying me.
  • leephillips 5y ago
    You’re not alone. Those gratuitous, unimaginative photographs (one mirror-flipped, suggesting obliviousness somewhere in the assembly line process), combined with the prolix, buzzword laden, soggy prose, emit a strong corporate odor that made me want to turn away. Pity, because the core of the content is somewhat interesting.
• aswinmohanme 5y ago
  The best things about Elixir is it's pattern matching and it's inbuilt documentation tool. Each and every document for every package is consistent, which are exploited by the IDE tools for stellar in editor help.