16 ms·

How to sell Elixir again

jeanlucas 3y ago
This is great. I think it's crucial to keep convincing the overall tech community about the good sides of Elixir. And yeah, resilient design de-risks itself and that alone is a huge gain because it also reduces other forms of complexity. Still, I think we have to keep pushing to debunk other myths from "it's impossible to find talent" and the fear of "no one uses" that are common myths about any technology that is not the #1 most used.
- bsaul 3y ago
  Elixir / erlang is not just « not the #1 ». I don’t think it’s even in the top 99% of the programmer’s population commonly used language. once you’ve removed people using c/c++, java / kotlin, dot net, javascript, ruby php and python, you’re left with a really fringe minority of people. And even in that minority, i would say erlang / elixir isn’t even in the top 2 ( my guess go and rust have a much wider audience)
  - radlad 3y ago
    No need to suppose, there are decent sources for this.[1][2] Go seems to be much more popular than you expect. Elixir and Erlang are both pretty obscure. [1] https://survey.stackoverflow.co/2022/#technology-most-popular-technologies https://survey.stackoverflow.co/2022/#technology-most-popula... [2] https://madnight.github.io/githut/#/pull_requests/2023/1 https://madnight.github.io/githut/#/pull_requests/2023/1
    - throwawaymaths 3y ago
      The irony is that for all its obscurity, most startups are using at least one mission critical service that runs on elixir -- slab, pagerduty, elixir, ramp, divvy, discord. brex is probably still half ish elixir, though they claimed to be wanting to replace it with kotlin when they got some new tech leadership. I wonder how that's going. I remember working at a startup where the cto was unsure about putting trust in elixir, claiming it was an "unproven entity". I pointed out to him we used THREE of those services, do if he didn't trust elixir we should probably pivot off of those products.
      - alexgrover 3y ago
        I doubt the reservation is with the language/runtime itself, especially with elixir and the BEAM. More likely, it’s with the maturity of the community. Especially at a small startup, building on elixir even today might still mean having to build things in house you may not in Django/Rails/JS.
        slondr 3y ago
        Phoenix exists, so I don’t think that’s true.
        evadne 3y ago
        Indeed. This was covered later in the article on characteristics that may alter the perception of a high-leverage toolchain… More good & relevant information + libraries -> more acceptance (i.e. my use case is no longer a tech uncertainty) The other thought would be that if you didn’t have to do anything yourself then you must have no moat.
        alexgrover 3y ago
        The moat comment depends on the company, not all or even most businesses depend on actual innovation as their moat. Also, I think we’re agreeing here, but there are a huge set of things that you may need to build an application that aren’t the core value prop of your company. Buying into a more mature ecosystem makes it more likely that you don’t have to build those things and can spend more time on the moat stuff.
        evadne 3y ago
        Indeed, I think you are quite right, and we are in agreement.
        throwawaymaths 3y ago
        I think you are overestimating the intelligence of that CTO
    - parthdesai 3y ago
      It's only obscure professionally; it's also one of the most loved languages. [same survey] https://survey.stackoverflow.co/2022/#most-loved-dreaded-and-wanted-language-love-dread https://survey.stackoverflow.co/2022/#most-loved-dreaded-and...
      - deleted 3y ago
        [deleted]
      - sph 3y ago
        I was surprised to see how low it is on the Want list, even though it's only second to Rust in the Love list. Simply put, many developers don't yet know they're gonna love it!
  - RSHEPP 3y ago
    In the Fintech space and we use Go and Elixir. Seems to be pretty common among other companies. Company is out of Utah. It's pretty easy to find talent for Go and a little more difficult for elixir.
    - iends 3y ago
      Elixir people might cringe but why wouldn’t you just be 100% Go?
      - lawik 3y ago
        Go people might cringe but why wouldn't you just be 100% Rust? Actual response: Some similarities, different goals, different strengths, different abstraction levels. Go is cool I hear but I don't see a need from over here doing Elixir.
      - pg_1234 3y ago
        In a concurrent environment Go is not guaranteed memory safe, leaving you exposed to silent errors of value ... which for Fintech is just suicidal.
      - RSHEPP 3y ago
        Because we live with our past decisions... All new services are in Go. The elixir service serves us well still.
        bsaul 3y ago
        Curious: why did you move from elixir to go ?
      - innocentoldguy 3y ago
        Why not 100% Elixir, since it is more robust and uses less resources?
    - pdimitar 3y ago
      I'm still on a hiatus but if you need a senior Elixir and Rust dev that knows Golang okay, we can chat. 21 years of experience in total, including in C/C++ and Java.
- sph 3y ago
  > it's impossible to find talent It's been 4 months and counting that I've been trying to land an Elixir freelance contract. My theory is that dev. happiness and productivity is so great in Elixir land, there is not much churn, so talent is available, jobs, not so much.
  - 8ytecoder 3y ago
    Reach out to me on my email on HN with your resume/GitHub link.
  - Plasmoid 3y ago
    I submitted a few patches to an elixir project and from that a company reached out to hire me. This was a while ago but I got the feeling that companies were starved for talent.
    - throwawaymaths 3y ago
      It's also hard to get a job as an elixir junior or senior. There is a disconnect and companies are trying to hire by cargo culting things that other startups/faang are doing, and repeatedly turning down perfectly good candidates. Also recruiters don't know how to find/screen elixir devs, etc.
  - napsterbr 3y ago
    (Edited out because I misread the parent comment)
    - pavlov 3y ago
      The GP poster is looking for an Elixir job too.
      - sph 3y ago
        They've put their billboard just next to mine, placing themselves as competition. Not super appreciated in this tight hiring market :-) (j/k, no worries napsterbr)
- scraplab 3y ago
  We use Elixir. Everyone we’ve hired, from junior to principal, has had no previous Elixir experience. They’ve mostly come from Ruby/Rails or JavaScript backgrounds. They’ve become productive in Elixir quickly and once they’ve understood some of the unique patterns and concepts, all thoroughly enjoyed working in it. Of course, those with more experience tend to have heard of Elixir and be keen to work in it. People with less experience are more concerned about whether investing in this language is a good career move, so we emphasise how learning something like Elixir will ultimately make you a more valuable developer. If you’re considering adopting Elixir for your new project/startup and worried about finding talented developers, I don’t think Elixir will make it harder and might even make it easier.
  - deleted 3y ago
    [deleted]
fideloper 3y ago
Elixir is great! BEAM and friends is amazing. I think Elixir/Phoenix could use a little bit of Javascript (and modern PHP) enthusiasm to help with adoption - this all seems a bit…dry.
- DANmode 3y ago
  > lecture.md
- johnisgood 3y ago
  Personally I want to move away from JavaScript and its ecosystem. There is https://hexdocs.pm/phoenix_live_view/js-interop.html https://hexdocs.pm/phoenix_live_view/js-interop.html though. For the record, Phoenix does use JavaScript for its "LiveView"[1], but I think it is optional? At least I remember someone telling me this when I was complaining that generating a basic Phoenix project (using "mix") is too bloated due to JavaScript and such. [1] [...] ./deps/phoenix_live_view/assets/js/phoenix_live_view/view_hook.js ./deps/phoenix_live_reload/priv/static/phoenix_live_reload.js ./assets/package-lock.json ./assets/vendor/topbar.js ./assets/js ./assets/js/app.js [...]
  - elicksaur 3y ago
    It uses websockets, which as I understand it, browsers only allow interfacing with them via JavaScript (at least easily). Is there a tech stack/protocol that gets comparable functionality to websockets but without using JavaScript?
  - evadne 3y ago
    Phoenix LiveView uses JS because the core of the tech requires the server to compute diffs & the client to patch the DOM accordingly. This is why a JS package is needed alongside the other default package from Phoenix, which brings Phoenix Sockets & Channels capability (which builds on top of transports such as Websocket). Previously have seen: https://github.com/patrick-steele-idem/morphdom https://github.com/patrick-steele-idem/morphdom Can check: https://www.npmjs.com/package/phoenix_live_view https://www.npmjs.com/package/phoenix_live_view
nologic01 3y ago
Erlang/elixir have a tremendus story to tell: in a world that digitizes increazingly vital aspects of its core infrastructure the focus on risk management that is in full display in this post is a unique and important aspect. The challenge is the prevalence of hypes, which as pointed out insightfully, can lead to irrational choices.
munchler 3y ago
I've always found myself in fundamental disagreement with the Erlang/Elixir philosophy. Resilience, within the context of this presentation, and the philosophy of Erlang, would be the capability to recover from errors while unattended. I prefer systems that don't fail quite so smoothly. Take this example: The application runs out of memory due to too many transactions being processed at once. The problem happens once every day. However the system gracefully recovers, and the team is able to resolve the issue peacefully without the problem escalating to an active incident. If I was funding development of such a system, I would find this situation unacceptable. I'm paying for an application that doesn't crap out in production every single day, not one that "gracefully recovers" after each such event so the dev team can "peacefully" manage it. The users whose data is lost during these incidents probably wouldn't feel quite so peaceful about it, either.
- draw_down 3y ago
  [dead]
- lobstrosity420 3y ago
  Is your argument that the application gracefully recovering from the scenario will somehow make the dev team accommodated? Hard crashes are not an acceptable substitute for observability, or continuous improvement.
  - munchler 3y ago
    I'm not sure what you mean by "accommodated". This example doesn't even rise to the level of an "active incident" in the Erlang philosophy. In other words, it's not a bug, so there's no urgency to improve it.
    - lobstrosity420 3y ago
      If there is data loss it’s an incident, full stop. Your observability layer should be letting you know.
lbrindze 3y ago
I love Elixir! One of the main reasons I haven’t been able to sell it as much was it’s lack of good numerical computational support, but with the release of nx now getting to a very mature point it’s really hard for me to not get excited about this ecosystem. I also think that livebook has a couple of really killer features now that make anyone who spends a significant amount of their time in Jupyter notebooks to stop and take a second look (eg it’s so easy to share a livebook compared with sharing a jupyter notebook, or even easier to extract code from a livebook prototype to turn into a resilient production elixir module). Yes there is still a ways to go to catch up to the maturity and breadth of the community that Python has in this domain, but that gap is closing way faster than I could have thought. I think the biggest challenge for adoption is its functional nature. If you take the time to learn about elixir and the BEAM you are rewarded with a pretty complete runtime which ships with its own DB, in-memory Store and message queue (with a very easy path to adopting more battle tested versions of these when you outgrow what is included in OTP). This means spin up time prototyping new systems is spent less on vendor choices (which type of DB should I use) and more on solving your problem domain. I wish I had know about all this stuff 5 years ago…
- evadne 3y ago
  Regarding numeric stuff. I discussed this matter with some folks and it was quite interesting because just like Erlang/OTP was used at control plane for phone switches while the data plane was implemented in something else, one could theoretically leverage it to oversee ML processes (perhaps Python programs written with PyTorch or something else) The topology is exactly the same In fact, porting your vetted numeric code to Elixir is probably going to make the risk go sky high, but running the same code with supervision structure in Elixir would in fact reduce risk so is a no-brainer Just my thoughts of course
  - ricketycricket 3y ago
    I do exactly this. Elixir supervises Ports to python and C binaries and manages all the communication between processes including buffering and maintaining state when necessary. Using libraries like Horde even allows you to run these processes on remote nodes very easily. It has worked fantastically well.
max_ 3y ago
Can anyone recommend a good Elixir/Phoenix course?
- RSHEPP 3y ago
  Educative.io seems pretty good. I just use the phoenix docs after understanding some of the core elixir features.
- msie 3y ago
  Phoenixonrails.com
  - arrowsmith 3y ago
    I am the author of this course - thanks, glad you liked it!
    - akudha 3y ago
      Can I follow the course if I haven’t worked with Ruby or RoR?
      - deleted 3y ago
        [deleted]
      - arrowsmith 3y ago
        Maybe, but I don't guarantee it. You're not the target audience.
- jnsaff2 3y ago
  For someone completely new to development Dockyard academy course resources [0] are open source and an excellent showcase for livebook. For an experienced dev wanting to pick up Elixir I would suggest picking up Elixir in Action [1]. The third edition is currently in MEAP. Much more concise and great discussion of some Erlang/OTP internals too. [0] https://github.com/DockYard-Academy/curriculum https://github.com/DockYard-Academy/curriculum [1] https://www.manning.com/books/elixir-in-action-third-edition https://www.manning.com/books/elixir-in-action-third-edition
revskill 3y ago
LiveView techs is kinda of the end story to get more adoption for Frontend Techs i think.
toastal 3y ago
Is the author sure they want to embed this lecture/blog post into a proprietary serivce’s UI?
- kpw94 3y ago
  It's better to focus on the content than the medium (pun intended, as usually this kind of comment are usually when people post something on medium, as if they didn't have another copy of their post backed-up somewhere else.) But I'll bite: What's wrong exactly with using Github's markdown renderer? This is a plain markdown file, the author could host it on S3 and it'd look like: https://gist.githubusercontent.com/evadne/c9aeca424d30f024ba048158bcad385f/raw/3bb733d248f4d95551a5b7c079bd64efb443282a/lecture.md https://gist.githubusercontent.com/evadne/c9aeca424d30f024ba... There are a ton of markdown renderers, author could write one in a few hours for the feature used (#, ##, ###, >, and unordered lists), or even better, paste the thing in one of the many markdown-to-html tools (https://markdowntohtml.com/ https://markdowntohtml.com/). This is not like the author used some proprietary syntax, that only displays on Github.
  - toastal 3y ago
    The author isn't in control of the chrome around it. It becomes an advertisement for the proprietary service. You can slap Markdown through Pandoc and host statically somewhere where you do control the the chrome. This is a similar objection to say Medium, but Medium authors aren't usually developers and don't have the know-how. GitHub has forked Markdown in a way that is incompatible with CommonMark, GitLab, etc. So the author might accidentally buy into that fork which there is no quality control for (just look at the lack of care put into their attempt at admonitions).
- evadne 3y ago
  I’m fine with it You can share it elsewhere if like
jononomo 3y ago
People say it is hard to find talented Elixir developers, but I know of two people who would love to jump ship to work with Elixir. Also, I think the BEAM is the most sensible platform for the modern web, and it puzzles me a bit that it is not more widely adopted.
killthebuddha 3y ago
I love elixir, but I feel like there’s something off about the focus on reliability and error handling. At least for web applications, it’s pretty boring the idea that a single error won’t take down the entire system. At worst, a single error might take down an entire process, but that’s really not that terrible. Also, error handling code that is not colocated with the logic that threw seems like a mess. Error handlers have to decide whether we can recover and whether we need to report the problem, and that doesn’t really change just because an error won’t bork an entire system. IME error handling is mostly about deciding what is best for the user. What I love most about elixir is the ridiculously dead-simple vertical scaling. A close second is The World’s Best Take On ORMs (aka Ecto).
- Jtsummers 3y ago
  Do you mean horizontal scaling? Throwing more machines and cores at your system and distributing work across additional nodes?
  - ricketycricket 3y ago
    Both vertical and horizontal are pretty simple with Elixir and are done in essentially the same way.
    - Jtsummers 3y ago
      Almost every system scales simply vertically, vertical scaling is (to a first approximation) throwing faster hardware at the problem. If you're IO bound you get a faster IO bus (this is not necessarily easy to do, but if you do it the system scales to the limit of it). If you're CPU bound you get a faster CPU. And so on. Horizontal scaling is what's hard for a lot of systems, but simple with Erlang and Elixir since they are, by design, meant to support concurrent and distributed workloads. That's why I was asking if they meant horizontal and not vertical. Erlang and Elixir are not uniquely easy to scale horizontally, but they are (if you don't fight their nature and produce programs that consist of one giant execution thread) ridiculously easy to scale horizontally by tacking on additional CPU cores or physical CPUs.
darkmarmot 3y ago
We sold it to our Fortune 100. Our Elixir application tracks a fair percentage of healthcare patients across the US in real-time, can handle loss of systems or data centers with zero downtime, data loss or interruption and we update it live. https://www.erlang-solutions.com/blog/how-hca-healthcare-used-the-beam-to-fight-covid-code-beam-v-talk-review/ https://www.erlang-solutions.com/blog/how-hca-healthcare-use...
datadeft 3y ago
I just implemented a trading system in Elixir with backend + JS free frontend and I have to admit that this was the most pleasant experience for a long time. I think pattern matching and the pipe operator combined with the let it crash approach work very well in practice. There are amazing libraries for Erlang/Elixir including database client, dataframes, JWT, http, AMQP client and many more. I haven't had a single library that was not working out of the box the way we wanted. The code is pretty easy to follow and we can onboard a new engineer with ease. The usual ration for our codebase comparing to Python is 1:10 in favour of Elixir. The engineers on the team have 10+ years Python experience and only used Elixir for toy project before.
einpoklum 3y ago
I'm commenting from the perspective of someone with zero experience with Elixir and Erlang. I've heard of them, but not used them. So, I leafed through this document, and did not see how it would help people sell Elixir. Engineers will not be offered reasons to prefer it to other languages (popular or otherwise), and managers / bean-counters will not be convinced by the claims of it being less risky and a robust choice for a glue language - when very few people know it, so maintaining the elixir code will depend on some local guru and/or training people to use elixir. ... and this all is not to disparage Elixir! I just don't feel I've been told almost anything about it.
- di4na 3y ago
  This was written to talk to people already in the community, as a way to explain the current situation. It was not targeted at external people that discovers it. We do have multiple other places for that if you are interested though :)
hmmokidk 3y ago
Using Node.js again instead of my usual Elixir and all I can think is "Y'all live like this?". I feel for anyone using a Node.js backend. Y'all really don't know what you're missing. Also dealing with bugs is infinitely harder. Try catch is infinitely more wordy and messy. And you lose out on so so many valuable CI steps the Elixir community has from sobelow to credo. And then there's writing tests. In the Node.js community it is an actual joke. It is so hard to write tests and I have yet to see any framework create a nice sandboxed test environment that just works. All of this stuff in Elixir is free. And like someone else said, the best ORM is Ecto and it's hard to disagree with that. Making a reliable and organized Node.js application is actually so difficult. If my pet project was in Node.js I would not even be able to accomplish it. And that's a fact. Elixir makes me so much more productive and the code I write is so much less buggy and less complex. I love that HN loves Elixir. If only it was more common in the workplace.
- izelnakri 3y ago
  I so far agree with all you said and strong think already based on limited info available to me that you are a well-versed Elixir dev. However nothing beats the short term dev speed of scripting up some JS with npm. Have you seen the latest test runner efforts on node.js and advancements in deno? I think this gap is slowly closing but node is still not near Elixir in terms of long-term productivity, in future it will take over though I think if types dont get into the Elixir language fast.
  - hmmokidk 3y ago
    I have to transpile my scripts if I want to copy-paste which I often need to do. And there's no repl if you're using transpiled code. I have tried using `ts-node` but that didn't work. In Elixir this stuff just works. Maybe there's some tooling I am missing out on with Node.js. I am not familiar with Deno.
- revskill 3y ago
  Use a real NodeJS framework then. Also nowadays it's Typescript tooling that gave superpower to NodeJS backend.
strzibny 3y ago
I get an Elixir job offer on LinkedIn at least every two weeks. It's niche but if you want to work with it, recruiters will find you. If you already work with Elixir, I have couple of posts that might be helpful[0]. [0] https://nts.strzibny.name/tag/elixir/ https://nts.strzibny.name/tag/elixir/
- Existenceblinks 3y ago
  I bet you are in US or EU.
  - colecut 3y ago
    That would often be a safe bet here
Dowwie 3y ago
> The community has proven to be sustainable, with ample social proof of further adoption and conditions amenable to generational succession It depends on how you measure sustainable. What would happen to Elixir without its BDFL? Has Elixir achieved escape velocity and will continue? Rust was pushed out of the Mozilla nest and managed to live on. I don't see a similar capacity for Elixir handling such existential risk. Are there succession plans? Is there mentoring among members of the core? I also think that it's necessary to point out that just because OTP facilitates resilience doesn't mean that the system you'll build with it will exhibit that behavior. You have to design your system to use OTP effectively. Easier said than done. I've seen Elixir systems reach a critical failure state following maximum restarts of its internal processes. However, at least Elixir has the potential of being hardened. It's just not going to act as expected without a lot of up front wisdom applied.
- evadne 3y ago
  Agreed. There is no alternative to thinking. However a good collection of conventions, primitives & building blocks, can assist greatly in architecting a robust system. We do test systems to the point of breakage. It is not something we skip just because the language is good. As to existential risk: I will try to be succinct. If there has been no exposure then there is no need to hedge. Further, there are commercial firms which will maintain your critical systems. In other words, a long term maintenance contract for Elixir systems can be procured from more than one source.
wnevets 3y ago
Elixir is great if you want the burden of using types without the actual benefits!
hannofcart 3y ago
Question for anyone who has switched to Elixir from a typesafe language: doesn't the lack of complile time type checking bother people working on Elixir? Any opinions on that?
- Dowwie 3y ago
  Yes, and typespecs are worse to debug than anything the borrow checker may complain about in Rust. Public api does benefit by exposing them, though.
- plumeria 3y ago
  If you want a type-safe language in the BEAM ecosystem, check out Gleam [0] [0] https://gleam.run/ https://gleam.run/
- mrjoelkemp 3y ago
  Not really. Working on a 2+ year, large, monolithic phoenix liveview app at Spotify. VS Code runs dialyzer on file save, which shows type mismatches. I also run dialyzer on pre-commit for a sweeping check. Ideally, we'd have the same optional typing flexibility with a compile time check, but it seems like a marginal gain over the current setup.
- lawn 3y ago
  My favorite languages are Rust and Elixir, and yes the lack of static types is my one gripe with Elixir. It's a little bit better than what it might look like on the surface level as you do a lot of pattern matching and dialyzer. It's far from what you get from Rust of course, but it's better than with Python for instance.
- creakingstairs 3y ago
  Yes it is the only thing that really bothers me about Elixir. In my personal projects, I heavily utilise typespecs which makes it somewhat bearable. But in my previous day job that had a high turnover rate (and hence a huge mess) doing any refactoring on the Elixir codebase was a nightmare even with tests. I found maintaining the Typescript codebase in the same company much easier.
_virtu 3y ago
Worked at a startup for the last nine months as a founding engineer building everything in Elixir + Phoenix and LiveView. I was able to ship more features and fix more problems faster than I ever have. The startup is out of runway and it breaks my heart to think I might have to go back to the painful world of node.js.

This is great. I think it's crucial to keep convincing the overall tech community about the good sides of Elixir. And yeah, resilient design de-risks itself and that alone is a huge gain because it also reduces other forms of complexity. Still, I think we have to keep pushing to debunk other myths from "it's impossible to find talent" and the fear of "no one uses" that are common myths about any technology that is not the #1 most used.

bsaul 3y ago
Elixir / erlang is not just « not the #1 ». I don’t think it’s even in the top 99% of the programmer’s population commonly used language. once you’ve removed people using c/c++, java / kotlin, dot net, javascript, ruby php and python, you’re left with a really fringe minority of people. And even in that minority, i would say erlang / elixir isn’t even in the top 2 ( my guess go and rust have a much wider audience)
- radlad 3y ago
  No need to suppose, there are decent sources for this.[1][2] Go seems to be much more popular than you expect. Elixir and Erlang are both pretty obscure. [1] https://survey.stackoverflow.co/2022/#technology-most-popular-technologies https://survey.stackoverflow.co/2022/#technology-most-popula... [2] https://madnight.github.io/githut/#/pull_requests/2023/1 https://madnight.github.io/githut/#/pull_requests/2023/1
  - throwawaymaths 3y ago
    The irony is that for all its obscurity, most startups are using at least one mission critical service that runs on elixir -- slab, pagerduty, elixir, ramp, divvy, discord. brex is probably still half ish elixir, though they claimed to be wanting to replace it with kotlin when they got some new tech leadership. I wonder how that's going. I remember working at a startup where the cto was unsure about putting trust in elixir, claiming it was an "unproven entity". I pointed out to him we used THREE of those services, do if he didn't trust elixir we should probably pivot off of those products.
    - alexgrover 3y ago
      I doubt the reservation is with the language/runtime itself, especially with elixir and the BEAM. More likely, it’s with the maturity of the community. Especially at a small startup, building on elixir even today might still mean having to build things in house you may not in Django/Rails/JS.
      - slondr 3y ago
        Phoenix exists, so I don’t think that’s true.
      - evadne 3y ago
        Indeed. This was covered later in the article on characteristics that may alter the perception of a high-leverage toolchain… More good & relevant information + libraries -> more acceptance (i.e. my use case is no longer a tech uncertainty) The other thought would be that if you didn’t have to do anything yourself then you must have no moat.
        alexgrover 3y ago
        The moat comment depends on the company, not all or even most businesses depend on actual innovation as their moat. Also, I think we’re agreeing here, but there are a huge set of things that you may need to build an application that aren’t the core value prop of your company. Buying into a more mature ecosystem makes it more likely that you don’t have to build those things and can spend more time on the moat stuff.
        evadne 3y ago
        Indeed, I think you are quite right, and we are in agreement.
      - throwawaymaths 3y ago
        I think you are overestimating the intelligence of that CTO
  - parthdesai 3y ago
    It's only obscure professionally; it's also one of the most loved languages. [same survey] https://survey.stackoverflow.co/2022/#most-loved-dreaded-and-wanted-language-love-dread https://survey.stackoverflow.co/2022/#most-loved-dreaded-and...
    - deleted 3y ago
      [deleted]
    - sph 3y ago
      I was surprised to see how low it is on the Want list, even though it's only second to Rust in the Love list. Simply put, many developers don't yet know they're gonna love it!
- RSHEPP 3y ago
  In the Fintech space and we use Go and Elixir. Seems to be pretty common among other companies. Company is out of Utah. It's pretty easy to find talent for Go and a little more difficult for elixir.
  - iends 3y ago
    Elixir people might cringe but why wouldn’t you just be 100% Go?
    - lawik 3y ago
      Go people might cringe but why wouldn't you just be 100% Rust? Actual response: Some similarities, different goals, different strengths, different abstraction levels. Go is cool I hear but I don't see a need from over here doing Elixir.
    - pg_1234 3y ago
      In a concurrent environment Go is not guaranteed memory safe, leaving you exposed to silent errors of value ... which for Fintech is just suicidal.
    - RSHEPP 3y ago
      Because we live with our past decisions... All new services are in Go. The elixir service serves us well still.
      - bsaul 3y ago
        Curious: why did you move from elixir to go ?
    - innocentoldguy 3y ago
      Why not 100% Elixir, since it is more robust and uses less resources?
  - pdimitar 3y ago
    I'm still on a hiatus but if you need a senior Elixir and Rust dev that knows Golang okay, we can chat. 21 years of experience in total, including in C/C++ and Java.
sph 3y ago
> it's impossible to find talent It's been 4 months and counting that I've been trying to land an Elixir freelance contract. My theory is that dev. happiness and productivity is so great in Elixir land, there is not much churn, so talent is available, jobs, not so much.
- 8ytecoder 3y ago
  Reach out to me on my email on HN with your resume/GitHub link.
- Plasmoid 3y ago
  I submitted a few patches to an elixir project and from that a company reached out to hire me. This was a while ago but I got the feeling that companies were starved for talent.
  - throwawaymaths 3y ago
    It's also hard to get a job as an elixir junior or senior. There is a disconnect and companies are trying to hire by cargo culting things that other startups/faang are doing, and repeatedly turning down perfectly good candidates. Also recruiters don't know how to find/screen elixir devs, etc.
- napsterbr 3y ago
  (Edited out because I misread the parent comment)
  - pavlov 3y ago
    The GP poster is looking for an Elixir job too.
    - sph 3y ago
      They've put their billboard just next to mine, placing themselves as competition. Not super appreciated in this tight hiring market :-) (j/k, no worries napsterbr)
scraplab 3y ago
We use Elixir. Everyone we’ve hired, from junior to principal, has had no previous Elixir experience. They’ve mostly come from Ruby/Rails or JavaScript backgrounds. They’ve become productive in Elixir quickly and once they’ve understood some of the unique patterns and concepts, all thoroughly enjoyed working in it. Of course, those with more experience tend to have heard of Elixir and be keen to work in it. People with less experience are more concerned about whether investing in this language is a good career move, so we emphasise how learning something like Elixir will ultimately make you a more valuable developer. If you’re considering adopting Elixir for your new project/startup and worried about finding talented developers, I don’t think Elixir will make it harder and might even make it easier.
- deleted 3y ago
  [deleted]

fideloper 3y ago

Elixir is great! BEAM and friends is amazing. I think Elixir/Phoenix could use a little bit of Javascript (and modern PHP) enthusiasm to help with adoption - this all seems a bit…dry.

DANmode 3y ago
> lecture.md
johnisgood 3y ago
Personally I want to move away from JavaScript and its ecosystem. There is https://hexdocs.pm/phoenix_live_view/js-interop.html https://hexdocs.pm/phoenix_live_view/js-interop.html though. For the record, Phoenix does use JavaScript for its "LiveView"[1], but I think it is optional? At least I remember someone telling me this when I was complaining that generating a basic Phoenix project (using "mix") is too bloated due to JavaScript and such. [1] [...] ./deps/phoenix_live_view/assets/js/phoenix_live_view/view_hook.js ./deps/phoenix_live_reload/priv/static/phoenix_live_reload.js ./assets/package-lock.json ./assets/vendor/topbar.js ./assets/js ./assets/js/app.js [...]
- elicksaur 3y ago
  It uses websockets, which as I understand it, browsers only allow interfacing with them via JavaScript (at least easily). Is there a tech stack/protocol that gets comparable functionality to websockets but without using JavaScript?
- evadne 3y ago
  Phoenix LiveView uses JS because the core of the tech requires the server to compute diffs & the client to patch the DOM accordingly. This is why a JS package is needed alongside the other default package from Phoenix, which brings Phoenix Sockets & Channels capability (which builds on top of transports such as Websocket). Previously have seen: https://github.com/patrick-steele-idem/morphdom https://github.com/patrick-steele-idem/morphdom Can check: https://www.npmjs.com/package/phoenix_live_view https://www.npmjs.com/package/phoenix_live_view

nologic01 3y ago

Erlang/elixir have a tremendus story to tell: in a world that digitizes increazingly vital aspects of its core infrastructure the focus on risk management that is in full display in this post is a unique and important aspect. The challenge is the prevalence of hypes, which as pointed out insightfully, can lead to irrational choices.

munchler 3y ago

I've always found myself in fundamental disagreement with the Erlang/Elixir philosophy. Resilience, within the context of this presentation, and the philosophy of Erlang, would be the capability to recover from errors while unattended. I prefer systems that don't fail quite so smoothly. Take this example: The application runs out of memory due to too many transactions being processed at once. The problem happens once every day. However the system gracefully recovers, and the team is able to resolve the issue peacefully without the problem escalating to an active incident. If I was funding development of such a system, I would find this situation unacceptable. I'm paying for an application that doesn't crap out in production every single day, not one that "gracefully recovers" after each such event so the dev team can "peacefully" manage it. The users whose data is lost during these incidents probably wouldn't feel quite so peaceful about it, either.

draw_down 3y ago
[dead]
lobstrosity420 3y ago
Is your argument that the application gracefully recovering from the scenario will somehow make the dev team accommodated? Hard crashes are not an acceptable substitute for observability, or continuous improvement.
- munchler 3y ago
  I'm not sure what you mean by "accommodated". This example doesn't even rise to the level of an "active incident" in the Erlang philosophy. In other words, it's not a bug, so there's no urgency to improve it.
  - lobstrosity420 3y ago
    If there is data loss it’s an incident, full stop. Your observability layer should be letting you know.

lbrindze 3y ago

I love Elixir! One of the main reasons I haven’t been able to sell it as much was it’s lack of good numerical computational support, but with the release of nx now getting to a very mature point it’s really hard for me to not get excited about this ecosystem. I also think that livebook has a couple of really killer features now that make anyone who spends a significant amount of their time in Jupyter notebooks to stop and take a second look (eg it’s so easy to share a livebook compared with sharing a jupyter notebook, or even easier to extract code from a livebook prototype to turn into a resilient production elixir module). Yes there is still a ways to go to catch up to the maturity and breadth of the community that Python has in this domain, but that gap is closing way faster than I could have thought. I think the biggest challenge for adoption is its functional nature. If you take the time to learn about elixir and the BEAM you are rewarded with a pretty complete runtime which ships with its own DB, in-memory Store and message queue (with a very easy path to adopting more battle tested versions of these when you outgrow what is included in OTP). This means spin up time prototyping new systems is spent less on vendor choices (which type of DB should I use) and more on solving your problem domain. I wish I had know about all this stuff 5 years ago…

evadne 3y ago
Regarding numeric stuff. I discussed this matter with some folks and it was quite interesting because just like Erlang/OTP was used at control plane for phone switches while the data plane was implemented in something else, one could theoretically leverage it to oversee ML processes (perhaps Python programs written with PyTorch or something else) The topology is exactly the same In fact, porting your vetted numeric code to Elixir is probably going to make the risk go sky high, but running the same code with supervision structure in Elixir would in fact reduce risk so is a no-brainer Just my thoughts of course
- ricketycricket 3y ago
  I do exactly this. Elixir supervises Ports to python and C binaries and manages all the communication between processes including buffering and maintaining state when necessary. Using libraries like Horde even allows you to run these processes on remote nodes very easily. It has worked fantastically well.

max_ 3y ago

Can anyone recommend a good Elixir/Phoenix course?

RSHEPP 3y ago
Educative.io seems pretty good. I just use the phoenix docs after understanding some of the core elixir features.
msie 3y ago
Phoenixonrails.com
- arrowsmith 3y ago
  I am the author of this course - thanks, glad you liked it!
  - akudha 3y ago
    Can I follow the course if I haven’t worked with Ruby or RoR?
    - deleted 3y ago
      [deleted]
    - arrowsmith 3y ago
      Maybe, but I don't guarantee it. You're not the target audience.
jnsaff2 3y ago
For someone completely new to development Dockyard academy course resources [0] are open source and an excellent showcase for livebook. For an experienced dev wanting to pick up Elixir I would suggest picking up Elixir in Action [1]. The third edition is currently in MEAP. Much more concise and great discussion of some Erlang/OTP internals too. [0] https://github.com/DockYard-Academy/curriculum https://github.com/DockYard-Academy/curriculum [1] https://www.manning.com/books/elixir-in-action-third-edition https://www.manning.com/books/elixir-in-action-third-edition

revskill 3y ago

LiveView techs is kinda of the end story to get more adoption for Frontend Techs i think.

toastal 3y ago

Is the author sure they want to embed this lecture/blog post into a proprietary serivce’s UI?

kpw94 3y ago
It's better to focus on the content than the medium (pun intended, as usually this kind of comment are usually when people post something on medium, as if they didn't have another copy of their post backed-up somewhere else.) But I'll bite: What's wrong exactly with using Github's markdown renderer? This is a plain markdown file, the author could host it on S3 and it'd look like: https://gist.githubusercontent.com/evadne/c9aeca424d30f024ba048158bcad385f/raw/3bb733d248f4d95551a5b7c079bd64efb443282a/lecture.md https://gist.githubusercontent.com/evadne/c9aeca424d30f024ba... There are a ton of markdown renderers, author could write one in a few hours for the feature used (#, ##, ###, >, and unordered lists), or even better, paste the thing in one of the many markdown-to-html tools (https://markdowntohtml.com/ https://markdowntohtml.com/). This is not like the author used some proprietary syntax, that only displays on Github.
- toastal 3y ago
  The author isn't in control of the chrome around it. It becomes an advertisement for the proprietary service. You can slap Markdown through Pandoc and host statically somewhere where you do control the the chrome. This is a similar objection to say Medium, but Medium authors aren't usually developers and don't have the know-how. GitHub has forked Markdown in a way that is incompatible with CommonMark, GitLab, etc. So the author might accidentally buy into that fork which there is no quality control for (just look at the lack of care put into their attempt at admonitions).
evadne 3y ago
I’m fine with it You can share it elsewhere if like

jononomo 3y ago

People say it is hard to find talented Elixir developers, but I know of two people who would love to jump ship to work with Elixir. Also, I think the BEAM is the most sensible platform for the modern web, and it puzzles me a bit that it is not more widely adopted.

killthebuddha 3y ago

I love elixir, but I feel like there’s something off about the focus on reliability and error handling. At least for web applications, it’s pretty boring the idea that a single error won’t take down the entire system. At worst, a single error might take down an entire process, but that’s really not that terrible. Also, error handling code that is not colocated with the logic that threw seems like a mess. Error handlers have to decide whether we can recover and whether we need to report the problem, and that doesn’t really change just because an error won’t bork an entire system. IME error handling is mostly about deciding what is best for the user. What I love most about elixir is the ridiculously dead-simple vertical scaling. A close second is The World’s Best Take On ORMs (aka Ecto).

Jtsummers 3y ago
Do you mean horizontal scaling? Throwing more machines and cores at your system and distributing work across additional nodes?
- ricketycricket 3y ago
  Both vertical and horizontal are pretty simple with Elixir and are done in essentially the same way.
  - Jtsummers 3y ago
    Almost every system scales simply vertically, vertical scaling is (to a first approximation) throwing faster hardware at the problem. If you're IO bound you get a faster IO bus (this is not necessarily easy to do, but if you do it the system scales to the limit of it). If you're CPU bound you get a faster CPU. And so on. Horizontal scaling is what's hard for a lot of systems, but simple with Erlang and Elixir since they are, by design, meant to support concurrent and distributed workloads. That's why I was asking if they meant horizontal and not vertical. Erlang and Elixir are not uniquely easy to scale horizontally, but they are (if you don't fight their nature and produce programs that consist of one giant execution thread) ridiculously easy to scale horizontally by tacking on additional CPU cores or physical CPUs.

darkmarmot 3y ago

We sold it to our Fortune 100. Our Elixir application tracks a fair percentage of healthcare patients across the US in real-time, can handle loss of systems or data centers with zero downtime, data loss or interruption and we update it live. https://www.erlang-solutions.com/blog/how-hca-healthcare-used-the-beam-to-fight-covid-code-beam-v-talk-review/ https://www.erlang-solutions.com/blog/how-hca-healthcare-use...

datadeft 3y ago

I just implemented a trading system in Elixir with backend + JS free frontend and I have to admit that this was the most pleasant experience for a long time. I think pattern matching and the pipe operator combined with the let it crash approach work very well in practice. There are amazing libraries for Erlang/Elixir including database client, dataframes, JWT, http, AMQP client and many more. I haven't had a single library that was not working out of the box the way we wanted. The code is pretty easy to follow and we can onboard a new engineer with ease. The usual ration for our codebase comparing to Python is 1:10 in favour of Elixir. The engineers on the team have 10+ years Python experience and only used Elixir for toy project before.

einpoklum 3y ago

I'm commenting from the perspective of someone with zero experience with Elixir and Erlang. I've heard of them, but not used them. So, I leafed through this document, and did not see how it would help people sell Elixir. Engineers will not be offered reasons to prefer it to other languages (popular or otherwise), and managers / bean-counters will not be convinced by the claims of it being less risky and a robust choice for a glue language - when very few people know it, so maintaining the elixir code will depend on some local guru and/or training people to use elixir. ... and this all is not to disparage Elixir! I just don't feel I've been told almost anything about it.

di4na 3y ago
This was written to talk to people already in the community, as a way to explain the current situation. It was not targeted at external people that discovers it. We do have multiple other places for that if you are interested though :)

hmmokidk 3y ago

Using Node.js again instead of my usual Elixir and all I can think is "Y'all live like this?". I feel for anyone using a Node.js backend. Y'all really don't know what you're missing. Also dealing with bugs is infinitely harder. Try catch is infinitely more wordy and messy. And you lose out on so so many valuable CI steps the Elixir community has from sobelow to credo. And then there's writing tests. In the Node.js community it is an actual joke. It is so hard to write tests and I have yet to see any framework create a nice sandboxed test environment that just works. All of this stuff in Elixir is free. And like someone else said, the best ORM is Ecto and it's hard to disagree with that. Making a reliable and organized Node.js application is actually so difficult. If my pet project was in Node.js I would not even be able to accomplish it. And that's a fact. Elixir makes me so much more productive and the code I write is so much less buggy and less complex. I love that HN loves Elixir. If only it was more common in the workplace.

izelnakri 3y ago
I so far agree with all you said and strong think already based on limited info available to me that you are a well-versed Elixir dev. However nothing beats the short term dev speed of scripting up some JS with npm. Have you seen the latest test runner efforts on node.js and advancements in deno? I think this gap is slowly closing but node is still not near Elixir in terms of long-term productivity, in future it will take over though I think if types dont get into the Elixir language fast.
- hmmokidk 3y ago
  I have to transpile my scripts if I want to copy-paste which I often need to do. And there's no repl if you're using transpiled code. I have tried using `ts-node` but that didn't work. In Elixir this stuff just works. Maybe there's some tooling I am missing out on with Node.js. I am not familiar with Deno.
revskill 3y ago
Use a real NodeJS framework then. Also nowadays it's Typescript tooling that gave superpower to NodeJS backend.

strzibny 3y ago

I get an Elixir job offer on LinkedIn at least every two weeks. It's niche but if you want to work with it, recruiters will find you. If you already work with Elixir, I have couple of posts that might be helpful[0]. [0] https://nts.strzibny.name/tag/elixir/ https://nts.strzibny.name/tag/elixir/

Existenceblinks 3y ago
I bet you are in US or EU.
- colecut 3y ago
  That would often be a safe bet here

Dowwie 3y ago

> The community has proven to be sustainable, with ample social proof of further adoption and conditions amenable to generational succession It depends on how you measure sustainable. What would happen to Elixir without its BDFL? Has Elixir achieved escape velocity and will continue? Rust was pushed out of the Mozilla nest and managed to live on. I don't see a similar capacity for Elixir handling such existential risk. Are there succession plans? Is there mentoring among members of the core? I also think that it's necessary to point out that just because OTP facilitates resilience doesn't mean that the system you'll build with it will exhibit that behavior. You have to design your system to use OTP effectively. Easier said than done. I've seen Elixir systems reach a critical failure state following maximum restarts of its internal processes. However, at least Elixir has the potential of being hardened. It's just not going to act as expected without a lot of up front wisdom applied.

evadne 3y ago
Agreed. There is no alternative to thinking. However a good collection of conventions, primitives & building blocks, can assist greatly in architecting a robust system. We do test systems to the point of breakage. It is not something we skip just because the language is good. As to existential risk: I will try to be succinct. If there has been no exposure then there is no need to hedge. Further, there are commercial firms which will maintain your critical systems. In other words, a long term maintenance contract for Elixir systems can be procured from more than one source.

wnevets 3y ago

Elixir is great if you want the burden of using types without the actual benefits!

hannofcart 3y ago

Question for anyone who has switched to Elixir from a typesafe language: doesn't the lack of complile time type checking bother people working on Elixir? Any opinions on that?

Dowwie 3y ago
Yes, and typespecs are worse to debug than anything the borrow checker may complain about in Rust. Public api does benefit by exposing them, though.
plumeria 3y ago
If you want a type-safe language in the BEAM ecosystem, check out Gleam [0] [0] https://gleam.run/ https://gleam.run/
mrjoelkemp 3y ago
Not really. Working on a 2+ year, large, monolithic phoenix liveview app at Spotify. VS Code runs dialyzer on file save, which shows type mismatches. I also run dialyzer on pre-commit for a sweeping check. Ideally, we'd have the same optional typing flexibility with a compile time check, but it seems like a marginal gain over the current setup.
lawn 3y ago
My favorite languages are Rust and Elixir, and yes the lack of static types is my one gripe with Elixir. It's a little bit better than what it might look like on the surface level as you do a lot of pattern matching and dialyzer. It's far from what you get from Rust of course, but it's better than with Python for instance.
creakingstairs 3y ago
Yes it is the only thing that really bothers me about Elixir. In my personal projects, I heavily utilise typespecs which makes it somewhat bearable. But in my previous day job that had a high turnover rate (and hence a huge mess) doing any refactoring on the Elixir codebase was a nightmare even with tests. I found maintaining the Typescript codebase in the same company much easier.

_virtu 3y ago

Worked at a startup for the last nine months as a founding engineer building everything in Elixir + Phoenix and LiveView. I was able to ship more features and fix more problems faster than I ever have. The startup is out of runway and it breaks my heart to think I might have to go back to the painful world of node.js.