17 ms·

Switching to Elixir

336 points by orlandohill 3y ago

gaws 3y ago
> A few months ago I started a new job at a company that uses Elixir as its main language on the backend. > I've never written a line of Elixir or Erlang before in my life Isn't this a red flag to the recruiters and hiring managers?
whalesalad 3y ago
The true power of Elixir comes from processes and OTP.
- davidw 3y ago
  Yep. A lot of these intro things aren't really selling me on how they're using the big features of the BEAM system as an advantage.
jononomo 3y ago
I love Elixir.
hbcondo714 3y ago
> Elixir's |>, and it inserts the result of the previous expression into the first argument of the next function I found this convenient while writing my first Elixir app with Phoenix Liveview: https://github.com/hbcondo/last10k_liveview https://github.com/hbcondo/last10k_liveview
isodev 3y ago
I only learned about Elixir a little more than a year ago and it’s been a lot of fun to learn and incorporate in different components. My biggest joy comes from how much one can do out of the box with beam/otp. Someone in a team I worked with once said “BEAM/OTP is like k8s only without the complicated parts”.
- bananadonkey 3y ago
  When all else fails that's how I explain it to my team. I spent years learning Elixir but unfortunately the benefits were somewhat undermined by the recent migration to OpenShift (k8s) I had just architected. It would have been a much more tantalizing proposition if k8s was not in the picture; instead we kept our existing dev stack and utilized k8s concepts to achieve what we would have been doing in OTP, with different trade-offs of course.
alskdj21 3y ago
Sasa Juric's The Soul of Erlang and Elixir talk[1] showcases how powerful the language can be. [1] https://www.youtube.com/watch?v=JvBT4XBdoUE&t=4 https://www.youtube.com/watch?v=JvBT4XBdoUE&t=4
- ZeroMcMuffin 3y ago
  As someone curious about Elixir, I watched this talk earlier this week. I highly recommend it to anyone who has heard all of the "let it fail" and "BEAM does concurrency right" talk, but still doesn't grasp it. It is an incredible talk.
andsbf 3y ago
`...If you call model.update(params) in Ruby, then it returns false if it fails and updates model.errors with what went wrong. Mutable state.` This is Rails stuff, not Ruby
- krainboltgreene 3y ago
  True, you could implement Ecto exactly in Ruby, except you'd be writing effectively Elixir and every library released that got close to this in the 15 years I've been doing Ruby has been either disliked or disregarded. Each with less contributor activity in their lifespan than a month of ActiveRecord attention.
- ljm 3y ago
  Yeah, the example is Rails-specific but Ruby is full of methods that mutate existing state. Most of the time they're marked with `!` at the end, but not always.
cheema33 3y ago
How do people switch programming languages? Established languages have massive ecosystems. Large set of libraries. For example, I cannot give up MS Entity Framework Core or Hot Chocolate graphql server for C#. Sure, there are alternatives, but nothing as feature complete. Perhaps it is possible for applications that have small set of requirements.
- whalesalad 3y ago
  Elixir and Erlang are very well established ecosystems.
- qaq 3y ago
  Erlang is fairly established 37 years young language and Elixir got to build on top of Erlang ecosystem.
- john-radio 3y ago
  > Perhaps it is possible for applications that have small set of requirements. Well, for existing applications it is extremely difficult, not because Elixir lacks many important features that C# delivers (although I'm sure it does lack some, and vice versa in a big way), but more just because rebuilding any project that's had hundreds or thousands of person-hours poured into it, that's currently satisfying hundreds or thousands of business requirements which may or may not be documented, is a huge project with few rewards; the investment is huge and the return on investment is... I mean, being on {sexy new language} is nice, but nobody's paying you for that. But that's not what the OP's job is talking about. They just got a different job using Elixir, and are learning the technologies the same way anyone else does, and they're excited about this instance of it enough to write about it.
- bradteamworks 3y ago
  I used C# before using Elixir. I also thought Entity was awesome. But Ecto and Absinthe are even better from my perspective.
- h0l0cube 3y ago
  > MS Entity Framework Core Having worked with both EF Core and Ecto, I would gladly see the back of EF Core. Ecto is flexible enough to basically do everything you would with a raw SQL statement, but still use a relation mapper with it's validations. And if you have freeform output because you're doing a bunch of JOINs or querying a MATERIALIZED VIEW or whatever, you can just pipe that straight into a struct inline without having to declare a definition somewhere.
block_dagger 3y ago
Longtime Rubyist here that has worked with Elixir. It is only loosely based on Ruby's syntax - there is a _lot_ more punctuation in Elixir. Also much more explicit passing of parameters, including database connections and error handlers in the case of a Phoenix application. It's also a challenge to deploy OTP along other non-hypervised runtimes. BEAM and Elixir are very cool, don't get me wrong, but after some programming web services in Elixir I was ready to head back to Ruby. If I need a highly fault tolerant near realtime comms system, I'll look at Elixir, otherwise I avoid.
- whalesalad 3y ago
  > It's also a challenge to deploy OTP along other non-hypervised runtimes. Pardon?
  - ungamedplayer 3y ago
    This part stumped me too. Maybe op had some deployment issues on VM systems.
    - whalesalad 3y ago
      ngl I get a sense the op and most people commenting in this thread don’t understand elixir at all. the fact that the syntax somewhat resembles ruby is really just 5% of what makes elixir interesting. It’s a distraction from the real value of the beam, OTP, and immutable data.
- rozap 3y ago
  > It's also a challenge to deploy OTP along other non-hypervised runtimes. What in tarnation. Please expand on this one.
superdisk 3y ago
For me the big sell of Elixir/Erlang is that it makes running "background jobs" a complete breeze with no concern for blocking IO bringing the entire server to a halt, especially in a web server context. At my last job I had to do a bunch of HTTP requests in a webhook handler and if enough happened at once, the entire site would just crash due to all the OS processes being busy. I found myself desperately wishing I was just using Elixir instead because it would have been trivial to just spin up a Task to do it and move on.
- ghayes 3y ago
  We recently switched from Rust to Elixir on a new service in no small part to this. The idea of sharing objects through Tokio async processes felt difficult compared to this being a first class feature of Elixir. It’s not that it’s hard, per se, but it felt harder to get right.
- jbmsf 3y ago
  Meh. I don't want background jobs to be a breeze in quite this way. I want background work to live on different compute capacity than http requests, both because they have very different resources usage and because I want to have state or queues in front of background work so there's a well-defined process for retry, error handling, and back-pressure. I get it, of course, it'd be lovely if these complications didn't exist and the same framework handled everything... but I don't think a programming language or even a runtime gets you there. You also need monitoring and ops processes to be part of the solution.
  - throwawaymaths 3y ago
    You're creating a really difficult distributed systems problem then. What happens if the async request gets swallowed? Are you coordinating telemetry and tracing across these compute units? Not all of us can afford elaborate ops teams
    - yuppiepuppie 3y ago
      Its really not that difficult to trace this stuff with modern APM tools. Datadog and Elastic APM support this out of the box for most languages/frameworks. And id be suprised if other big players in space didnt also.
colesantiago 3y ago
Which companies have used Elixir in production, I know Brex used to use Elixir but now used Kotlin and also the Bleacher Report. Are there any more?
- romanhn 3y ago
  There's a pretty large list here: https://elixir-companies.com https://elixir-companies.com
- schainks 3y ago
  Adobe and Apple.
- sho 3y ago
  There are tons, I can name at least 4 in my city alone, all fintech. Elixir really excels, and is heavily used, at payment processing workflows, where genservers and the concurrency model is amazingly useful at handling complex, multi-step transactions involving multiple, often external, actors. None of the companies appear on that list, I think those kinds of things should always be taken with a grain of salt.
- voxadam 3y ago
  Some case studies of Elixir's use at various companies can be found on the main Elixir site.[0] [0] https://elixir-lang.org/cases.html https://elixir-lang.org/cases.html
- tionis 3y ago
  Discord uses it for their backend I think. Interestingly WhatsApp's backend is also built on Beam, but using Erlang directly instead.
- keep_reading 3y ago
  Based on the customer list of Oban.pro and knowledge from previous conferences there's also Nintendo (one of their online game stores uses it?), PepsiCo, Apple, Toyota...
sinuhe69 3y ago
Coming from F# and only dabbled in Elixir, I find the language unfortunately a bit confusing. For instance, the signature of a function only reveals the name and number of the parameters but not type, so in a big library, it’s quite hard to recognize (mentally) what goes into what and one can only see one plugged the wrong parameters after one had ran and debugged the code. In strict-type language like F#, such issues would be detected right away during coding, thus it helps to reduce the time and effort immensely. So my question is what are the main selling points of Elixir besides the Erlang environment?
- rapind 3y ago
  As a language, I wouldn't call it an upgrade over F# (subjective). The main selling point is probably running on BEAM w/ ruby-ish syntax. BEAM is kind of a big deal IMO. I don't think it compares very well to F# types, but you can use typespecs: https://hexdocs.pm/elixir/1.15.7/typespecs.html https://hexdocs.pm/elixir/1.15.7/typespecs.html
- jswny 3y ago
  Static typing for Elixir is in active development: https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradual-typing/ https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua... Yes, it is currently dynamic and yes, that means you won't get much int he way of type information from the language itself, it's not currently a statically typed language.
  - deviprsd 3y ago
    dynamic but still strongly typed
- shirvan 3y ago
  There is a lot to like about Elixir itself including the nice syntax, which as mentioned in the article is inspired by Ruby and very easy to pickup. The BEAM/OTP is what really give Elixir the edge over other languages that I've used. In my experience they include many batteries that would be libraries in other languages, and most times those libraries add a ton of complexity, and sometimes a big learning curve; Async anything is a good example. I think once one works with Elixir for some time, and gets to learn these builtin tools and abstractions they understand the power of the ecosystem as a whole.
BMorearty 3y ago
> In Ruby it's common to use exceptions for control flow. I think this is just plain incorrect. The example given later in this paragraph is the Rails `update` method--but the approach used in all canonical Rails examples and generators is the non-exception version of `update`.
- whalesalad 3y ago
  Ruby != Rails. There are a lot of bang! methods that will raise on error in Rails. But in general Ruby is just like Python in that it is indeed common to use exceptions for control flow.
  - BMorearty 3y ago
    I know Ruby != Rails but the example wasn’t mine. It was from the paragraph I quoted from the post, which conflates the two. It may be true in Python--I don’t use it much--but I know Ruby well. It was my primary language for 13 years, at multiple companies. I taught it to over a thousand engineers at Airbnb over the course of five years. I still disagree that it is common to use exceptions for control flow. Maybe it’s a matter of the interpretation of the word “common.” ¯\_(ツ)_/¯
- thibaut_barrere 3y ago
  I do not find it incorrect at all, as a Ruby user since 2004. A lot of gems use exceptions for control flow and it is also common in apps or libraries I've written or maintained (just a data point).
  - lcnPylGDnU4H9OF 3y ago
    > A lot of gems use exceptions for control flow Do you happen to have an example of such control flow to link to? Not that I don't believe you but I wonder if there's a difference in what is meant by "control flow" between commenters. begin do_stuff! rescue MyFirstLibraryError => error # handle first rescue MySecondLibraryError => error # handle second end That could be "control flow" to one person and "error handling" to another. Or even both to a third person.
gigatexal 3y ago
“In fact, I might go as far as saying that Elixir gives you a fun language (like Ruby) while leaving out the stateful footguns OOP languages give you. There are no classes, no instances, no inheritance…it's immutable and functional and you're not bogged down by a static type system.” I want this but with types. I’m convinced strongly typed is the way to go for larger code bases as it hides the magic of a lot of things and is easier to reason about.
- creakingstairs 3y ago
  Types are coming! Hopefully not too far away. https://elixir-lang.org/blog/2023/06/22/type-system-updates-research-dev/ https://elixir-lang.org/blog/2023/06/22/type-system-updates-...
- weatherlight 3y ago
  It's less of an issue with elixir than it is with ruby or python or any other dynamic lang (or static lang) with mutability. Because of pattern matching/unification in functions, you have a good idea what shape your data is as it's being passed around. if you still don't feel comfortable, there's always Dialyzer. Dialyzer is a static analysis tool for erlang/elixir. It's part of the standard Erlang Release and stands for DIscrepancy AnaLYZer for ERlang programs. It identifies software discrepancies such as type errors, dead code, unnecessary tests, etc., in single Erlang modules or entire (sets of) applications. Dialyzer starts from a base of correct programs and infers types; it doesn't require type annotations but uses them if they are available to provide better warnings. https://fly.io/phoenix-files/adding-dialyzer-without-the-pain/ https://fly.io/phoenix-files/adding-dialyzer-without-the-pai...
  - japhib 3y ago
    Big time this ^, I really need static typing in hobby projects (I like C#/Typescript) but at work we use Elixir and it doesn't end up being a problem because of pattern matching. It's partially because it ends up being run-time type checking, and partially because it makes the code _read_ like a statically typed language.
- 3y ago
hartator 3y ago
And still 0 successful startup has been built on top of elixir.
- ashton314 3y ago
  Hogwash. I used to work for one. Left to go back to school. They’re still going strong. Maybe I’ll go back some day.
- Supermancho 3y ago
  Real talk. HN posts on anything OTP continue to be the same echo chamber of responses, with most readers just leaving them to it. Many people have been trying to nicely point out that "uses Elixir in some places" is not the same as "built on Elixir". ie It's exceedingly rare for any system to have a secret sauce called Elixir and none of them have sparked a race to use it. How many decades before someone points out it's a dead horse? From my few years off-and-on, Elixir is a nice syntax on top of Erlang. Erlang is intrinsically a flow-based system. Just because you can prove something is turing complete, doesn't make Elixir/Erlang a good general language choice. The no-side effect philosophy is a dead end. You just store state somewhere else anyway, so what have you gained? The current type system is problematic, at best, and everyone knows that. Decades have passed and the same tired phrasing appears in every paper and every talk. "dynamic, scalable language built on Erlang VM, designed for building maintainable, high-concurrency apps". It's clear that this isn't special anymore and it reads as desperate for relevancy, or left to rot. Either way, Elixir/Erlang is a specialty tool like Apache Nifi or CockroachDB. Niche, at best, a sub-optimal choice at worst, for most projects. It's oft repeated that Elixir/Erlange tooling is "established". Whenever I have used the tooling or a framework (looking at you Phoenix), it's been primitive (Observer has gotten better), poorly implemented (IDEA, VScode), or requires a large amount of memorization to "learn" it. Not the language, the tooling. It's not enough to know Elixir or Erlang. You better understand BEAM (to some extent), shell scripting (just run it in a docker on windows), some glue technologies (something to build the UI, maintain state, etc), and then you can get down to building your backend application.
  - ashton314 3y ago
byhemechi 3y ago
I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so much as an error.
- deleted 3y ago
  [deleted]
- weatherlight 3y ago
  because of unification/pattern-matching you have a pretty good idea, just looking at function name + args what the shape of the data is going to be.
  - artdigital 3y ago
    As someone who worked with Elixir for the past couple years, and maintains multiple libraries in Elixir - nah not really. Static typing is the thing I'm missing with Elixir. No matter how much pattern matching you do, and how many typespecs you add to get a better understanding of what's behind a variable, you'll still run into issues at runtime frequently that could have been avoided if it was statically typed. Dialyzer is great but typespecs and pattern matching only get you so far. You'll always run into situations where the shape of data is not clear, and you have to open a REPL to do an IO.inspect somewhere
    - h0l0cube 3y ago
      > You'll always run into situations where the shape of data is not clear If you're using typespecs, then I think the deficiency is with tooling. I think the language servers (like ElixirLS) were quite buggy for a while, but it's getting better at code completion and inspection. But if the type has no spec then you're in the same situation as any gradually typed language.
aryehof 3y ago
Write after you’ve been there for 2 years, instead of at the start. That new thing always looks like a flawless shiny new silver bullet when starting out.
- ashton314 3y ago
  I work professionally as an elixir developer for longer than that before starting a PhD program; Elixir was and still is a gem. It’s not perfect. It holds up incredibly well though.
- ljm 3y ago
  I'm the author and well accustomed to the concept of the honeymoon period. First impressions have their place and that's what I'm offering, because I'm talking to expert Rubyists, not expert Elixir/Erlang devs.
99miles 3y ago
I've been using Ruby since about 2007. Every time I attempt to switch to the next "cool" thing, I ended up switching back, because Ruby is what I love and am the fastest with, and that's all that matters. However, I've been starting to see a lot more Elixir buzz, and I love the looks and sounds of it. Looks like I'll need to start a new side project soon to give it a try.
zoogeny 3y ago
I have been watching Elixir YouTube videos pretty much every day for the last few weeks. I guess there was an Elixir conference recently and after I watched a couple, YouTube has been sending me a consistent stream of Elixir content. I really want to try out this language. I love the idea of Erlang but the few times I've had to deal with it (an ejabberd chat server was one) I found it to be a bit too quirky. Every video I've seen with Joe Armstrong leads me to believe he was an under-appreciated genius. Isolated processes and message passing (Actors) seem a good candidate for the future of distributed programming (see this recent video from Crockford on his new Misty programming language [1] - notice how the questions were about Elixir/Erlang). I love pattern matching and elixir uses this to a high degree. However, I am not 100% sold. Clearly this community punches above its weight, and the BEAM is obviously no slouch and is a brilliant choice for a platform to build upon. But I get concerned looking at the magic of LiveView (and LiveBook). My experience is that if something sounds too good to be true, it often is. A lot of the jargon is also totally unfamiliar to me - things like GenServers and other esoteric kinds of platform specific knowledge. It feels like stepping into a one-way portal, I'm not sure any knowledge in that universe is transferable. There is a huge risk in niche languages and platforms. Hard to hire for, hard to find libraries for, hard to find blogs/tutorials/etc. With alternatives like Go having a pretty respectable concurrency story ... it is pretty hard to justify taking the risk on such a small community. But kudos to that community. It is honestly impressive to me what they have achieved. I'm also very excited to see what happens with their type system implementation. 1. https://www.youtube.com/watch?v=R2idkNdKqpQ https://www.youtube.com/watch?v=R2idkNdKqpQ
- throwawaymaths 3y ago
  > looking at the magic of LiveView (and LiveBook) What's the magic? I think it's pretty easy to get a correct mental model of everything in livebook maybe excepting exact details of how the diff calculation/data compression works. Even so, you can spy on the websocket messages and get a reasonable picture of what's going on in a pinch. Liveview is incredibly straightforward.
  - zoogeny 3y ago
    > Liveview is incredibly straightforward. I don't agree. One of the keynotes from the 2023 ElixirConf was Chris McCord (one of the principle developers of LiveView) describing how it is almost 1.0 [1]. One thing that made me laugh a bit was him emphasizing how much Javascript he's had to write (he was referencing the fact that there is an internal community meme that you can achieve such incredible behaviors without writing Javascript). His quip was "because I wrote it all". I wonder if you asked him "was it straightforward?" what do you think his answer would be? There are a lot of videos of people talking about how they managed to write something in LiveView. Here is one from 2022 "How I built a block based editor in LiveView" [2]. That is a good one to see how non-trivial tasks can be difficult in LiveView, describing a few times how he had to fight with it to get it to kinda-sorta do what he wanted. Certainly this man will achieve his goal since he is smart and motivated, but his description of his journey does not lead me to a conclusion of "this is incredibly straightforward". This is impressive tech no doubt, but it is far from clear it is currently reliable enough to stake a startup on. Another tangential issue I have with LiveView is the obvious requirement for a persistent socket connection ... which leads me to wonder how one would approach local-first type developments. Again, certainly possible but definitely not straightforward. 1. https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeSync https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeS... 2. https://www.youtube.com/watch?v=7yZwxsG7tVs https://www.youtube.com/watch?v=7yZwxsG7tVs
danjac 3y ago
It would be nice to work with Elixir, having played around with it. However every Elixir job I've seen requires Elixir experience, so I don't really see much opportunity for working with it professionally.
- fastball 3y ago
  Yeah, I'm in the same boat. Have tried to find a side project that would justify Elixir/Erlang and nothing has jumped out at me that would cut it. I still generally want to pick the best tool for the job (even on side projects), and Erlang frequently feels like overkill for the use cases I have in mind.
  - danjac 3y ago
    Sure but for these companies "did some Elixir in a weekend project" doesn't count as experience.
    - fastball 3y ago
      Yes, that is my point. In order to demonstrate experience you really need to show work on something that justified Erlang, not just that you understand the syntax of Elixir and the basics of working with the Erlang VM. And usually a "weekend project" does not qualify (though that really depends on the project). But I do think most companies that are looking for Elixir experience would be happy with your weekend project if was actually used by people in a way where Elixir could shine.
da39a3ee 3y ago
> There are no classes, no instances, no inheritance I don't know anything about Elixir, but it bothers me when people claim that languages like Rust and Go are "not object oriented". If you create structs and have special syntax for defining functions that operate on instances of those structs, then those are called objects and you are doing OOP. Just because some Java people came up with a definition of OOP that says it has to have inheritance, doesn't mean you actually have to pay attention to their definition.
- lawn 3y ago
  And Erlang (and Elixir) is also closer to the original definition of OOP, with it's focus on message passing between processes ("objects").
  - da39a3ee 3y ago
    Right exactly. The author implies that Elixir isn't an "OOP language" but I agree with you that (AIUI) it's almost the opposite -- it's descended from Erlang whose, AIUI, entire raison d'etre is programming in a style that is strongly oriented around objects (i.e. instances that usually represent entities in the application domain, and communicate by message passing). Immutability is orthogonal.
    - ljm 3y ago
      I mean, I agree as much in that OOP in its classical Alan Kay definition has little to nothing in common with what we currently call OOP. Erlang definitely has more in common with Smalltalk and even Lisp in terms of its architecture and also the ability to modify it at runtime. At least in elixir, state and behaviour aren't intermingled as in Java-style OOP (which PHP, C# and Ruby do mostly)
- deleted 3y ago
  [deleted]
EMM_386 3y ago
> you're not bogged down by a static type system Maybe it's just me, and I'm not even specifically referring to this particular post ... but why is there so much "debate and discussion" (flamewars?) over static typing recently? I am guessing this is due to a large influx of people into IT, many of whom got hired because they knew some JavaScript, "React a plus" a lot out of bootcamps and similar programs. As that sizable group ran headlong into static typing, usually via TypeScript, then the debates began. All over Reddit, Twitter, even HN. People insisting that the verbose and confusing syntax was a "bridge-too-far" and one they would not cross, even if the reasons came down to "it looks weird" or "don't have to 'compile' JavaScript". Maybe, spending too much heads-down time over the last ... whatever decades at this point ... I simply don't get it. Don't get it similar to what I quoted here ... "bogged down by a static type system". "Bogged down", in what way? I spend my days mixed between everything from C# to JavaScript, almost polar opposites. And the rest of it usually in TypeScript. I do not get this feeling of being "bogged down" by static typing .... ever? I don't recall it being an issue, even though I spent hours in statically typed lanagues yesterday alone. Maybe if you are the author of a complex JS library that has to be shoe-horned into TypeScript ... yes, maybe. What I did experience recently was being able to remove a parameter from a function, actually compile with the intent it will fail, see it fail, double click on some things and fix the 17 callers to that method I just changed the signature of, and then a minute or so later after fixing those call sites, I was back to work. Yet, over on the social sites, the debate rages on. Open source projects removing TypeScript practically overnight for "reasons". Questions such as "how many type issues did you run into before switching to TypeScript", leaving me to wonder if that is even a rational question. And then on the flipside, "TypeScript is the greatest language ever", heart emojis being sent to it, "If you are a JS dev you need to be using TS". It's all strange to me, having used JavaScript for the first time back in 1996. I'm convinced it was this wave of JavaScript devs crashing into new requirements to use TypeScript that started it. It will sort itself out here at some point.
ctrlmeta 3y ago
> A few months ago I started a new job at a company that uses Elixir > In fact, I might go as far as saying that Elixir gives you a fun language (like Ruby) while leaving out the stateful footguns OOP languages give you. I don't mean to discount the author's experiences and opinion in this post. It's a nice post with a lot of good food for thought. Likewise I want to share only my own experience here. Two months into any new programming language, it feels like a fun language. Eventually the novelty factor wears off. And then it becomes a boring language. And I say "boring" in a positive sense. The daily driver languages should be boring. Should present no surprises. Get the job done and get out of my way. When we transistion from the fun phase to that boring phase, what matters more is how good the language is fundamentally designed. As an example in Elixir the pattern matching abilities are great but I don't know if I could justify choosing a language without compile-time type safety in this day and age!
readline_prompt 3y ago
understandably types are great, but the projects I've worked in got along just fine using specs and dialyzer's success typing. of course sometimes it can get messy like in macros etc.
sBqQu3U0wH 3y ago
>A few months ago I started a new job at a company that uses Elixir as its main language >I've never written a line of Elixir or Erlang before in my life How is this possible?
- jacquesm 3y ago
  It's possible because the number of programmers that have been exposed to Erlang and Elixir is a very small fraction of the total. Besides, many programmers go through their whole career in a single eco-system (.NET, Java, C, C++, COBOL, PHP etc).
  - sBqQu3U0wH 3y ago
    Hmm, I was dabbling with Elixir for quite some time now, but never considered myself proficient enough for applying to Elixir jobs. May be worth a try.
- dbbk 3y ago
  My company hires non-Elixir developers for Elixir roles too. The candidates with experience are just far too hard to find.
- ch4s3 3y ago
  I've hired a number of people to write Elixr who were skilled and eager but hadn't used it before.
- toast0 3y ago
  Some companies have sanity in hiring? I've been hired to work in Erlang without experience (although I got typecast into php stuff because I did have experience) and although the company was dependent on Erlang, we almost never hired anyone with Erlang experience. Hire smart people that are comfortable learning new things, have a project where the strength of BEAM is compelling, buy a bunch of Erlang books. My current job is mostly Rust and I didn't know that before I started either. And seems like the team is similar. Smaller team, so I don't know have confidence in my likely to know Rust estimate. The pool of people who are looking for a new job, and are experienced in Erlang/Elixir, and have exposure to the business specialization, and want to work for a company is very small and hard to find. Hiring companies can ask for it, but they'll have to compromise. It almost certainly doesn't hurt to apply to a job where you don't meet the stated requirements; there's likely no real penalty for having your resume tossed out, and that happens with qualified resumes too. At worst, maybe they blacklist you and won't look at your resume again ever; that's probably ok. Same thing goes the other way, I'd have preferred an opportunity to use more Erlang, but I didn't find one that met my other needs, so I compromised and write Rust in a cloudy environment and dream about using BEAM and dist and hotloading and all that. Maybe one day.
ThinkBeat 3y ago
I love BEAM since I was first introduced to Erlang. I think it should be adopted a lot more for codebases and that it solves a lot of problems in a good way that are currently solved in bad ways in modern trends. Clearly there are strong preferences among folks for static or dynamic typing, almost like vi vs emacs. My opinion is on typing is: Stating typing does not slow you down. With dynamic typing while you are writing code you have to plan and remember what type a variable of some sort represents before You can act on it. With static languages most type of variables will be known at compile time and can offer good feedback if a type is used in the wrong manner. It also makes it much easier to know what a variable is and what it might be doing if it has an official type. Reading dynamic code I often have to search around a bit to figure out what a variable is. I think if the only reason it is "problematic" to have static typing is because writing "int", "string" etc. is too much work then your priorities are mixed up. Sometimes people resort to Hungarian notation to help out. (Less and less) sName,iAge,etc. That is helpful but you might as well have static typing at that point. There has been a lot of work done to find a good way to add (optional) static typing to Elixir and I think it is on going but represents a hard problem. I am glad Gleam is out (https://gleam.run/ https://gleam.run/), it is my favorite BEAM language now.
michaelcampbell 3y ago
> Exceptions, then! In Ruby it's common to use exceptions for control flow. "common"? Not IME. Certainly possible, but I don't see it a WHOLE lot. Maybe it's just $CURRENTJOB's style not to, I'll grant.
runegustavsson 3y ago
I've been programming in Erlang since 1991, every day; and that has been my intention all the time. I've done things in Haskell, Rust, Elixir, etc.. over the years. Strong typing is extremely valuable but what it all boils down to is where I have the most fun. Erlang is the prog.lang that gives me most joy and I plan to continue hacking Erlang, at least, until I retire in a few years.
- news_to_me 3y ago
  What kinds of projects have been the most fun for you to work on?
bdavid21wnec 3y ago
I used Elixir briefly, what sticks out to me was how easy it was to learn. Really like the pattern matching and immutable data. What it excelled at most and I still haven’t found the full equivalent in any other language is building a full CQRS system. The Commanded library combined with graphql was so powerful and well thought out. With the BEAM if a developer writes some bad code, instead of screwing up all your events, the GenServer will just error out on the same event until new code it pushes to fix it. Events will starting queueing, but the whole system is unaffected. It was brilliant
fyokdrigd 3y ago
elixir is awful, mid-long term. you write mix new something. it generates tons of code which will NEVER be update when the template gets update for new people running mix new something. then all the liveview magic happens with JavaScript code writen by someone who will not be there when major browser security model changes happen (and google make sure these happens every 3mo). then who will keep updating the magic js?
- ch4s3 3y ago
  LiveView just uses websockets to push diffs to Morphdom. It's not really much more complicated than that.
jononomo 3y ago
Elixir may not be statically typed, but at least it isn’t object-oriented.
- ch4s3 3y ago
  IMHO, structural typing and pattern matching get a lot of the value of static types without all of the extra effort. But your mileage may vary.
linkdd 3y ago
Self promotion moment: If you enjoy the Result/Either type and API in Rust, I made this project just for this: https://github.com/linkdd/rustic_result https://github.com/linkdd/rustic_result I also made https://github.com/linkdd/rustic_maybe/tree/main https://github.com/linkdd/rustic_maybe/tree/main for an Option/Maybe type. NB: Those are not types, but I'm waiting for set theoretic types to update those libs :)
xonetons018 3y ago
Cone tond
gv83 3y ago
while bracing myself for the downvotes storm: why is this frontpage? it's very bland content harping the same old story about immutable data and pipes, without any real insights other than "3 months of a new thing and it seems cool". are we really at the point where rust or elixir in the title = instant karma shower?
- ljm 3y ago
  I'm the author and it was a surprise to see the post here, and I find that flattering and quite warming that someone liked it enough to share (and enough people liked it enough to upvote it). I respect your opinion but might I suggest you were not the audience for it? There are maybe three or four posts saying the same thing as you. Nobody has to like or agree with anything that hits front page on HN. And yes, I do agree that HN has a soft spot for Elixir lately, same as AI and LLMs.
  - gv83 3y ago
    hope that you got no offense from that, I didn't mean it: it takes quite a lot to publish your musings on the internet and I totally admire that. The article was well written but again, I found it a bit bland for my tastes as you identified I'm probably not the target audience. It's just that, after many many many months of elixir (pseudo?)brigading it's starting to get tiresome. Thanks for your comprehension.
    - ljm 3y ago
      No, no offense at all. I welcome it, actually. Can do a lot more with constructive critique than pure praise. I'm honoured someone found it worthy to submit, but I do know that elixir has been an easy hype topic here. Not sure the rest of my blog would gain the same traction.
pmarreck 3y ago
FYI it's spelled "cinch", not "synch"
rednafi 3y ago
I usually pick up languages that allows me to write and ship high quality CLIs quickly. Over the years, I’ve written and shipped a few. If a language comes up with a VM where the CLI startup time is too long, it’s a show stopper for me. I know, weird requirement.

336 points by orlandohill 3y ago

gaws 3y ago

> A few months ago I started a new job at a company that uses Elixir as its main language on the backend. > I've never written a line of Elixir or Erlang before in my life Isn't this a red flag to the recruiters and hiring managers?

whalesalad 3y ago

The true power of Elixir comes from processes and OTP.

davidw 3y ago
Yep. A lot of these intro things aren't really selling me on how they're using the big features of the BEAM system as an advantage.

jononomo 3y ago

I love Elixir.

hbcondo714 3y ago

> Elixir's |>, and it inserts the result of the previous expression into the first argument of the next function I found this convenient while writing my first Elixir app with Phoenix Liveview: https://github.com/hbcondo/last10k_liveview https://github.com/hbcondo/last10k_liveview

isodev 3y ago

I only learned about Elixir a little more than a year ago and it’s been a lot of fun to learn and incorporate in different components. My biggest joy comes from how much one can do out of the box with beam/otp. Someone in a team I worked with once said “BEAM/OTP is like k8s only without the complicated parts”.

bananadonkey 3y ago
When all else fails that's how I explain it to my team. I spent years learning Elixir but unfortunately the benefits were somewhat undermined by the recent migration to OpenShift (k8s) I had just architected. It would have been a much more tantalizing proposition if k8s was not in the picture; instead we kept our existing dev stack and utilized k8s concepts to achieve what we would have been doing in OTP, with different trade-offs of course.

alskdj21 3y ago

Sasa Juric's The Soul of Erlang and Elixir talk[1] showcases how powerful the language can be. [1] https://www.youtube.com/watch?v=JvBT4XBdoUE&t=4 https://www.youtube.com/watch?v=JvBT4XBdoUE&t=4

ZeroMcMuffin 3y ago
As someone curious about Elixir, I watched this talk earlier this week. I highly recommend it to anyone who has heard all of the "let it fail" and "BEAM does concurrency right" talk, but still doesn't grasp it. It is an incredible talk.

andsbf 3y ago

`...If you call model.update(params) in Ruby, then it returns false if it fails and updates model.errors with what went wrong. Mutable state.` This is Rails stuff, not Ruby

krainboltgreene 3y ago
True, you could implement Ecto exactly in Ruby, except you'd be writing effectively Elixir and every library released that got close to this in the 15 years I've been doing Ruby has been either disliked or disregarded. Each with less contributor activity in their lifespan than a month of ActiveRecord attention.
ljm 3y ago
Yeah, the example is Rails-specific but Ruby is full of methods that mutate existing state. Most of the time they're marked with `!` at the end, but not always.

cheema33 3y ago

How do people switch programming languages? Established languages have massive ecosystems. Large set of libraries. For example, I cannot give up MS Entity Framework Core or Hot Chocolate graphql server for C#. Sure, there are alternatives, but nothing as feature complete. Perhaps it is possible for applications that have small set of requirements.

whalesalad 3y ago
Elixir and Erlang are very well established ecosystems.
qaq 3y ago
Erlang is fairly established 37 years young language and Elixir got to build on top of Erlang ecosystem.
john-radio 3y ago
> Perhaps it is possible for applications that have small set of requirements. Well, for existing applications it is extremely difficult, not because Elixir lacks many important features that C# delivers (although I'm sure it does lack some, and vice versa in a big way), but more just because rebuilding any project that's had hundreds or thousands of person-hours poured into it, that's currently satisfying hundreds or thousands of business requirements which may or may not be documented, is a huge project with few rewards; the investment is huge and the return on investment is... I mean, being on {sexy new language} is nice, but nobody's paying you for that. But that's not what the OP's job is talking about. They just got a different job using Elixir, and are learning the technologies the same way anyone else does, and they're excited about this instance of it enough to write about it.
bradteamworks 3y ago
I used C# before using Elixir. I also thought Entity was awesome. But Ecto and Absinthe are even better from my perspective.
h0l0cube 3y ago
> MS Entity Framework Core Having worked with both EF Core and Ecto, I would gladly see the back of EF Core. Ecto is flexible enough to basically do everything you would with a raw SQL statement, but still use a relation mapper with it's validations. And if you have freeform output because you're doing a bunch of JOINs or querying a MATERIALIZED VIEW or whatever, you can just pipe that straight into a struct inline without having to declare a definition somewhere.

block_dagger 3y ago

Longtime Rubyist here that has worked with Elixir. It is only loosely based on Ruby's syntax - there is a _lot_ more punctuation in Elixir. Also much more explicit passing of parameters, including database connections and error handlers in the case of a Phoenix application. It's also a challenge to deploy OTP along other non-hypervised runtimes. BEAM and Elixir are very cool, don't get me wrong, but after some programming web services in Elixir I was ready to head back to Ruby. If I need a highly fault tolerant near realtime comms system, I'll look at Elixir, otherwise I avoid.

whalesalad 3y ago
> It's also a challenge to deploy OTP along other non-hypervised runtimes. Pardon?
- ungamedplayer 3y ago
  This part stumped me too. Maybe op had some deployment issues on VM systems.
  - whalesalad 3y ago
    ngl I get a sense the op and most people commenting in this thread don’t understand elixir at all. the fact that the syntax somewhat resembles ruby is really just 5% of what makes elixir interesting. It’s a distraction from the real value of the beam, OTP, and immutable data.
rozap 3y ago
> It's also a challenge to deploy OTP along other non-hypervised runtimes. What in tarnation. Please expand on this one.

superdisk 3y ago

For me the big sell of Elixir/Erlang is that it makes running "background jobs" a complete breeze with no concern for blocking IO bringing the entire server to a halt, especially in a web server context. At my last job I had to do a bunch of HTTP requests in a webhook handler and if enough happened at once, the entire site would just crash due to all the OS processes being busy. I found myself desperately wishing I was just using Elixir instead because it would have been trivial to just spin up a Task to do it and move on.

ghayes 3y ago
We recently switched from Rust to Elixir on a new service in no small part to this. The idea of sharing objects through Tokio async processes felt difficult compared to this being a first class feature of Elixir. It’s not that it’s hard, per se, but it felt harder to get right.
jbmsf 3y ago
Meh. I don't want background jobs to be a breeze in quite this way. I want background work to live on different compute capacity than http requests, both because they have very different resources usage and because I want to have state or queues in front of background work so there's a well-defined process for retry, error handling, and back-pressure. I get it, of course, it'd be lovely if these complications didn't exist and the same framework handled everything... but I don't think a programming language or even a runtime gets you there. You also need monitoring and ops processes to be part of the solution.
- throwawaymaths 3y ago
  You're creating a really difficult distributed systems problem then. What happens if the async request gets swallowed? Are you coordinating telemetry and tracing across these compute units? Not all of us can afford elaborate ops teams
  - yuppiepuppie 3y ago
    Its really not that difficult to trace this stuff with modern APM tools. Datadog and Elastic APM support this out of the box for most languages/frameworks. And id be suprised if other big players in space didnt also.

colesantiago 3y ago

Which companies have used Elixir in production, I know Brex used to use Elixir but now used Kotlin and also the Bleacher Report. Are there any more?

romanhn 3y ago
There's a pretty large list here: https://elixir-companies.com https://elixir-companies.com
schainks 3y ago
Adobe and Apple.
sho 3y ago
There are tons, I can name at least 4 in my city alone, all fintech. Elixir really excels, and is heavily used, at payment processing workflows, where genservers and the concurrency model is amazingly useful at handling complex, multi-step transactions involving multiple, often external, actors. None of the companies appear on that list, I think those kinds of things should always be taken with a grain of salt.
voxadam 3y ago
Some case studies of Elixir's use at various companies can be found on the main Elixir site.[0] [0] https://elixir-lang.org/cases.html https://elixir-lang.org/cases.html
tionis 3y ago
Discord uses it for their backend I think. Interestingly WhatsApp's backend is also built on Beam, but using Erlang directly instead.
keep_reading 3y ago
Based on the customer list of Oban.pro and knowledge from previous conferences there's also Nintendo (one of their online game stores uses it?), PepsiCo, Apple, Toyota...

sinuhe69 3y ago

Coming from F# and only dabbled in Elixir, I find the language unfortunately a bit confusing. For instance, the signature of a function only reveals the name and number of the parameters but not type, so in a big library, it’s quite hard to recognize (mentally) what goes into what and one can only see one plugged the wrong parameters after one had ran and debugged the code. In strict-type language like F#, such issues would be detected right away during coding, thus it helps to reduce the time and effort immensely. So my question is what are the main selling points of Elixir besides the Erlang environment?

rapind 3y ago
As a language, I wouldn't call it an upgrade over F# (subjective). The main selling point is probably running on BEAM w/ ruby-ish syntax. BEAM is kind of a big deal IMO. I don't think it compares very well to F# types, but you can use typespecs: https://hexdocs.pm/elixir/1.15.7/typespecs.html https://hexdocs.pm/elixir/1.15.7/typespecs.html
jswny 3y ago
Static typing for Elixir is in active development: https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradual-typing/ https://elixir-lang.org/blog/2023/09/20/strong-arrows-gradua... Yes, it is currently dynamic and yes, that means you won't get much int he way of type information from the language itself, it's not currently a statically typed language.
- deviprsd 3y ago
  dynamic but still strongly typed
shirvan 3y ago
There is a lot to like about Elixir itself including the nice syntax, which as mentioned in the article is inspired by Ruby and very easy to pickup. The BEAM/OTP is what really give Elixir the edge over other languages that I've used. In my experience they include many batteries that would be libraries in other languages, and most times those libraries add a ton of complexity, and sometimes a big learning curve; Async anything is a good example. I think once one works with Elixir for some time, and gets to learn these builtin tools and abstractions they understand the power of the ecosystem as a whole.

BMorearty 3y ago

> In Ruby it's common to use exceptions for control flow. I think this is just plain incorrect. The example given later in this paragraph is the Rails `update` method--but the approach used in all canonical Rails examples and generators is the non-exception version of `update`.

whalesalad 3y ago
Ruby != Rails. There are a lot of bang! methods that will raise on error in Rails. But in general Ruby is just like Python in that it is indeed common to use exceptions for control flow.
- BMorearty 3y ago
  I know Ruby != Rails but the example wasn’t mine. It was from the paragraph I quoted from the post, which conflates the two. It may be true in Python--I don’t use it much--but I know Ruby well. It was my primary language for 13 years, at multiple companies. I taught it to over a thousand engineers at Airbnb over the course of five years. I still disagree that it is common to use exceptions for control flow. Maybe it’s a matter of the interpretation of the word “common.” ¯\_(ツ)_/¯
thibaut_barrere 3y ago
I do not find it incorrect at all, as a Ruby user since 2004. A lot of gems use exceptions for control flow and it is also common in apps or libraries I've written or maintained (just a data point).
- lcnPylGDnU4H9OF 3y ago
  > A lot of gems use exceptions for control flow Do you happen to have an example of such control flow to link to? Not that I don't believe you but I wonder if there's a difference in what is meant by "control flow" between commenters. begin do_stuff! rescue MyFirstLibraryError => error # handle first rescue MySecondLibraryError => error # handle second end That could be "control flow" to one person and "error handling" to another. Or even both to a third person.

gigatexal 3y ago

“In fact, I might go as far as saying that Elixir gives you a fun language (like Ruby) while leaving out the stateful footguns OOP languages give you. There are no classes, no instances, no inheritance…it's immutable and functional and you're not bogged down by a static type system.” I want this but with types. I’m convinced strongly typed is the way to go for larger code bases as it hides the magic of a lot of things and is easier to reason about.

creakingstairs 3y ago
Types are coming! Hopefully not too far away. https://elixir-lang.org/blog/2023/06/22/type-system-updates-research-dev/ https://elixir-lang.org/blog/2023/06/22/type-system-updates-...
weatherlight 3y ago
It's less of an issue with elixir than it is with ruby or python or any other dynamic lang (or static lang) with mutability. Because of pattern matching/unification in functions, you have a good idea what shape your data is as it's being passed around. if you still don't feel comfortable, there's always Dialyzer. Dialyzer is a static analysis tool for erlang/elixir. It's part of the standard Erlang Release and stands for DIscrepancy AnaLYZer for ERlang programs. It identifies software discrepancies such as type errors, dead code, unnecessary tests, etc., in single Erlang modules or entire (sets of) applications. Dialyzer starts from a base of correct programs and infers types; it doesn't require type annotations but uses them if they are available to provide better warnings. https://fly.io/phoenix-files/adding-dialyzer-without-the-pain/ https://fly.io/phoenix-files/adding-dialyzer-without-the-pai...
- japhib 3y ago
  Big time this ^, I really need static typing in hobby projects (I like C#/Typescript) but at work we use Elixir and it doesn't end up being a problem because of pattern matching. It's partially because it ends up being run-time type checking, and partially because it makes the code _read_ like a statically typed language.
3y ago

hartator 3y ago

And still 0 successful startup has been built on top of elixir.

ashton314 3y ago
Hogwash. I used to work for one. Left to go back to school. They’re still going strong. Maybe I’ll go back some day.
Supermancho 3y ago
Real talk. HN posts on anything OTP continue to be the same echo chamber of responses, with most readers just leaving them to it. Many people have been trying to nicely point out that "uses Elixir in some places" is not the same as "built on Elixir". ie It's exceedingly rare for any system to have a secret sauce called Elixir and none of them have sparked a race to use it. How many decades before someone points out it's a dead horse? From my few years off-and-on, Elixir is a nice syntax on top of Erlang. Erlang is intrinsically a flow-based system. Just because you can prove something is turing complete, doesn't make Elixir/Erlang a good general language choice. The no-side effect philosophy is a dead end. You just store state somewhere else anyway, so what have you gained? The current type system is problematic, at best, and everyone knows that. Decades have passed and the same tired phrasing appears in every paper and every talk. "dynamic, scalable language built on Erlang VM, designed for building maintainable, high-concurrency apps". It's clear that this isn't special anymore and it reads as desperate for relevancy, or left to rot. Either way, Elixir/Erlang is a specialty tool like Apache Nifi or CockroachDB. Niche, at best, a sub-optimal choice at worst, for most projects. It's oft repeated that Elixir/Erlange tooling is "established". Whenever I have used the tooling or a framework (looking at you Phoenix), it's been primitive (Observer has gotten better), poorly implemented (IDEA, VScode), or requires a large amount of memorization to "learn" it. Not the language, the tooling. It's not enough to know Elixir or Erlang. You better understand BEAM (to some extent), shell scripting (just run it in a docker on windows), some glue technologies (something to build the UI, maintain state, etc), and then you can get down to building your backend application.
- ashton314 3y ago

byhemechi 3y ago

I often see people say static typing slows them down and I'd really like to know why that is because for me it's the exact opposite, I really don't like not knowing what format data is in. I'd much rather have to write slightly more verbose code and have a vast number of possible errors caught at compile time instead of having things go wrong in production when someone inputs something a bit weird with nothing so much as an error.

deleted 3y ago
[deleted]
weatherlight 3y ago
because of unification/pattern-matching you have a pretty good idea, just looking at function name + args what the shape of the data is going to be.
- artdigital 3y ago
  As someone who worked with Elixir for the past couple years, and maintains multiple libraries in Elixir - nah not really. Static typing is the thing I'm missing with Elixir. No matter how much pattern matching you do, and how many typespecs you add to get a better understanding of what's behind a variable, you'll still run into issues at runtime frequently that could have been avoided if it was statically typed. Dialyzer is great but typespecs and pattern matching only get you so far. You'll always run into situations where the shape of data is not clear, and you have to open a REPL to do an IO.inspect somewhere
  - h0l0cube 3y ago
    > You'll always run into situations where the shape of data is not clear If you're using typespecs, then I think the deficiency is with tooling. I think the language servers (like ElixirLS) were quite buggy for a while, but it's getting better at code completion and inspection. But if the type has no spec then you're in the same situation as any gradually typed language.

aryehof 3y ago

Write after you’ve been there for 2 years, instead of at the start. That new thing always looks like a flawless shiny new silver bullet when starting out.

ashton314 3y ago
I work professionally as an elixir developer for longer than that before starting a PhD program; Elixir was and still is a gem. It’s not perfect. It holds up incredibly well though.
ljm 3y ago
I'm the author and well accustomed to the concept of the honeymoon period. First impressions have their place and that's what I'm offering, because I'm talking to expert Rubyists, not expert Elixir/Erlang devs.

99miles 3y ago

I've been using Ruby since about 2007. Every time I attempt to switch to the next "cool" thing, I ended up switching back, because Ruby is what I love and am the fastest with, and that's all that matters. However, I've been starting to see a lot more Elixir buzz, and I love the looks and sounds of it. Looks like I'll need to start a new side project soon to give it a try.

zoogeny 3y ago

I have been watching Elixir YouTube videos pretty much every day for the last few weeks. I guess there was an Elixir conference recently and after I watched a couple, YouTube has been sending me a consistent stream of Elixir content. I really want to try out this language. I love the idea of Erlang but the few times I've had to deal with it (an ejabberd chat server was one) I found it to be a bit too quirky. Every video I've seen with Joe Armstrong leads me to believe he was an under-appreciated genius. Isolated processes and message passing (Actors) seem a good candidate for the future of distributed programming (see this recent video from Crockford on his new Misty programming language [1] - notice how the questions were about Elixir/Erlang). I love pattern matching and elixir uses this to a high degree. However, I am not 100% sold. Clearly this community punches above its weight, and the BEAM is obviously no slouch and is a brilliant choice for a platform to build upon. But I get concerned looking at the magic of LiveView (and LiveBook). My experience is that if something sounds too good to be true, it often is. A lot of the jargon is also totally unfamiliar to me - things like GenServers and other esoteric kinds of platform specific knowledge. It feels like stepping into a one-way portal, I'm not sure any knowledge in that universe is transferable. There is a huge risk in niche languages and platforms. Hard to hire for, hard to find libraries for, hard to find blogs/tutorials/etc. With alternatives like Go having a pretty respectable concurrency story ... it is pretty hard to justify taking the risk on such a small community. But kudos to that community. It is honestly impressive to me what they have achieved. I'm also very excited to see what happens with their type system implementation. 1. https://www.youtube.com/watch?v=R2idkNdKqpQ https://www.youtube.com/watch?v=R2idkNdKqpQ

throwawaymaths 3y ago
> looking at the magic of LiveView (and LiveBook) What's the magic? I think it's pretty easy to get a correct mental model of everything in livebook maybe excepting exact details of how the diff calculation/data compression works. Even so, you can spy on the websocket messages and get a reasonable picture of what's going on in a pinch. Liveview is incredibly straightforward.
- zoogeny 3y ago
  > Liveview is incredibly straightforward. I don't agree. One of the keynotes from the 2023 ElixirConf was Chris McCord (one of the principle developers of LiveView) describing how it is almost 1.0 [1]. One thing that made me laugh a bit was him emphasizing how much Javascript he's had to write (he was referencing the fact that there is an internal community meme that you can achieve such incredible behaviors without writing Javascript). His quip was "because I wrote it all". I wonder if you asked him "was it straightforward?" what do you think his answer would be? There are a lot of videos of people talking about how they managed to write something in LiveView. Here is one from 2022 "How I built a block based editor in LiveView" [2]. That is a good one to see how non-trivial tasks can be difficult in LiveView, describing a few times how he had to fight with it to get it to kinda-sorta do what he wanted. Certainly this man will achieve his goal since he is smart and motivated, but his description of his journey does not lead me to a conclusion of "this is incredibly straightforward". This is impressive tech no doubt, but it is far from clear it is currently reliable enough to stake a startup on. Another tangential issue I have with LiveView is the obvious requirement for a persistent socket connection ... which leads me to wonder how one would approach local-first type developments. Again, certainly possible but definitely not straightforward. 1. https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeSync https://www.youtube.com/watch?v=FADQAnq0RpA&ab_channel=CodeS... 2. https://www.youtube.com/watch?v=7yZwxsG7tVs https://www.youtube.com/watch?v=7yZwxsG7tVs

danjac 3y ago

It would be nice to work with Elixir, having played around with it. However every Elixir job I've seen requires Elixir experience, so I don't really see much opportunity for working with it professionally.

fastball 3y ago
Yeah, I'm in the same boat. Have tried to find a side project that would justify Elixir/Erlang and nothing has jumped out at me that would cut it. I still generally want to pick the best tool for the job (even on side projects), and Erlang frequently feels like overkill for the use cases I have in mind.
- danjac 3y ago
  Sure but for these companies "did some Elixir in a weekend project" doesn't count as experience.
  - fastball 3y ago
    Yes, that is my point. In order to demonstrate experience you really need to show work on something that justified Erlang, not just that you understand the syntax of Elixir and the basics of working with the Erlang VM. And usually a "weekend project" does not qualify (though that really depends on the project). But I do think most companies that are looking for Elixir experience would be happy with your weekend project if was actually used by people in a way where Elixir could shine.

da39a3ee 3y ago

> There are no classes, no instances, no inheritance I don't know anything about Elixir, but it bothers me when people claim that languages like Rust and Go are "not object oriented". If you create structs and have special syntax for defining functions that operate on instances of those structs, then those are called objects and you are doing OOP. Just because some Java people came up with a definition of OOP that says it has to have inheritance, doesn't mean you actually have to pay attention to their definition.

lawn 3y ago
And Erlang (and Elixir) is also closer to the original definition of OOP, with it's focus on message passing between processes ("objects").
- da39a3ee 3y ago
  Right exactly. The author implies that Elixir isn't an "OOP language" but I agree with you that (AIUI) it's almost the opposite -- it's descended from Erlang whose, AIUI, entire raison d'etre is programming in a style that is strongly oriented around objects (i.e. instances that usually represent entities in the application domain, and communicate by message passing). Immutability is orthogonal.
  - ljm 3y ago
    I mean, I agree as much in that OOP in its classical Alan Kay definition has little to nothing in common with what we currently call OOP. Erlang definitely has more in common with Smalltalk and even Lisp in terms of its architecture and also the ability to modify it at runtime. At least in elixir, state and behaviour aren't intermingled as in Java-style OOP (which PHP, C# and Ruby do mostly)
deleted 3y ago
[deleted]

EMM_386 3y ago

> you're not bogged down by a static type system Maybe it's just me, and I'm not even specifically referring to this particular post ... but why is there so much "debate and discussion" (flamewars?) over static typing recently? I am guessing this is due to a large influx of people into IT, many of whom got hired because they knew some JavaScript, "React a plus" a lot out of bootcamps and similar programs. As that sizable group ran headlong into static typing, usually via TypeScript, then the debates began. All over Reddit, Twitter, even HN. People insisting that the verbose and confusing syntax was a "bridge-too-far" and one they would not cross, even if the reasons came down to "it looks weird" or "don't have to 'compile' JavaScript". Maybe, spending too much heads-down time over the last ... whatever decades at this point ... I simply don't get it. Don't get it similar to what I quoted here ... "bogged down by a static type system". "Bogged down", in what way? I spend my days mixed between everything from C# to JavaScript, almost polar opposites. And the rest of it usually in TypeScript. I do not get this feeling of being "bogged down" by static typing .... ever? I don't recall it being an issue, even though I spent hours in statically typed lanagues yesterday alone. Maybe if you are the author of a complex JS library that has to be shoe-horned into TypeScript ... yes, maybe. What I did experience recently was being able to remove a parameter from a function, actually compile with the intent it will fail, see it fail, double click on some things and fix the 17 callers to that method I just changed the signature of, and then a minute or so later after fixing those call sites, I was back to work. Yet, over on the social sites, the debate rages on. Open source projects removing TypeScript practically overnight for "reasons". Questions such as "how many type issues did you run into before switching to TypeScript", leaving me to wonder if that is even a rational question. And then on the flipside, "TypeScript is the greatest language ever", heart emojis being sent to it, "If you are a JS dev you need to be using TS". It's all strange to me, having used JavaScript for the first time back in 1996. I'm convinced it was this wave of JavaScript devs crashing into new requirements to use TypeScript that started it. It will sort itself out here at some point.

ctrlmeta 3y ago

> A few months ago I started a new job at a company that uses Elixir > In fact, I might go as far as saying that Elixir gives you a fun language (like Ruby) while leaving out the stateful footguns OOP languages give you. I don't mean to discount the author's experiences and opinion in this post. It's a nice post with a lot of good food for thought. Likewise I want to share only my own experience here. Two months into any new programming language, it feels like a fun language. Eventually the novelty factor wears off. And then it becomes a boring language. And I say "boring" in a positive sense. The daily driver languages should be boring. Should present no surprises. Get the job done and get out of my way. When we transistion from the fun phase to that boring phase, what matters more is how good the language is fundamentally designed. As an example in Elixir the pattern matching abilities are great but I don't know if I could justify choosing a language without compile-time type safety in this day and age!

readline_prompt 3y ago

understandably types are great, but the projects I've worked in got along just fine using specs and dialyzer's success typing. of course sometimes it can get messy like in macros etc.

sBqQu3U0wH 3y ago

>A few months ago I started a new job at a company that uses Elixir as its main language >I've never written a line of Elixir or Erlang before in my life How is this possible?

jacquesm 3y ago
It's possible because the number of programmers that have been exposed to Erlang and Elixir is a very small fraction of the total. Besides, many programmers go through their whole career in a single eco-system (.NET, Java, C, C++, COBOL, PHP etc).
- sBqQu3U0wH 3y ago
  Hmm, I was dabbling with Elixir for quite some time now, but never considered myself proficient enough for applying to Elixir jobs. May be worth a try.
dbbk 3y ago
My company hires non-Elixir developers for Elixir roles too. The candidates with experience are just far too hard to find.
ch4s3 3y ago
I've hired a number of people to write Elixr who were skilled and eager but hadn't used it before.
toast0 3y ago
Some companies have sanity in hiring? I've been hired to work in Erlang without experience (although I got typecast into php stuff because I did have experience) and although the company was dependent on Erlang, we almost never hired anyone with Erlang experience. Hire smart people that are comfortable learning new things, have a project where the strength of BEAM is compelling, buy a bunch of Erlang books. My current job is mostly Rust and I didn't know that before I started either. And seems like the team is similar. Smaller team, so I don't know have confidence in my likely to know Rust estimate. The pool of people who are looking for a new job, and are experienced in Erlang/Elixir, and have exposure to the business specialization, and want to work for a company is very small and hard to find. Hiring companies can ask for it, but they'll have to compromise. It almost certainly doesn't hurt to apply to a job where you don't meet the stated requirements; there's likely no real penalty for having your resume tossed out, and that happens with qualified resumes too. At worst, maybe they blacklist you and won't look at your resume again ever; that's probably ok. Same thing goes the other way, I'd have preferred an opportunity to use more Erlang, but I didn't find one that met my other needs, so I compromised and write Rust in a cloudy environment and dream about using BEAM and dist and hotloading and all that. Maybe one day.

ThinkBeat 3y ago

I love BEAM since I was first introduced to Erlang. I think it should be adopted a lot more for codebases and that it solves a lot of problems in a good way that are currently solved in bad ways in modern trends. Clearly there are strong preferences among folks for static or dynamic typing, almost like vi vs emacs. My opinion is on typing is: Stating typing does not slow you down. With dynamic typing while you are writing code you have to plan and remember what type a variable of some sort represents before You can act on it. With static languages most type of variables will be known at compile time and can offer good feedback if a type is used in the wrong manner. It also makes it much easier to know what a variable is and what it might be doing if it has an official type. Reading dynamic code I often have to search around a bit to figure out what a variable is. I think if the only reason it is "problematic" to have static typing is because writing "int", "string" etc. is too much work then your priorities are mixed up. Sometimes people resort to Hungarian notation to help out. (Less and less) sName,iAge,etc. That is helpful but you might as well have static typing at that point. There has been a lot of work done to find a good way to add (optional) static typing to Elixir and I think it is on going but represents a hard problem. I am glad Gleam is out (https://gleam.run/ https://gleam.run/), it is my favorite BEAM language now.

michaelcampbell 3y ago

> Exceptions, then! In Ruby it's common to use exceptions for control flow. "common"? Not IME. Certainly possible, but I don't see it a WHOLE lot. Maybe it's just $CURRENTJOB's style not to, I'll grant.

runegustavsson 3y ago

I've been programming in Erlang since 1991, every day; and that has been my intention all the time. I've done things in Haskell, Rust, Elixir, etc.. over the years. Strong typing is extremely valuable but what it all boils down to is where I have the most fun. Erlang is the prog.lang that gives me most joy and I plan to continue hacking Erlang, at least, until I retire in a few years.

news_to_me 3y ago
What kinds of projects have been the most fun for you to work on?

bdavid21wnec 3y ago

I used Elixir briefly, what sticks out to me was how easy it was to learn. Really like the pattern matching and immutable data. What it excelled at most and I still haven’t found the full equivalent in any other language is building a full CQRS system. The Commanded library combined with graphql was so powerful and well thought out. With the BEAM if a developer writes some bad code, instead of screwing up all your events, the GenServer will just error out on the same event until new code it pushes to fix it. Events will starting queueing, but the whole system is unaffected. It was brilliant

fyokdrigd 3y ago

elixir is awful, mid-long term. you write mix new something. it generates tons of code which will NEVER be update when the template gets update for new people running mix new something. then all the liveview magic happens with JavaScript code writen by someone who will not be there when major browser security model changes happen (and google make sure these happens every 3mo). then who will keep updating the magic js?

ch4s3 3y ago
LiveView just uses websockets to push diffs to Morphdom. It's not really much more complicated than that.

jononomo 3y ago

Elixir may not be statically typed, but at least it isn’t object-oriented.

ch4s3 3y ago
IMHO, structural typing and pattern matching get a lot of the value of static types without all of the extra effort. But your mileage may vary.

linkdd 3y ago

Self promotion moment: If you enjoy the Result/Either type and API in Rust, I made this project just for this: https://github.com/linkdd/rustic_result https://github.com/linkdd/rustic_result I also made https://github.com/linkdd/rustic_maybe/tree/main https://github.com/linkdd/rustic_maybe/tree/main for an Option/Maybe type. NB: Those are not types, but I'm waiting for set theoretic types to update those libs :)

xonetons018 3y ago

Cone tond

gv83 3y ago

while bracing myself for the downvotes storm: why is this frontpage? it's very bland content harping the same old story about immutable data and pipes, without any real insights other than "3 months of a new thing and it seems cool". are we really at the point where rust or elixir in the title = instant karma shower?

ljm 3y ago
I'm the author and it was a surprise to see the post here, and I find that flattering and quite warming that someone liked it enough to share (and enough people liked it enough to upvote it). I respect your opinion but might I suggest you were not the audience for it? There are maybe three or four posts saying the same thing as you. Nobody has to like or agree with anything that hits front page on HN. And yes, I do agree that HN has a soft spot for Elixir lately, same as AI and LLMs.
- gv83 3y ago
  hope that you got no offense from that, I didn't mean it: it takes quite a lot to publish your musings on the internet and I totally admire that. The article was well written but again, I found it a bit bland for my tastes as you identified I'm probably not the target audience. It's just that, after many many many months of elixir (pseudo?)brigading it's starting to get tiresome. Thanks for your comprehension.
  - ljm 3y ago
    No, no offense at all. I welcome it, actually. Can do a lot more with constructive critique than pure praise. I'm honoured someone found it worthy to submit, but I do know that elixir has been an easy hype topic here. Not sure the rest of my blog would gain the same traction.

pmarreck 3y ago

FYI it's spelled "cinch", not "synch"

rednafi 3y ago

I usually pick up languages that allows me to write and ship high quality CLIs quickly. Over the years, I’ve written and shipped a few. If a language comes up with a VM where the CLI startup time is too long, it’s a show stopper for me. I know, weird requirement.