[HN Gopher] Why Elixir? Common misconceptions
___________________________________________________________________
Why Elixir? Common misconceptions
Author : ahamez
Score : 116 points
Date : 2025-07-23 13:52 UTC (9 hours ago)
(HTM) web link (matthewsinclair.com)
(TXT) w3m dump (matthewsinclair.com)
| andy_ppp wrote:
| Yes, it's always a surprise to me that, given how great Elixir
| is, it didn't take over backend development. It seems so much
| better suited to doing something similar to microservices without
| a lot of the overhead you'd think people would love it. It always
| seems that fads win and projects with extremely tight concepts
| remain niche.
| tl wrote:
| While Elixir is my current favorite language to hack in, it is
| very alien and downright hostile to integrating with existing
| systems. For example, relational database support was postgres
| focused for a long time (to the exclusion even of SQLite and
| continued inability to talk to Oracle). Then you have articles
| like https://dashbit.co/blog/you-may-not-need-redis-with-elixir
| pushing ETS over Redis. While it's a valid argument, it's not
| adoption-friendly.
|
| Clojure brings about half the novelty of Elixir, runs on the
| JVM and still struggles to replace Java.
| stanmancan wrote:
| What's wrong with that article?
|
| For what it's worth, I've been using Elixir professionally
| for a few years now and haven't touched Redis once.
|
| Not sure why telling people they don't need another service
| is bad for adoption?
| throwawaymaths wrote:
| if the author is reading this a minor edit should be that
| whatsapp uses erlang, not elixir.
| Towaway69 wrote:
| I personally prefer Erlang because I'm closer to ideals:
| lightweight processes, message passing and behaviours.
|
| Elixir abstracts that away and leaves a ruby-like language that
| hides much away - which good and fine.
|
| Erlang is by no means a simple language to get one's head around.
| mike1o1 wrote:
| I've been using Elixir for about a year on a side project and
| I've been enjoying it more than any other backend I've used
| (Node, Rails and C#). I recently discovered Ash and I feel like
| after that initial learning curve my productivity (and code
| quality) has improved quite a bit.
|
| I wish Elixir had more mindshare beside just LiveView and "real
| time" type functionality. Even building a GraphQL/JSON endpoint
| without real-time requirements, the functional nature (no side
| effects), pattern matching and ruby inspired syntax makes writing
| plain old JSON controllers a joy.
|
| While Elixir might not have a package for every use case under
| the sun, the low level primitives are there.
| realusername wrote:
| Personally while I enjoy Elixir/Phoenix, I didn't like Ash
| because there's way too many keyword DSL to learn.
|
| It's like Rails except that there's much more resources for
| Rails to find if you made a mistake in the DSL
| mike1o1 wrote:
| Yes, the learning curve is a extremely high. It took a few
| false starts over time, but after the "Ash book" came out, I
| gave it a more serious try and it finally started to click
| for me.
|
| I think it helped that at the time I was trying to build some
| pretty advanced filtering functionality using Ecto and was
| having a pretty tough time. While searching for solutions I
| saw a few mentions of Ash and that it could solve the problem
| out of the box.
|
| After a few days of experiments, I found that it was able to
| do the filtering I wanted out of the box and was even more
| functional than what I was trying to build.
|
| For reference, I was trying to add some tagging functionality
| to a resource and I wanted to be able to filter by that tag,
| including multiple tags. Can I do that in Ecto? Of course,
| but Ash provided that out of the box after modeling the
| resource.
| pmarreck wrote:
| So if you're comfortable with Ecto and SQL, you can safely
| skip over Ash?
| borromakot wrote:
| That is like 0.5% of what Ash helps with :)
| mike1o1 wrote:
| I guess, but you'll be writing a _lot_ of code yourself,
| that might be hard to maintain and can become brittle
| overtime as requirements evolve.
|
| As an example, I wanted to add support for adding tags to
| a resource, and support filtering for the resource by the
| tag, and I wanted to be able to do this filtering both
| through Elixir functions as well as GraphQL.
|
| Can I do this with Ecto? Absolutely, but I'd have to
| build it all myself.
|
| With Ash, I created a `Tag` and `Tagging` resource,
| adding a `many_to_many` block on my resource, marked it
| as public. Then I added the `AshGraphql.Resource`
| extension to my `Tag` resource, marked it as filterable
| and I was done.
|
| Now I can filter and sort by tags, filter by where tags
| _don't_ exist and more. I didn't have to do anything
| other than model my domain, and Ash took care of the rest
| for me. Not only that, but it probably did a lot of
| things for me that I probably wouldn't have thought of,
| such as supporting multi-tenancy, policies and more.
|
| It really is a lovely tool, I can't say enough good
| things about it.
|
| Does it have a learning curve? Absolutely! Is it worth
| overcoming it? Again, absolutely!
| pmarreck wrote:
| Except that it's not like Rails in the sense that in Rails,
| you will eventually develop extremely difficult to debug race
| conditions thanks to mutability that Elixir lacks.
|
| Source: Has worked on million-line Ruby on Rails codebase
| hangonhn wrote:
| I've been wanting to learn Elixir for a long time but is it worth
| learning it without knowing Erlang first? I'm not against
| learning Erlang but just curious if Erlang is a good thing to
| know before tackling Elixir.
| runjake wrote:
| You don't need to learn Erlang first.
| thibaut_barrere wrote:
| Yes, it is worth it to learn Elixir without learning Erlang,
| absolutely.
| _acco wrote:
| I consider myself expert-level at Elixir and did not learn
| Erlang first. Couldn't write a single line of Erlang today
| unaided if I tried.
|
| I picked up Joe's Erlang book years after out of pure
| joy/curiosity.
|
| Especially with LLMs, totally unnecessary.
| Towaway69 wrote:
| Erlang is definitely worth learning but definitely not required
| by Elixir.
|
| Learning the concepts that embody Erlang such as tail recursion
| and function matching, make Erlang worth learning. Erlang is
| also a special mix of Prolog and Lisp.
| pivo wrote:
| To add to this, Erlang is a very simple language that you can
| learn in just a few days. I don't know Elixir but I assume
| that, as is the case with Erlang, the more difficult thing to
| learn is OTP and not the language itself.
|
| For me Erlang was worth learning because it's so
| interestingly different to many other languages because of
| its Prolog roots.
| parthdesai wrote:
| You can get very very far in Elixir without even knowing about
| an acronym called OTP.
| spike021 wrote:
| I only learned Elixir because the company I currently work for
| is an Elixir shop. I've basically ignored Erlang since I
| started here, other than the occasional library being Erlang.
|
| I don't think it's really impeded my ability to learn or use
| Elixir. But I could also see how learning it and the
| underpinnings for Elixir could aid understanding too.
| cultofmetatron wrote:
| I built a whole startup in elixir from 0 to 1000+ active
| subscriptions. I don't know a lick of erlang.
| davidw wrote:
| That's pretty cool - what is it if you don't mind talking
| about it? How do you feel Elixir made it possible or easier.
| Or is it just something you happened to choose and you could
| have used Node or Rails or whatever else.
| OkayPhysicist wrote:
| You do not need to know much, if any, Erlang to be productive
| in Elixir. Some libraries you might call will be written in
| Erlang, but those tend to have been around long enough that you
| don't need to look inside. Being able to read the Erlang docs
| can be helpful, because the OTP has a ton of helpful functions,
| but that's mostly just learning what Erlang calls its types.
| moritz wrote:
| Maybe not Erlang the language, but it's useful to know its
| "philosophy" and what the BEAM is all about.
| arrowsmith wrote:
| It is absolutely 100% _not_ necessary to learn any Erlang at
| all before learning Elixir. I've been developing with Elixir
| for 5 years and still have never written a line of Erlang.
|
| You don't need to learn OTP at first either -- it'll just slow
| you down and confuse you. Learn Elixir syntax and semantics,
| learn how to build a Phoenix app or whatever, then dive into
| OTP once you're comfortable with the basics.
| cybrox wrote:
| We've been running Elixir in production for 5+ years and most
| of our team only know some very basic erlang data structures
| for working with the :dbg module on live systems.
|
| Erlang knowledge is not needed for building products with
| Elixir at all unless you want to go very in-depth.
| heeton wrote:
| ~5 year pro elixir here, various systems in production, I don't
| know any erlang.
| dzonga wrote:
| I have come to the simple conclusion that yeah if a tech is great
| and people are not launching products internally or as startups
| then maybe it's time to introspect.
|
| if using elixir supposedly gives a competitive advantage, why
| aren't companies using to launch new products - both existing and
| startups.
|
| a lot of those things quoted in the article are present on the
| jvm platform or through containers.
|
| and btw some of those companies listed have migrated away from
| elixir e.g brex and discord.
| thibaut_barrere wrote:
| Companies _are_ launching products with it ; that you aren't
| hearing about it is more about communication & leverage, than
| about their existence.
|
| A while back there was an effort to give more publicity on
| precise cases here https://elixir-lang.org/cases.html ; I think
| the effort is now moving to advertising the platform outside
| Elixir circles (e.g. more generalist conferences).
|
| FWIW, I'm working on https://transport.data.gouv.fr, Elixir-
| based since 2016, the National Access Point to transportation
| data, which includes a business specific reverse proxy with a
| 3x YoY growth, with no plans to migrate :-)
| wavemode wrote:
| There are a large number of companies using Elixir, in small or
| big ways: https://elixir-companies.com/en/companies
|
| Elixir also does not stand alone - the storied history of
| Erlang/BEAM in mission-critical distributed systems needs no
| introduction. Elixir lives within, and benefits from, that same
| ecosystem of libraries and tools.
|
| So yeah I'm not sure what you believe there is to "introspect"
| about, nor to what end.
| weatherlight wrote:
| 3 out of 5 of all the phone calls you've ever made was managed
| by a box somewhere running the Erlang VM (BEAM) which Elixir
| gets all its concurrency and parallelism from.
|
| And no, Discord has not moved away from Elixir. While they have
| adopted Rust for certain parts of their infrastructure, Elixir
| remains a core part of their backend, particularly for real-
| time communication and chat infrastructure.
| em-bee wrote:
| _maybe it 's time to introspect_
|
| to learn what? that the language was not good enough? that it
| wasn't marketed well enough? that there was not enough
| community support? not enough word of mouth?
|
| lisp users say they have a competitive advantage, as do
| smalltalk users. even pike at a time had a competitive
| advantage in that it was/is more performant than other similar
| languages.
|
| some of us in the pike community kept asking ourselves why pike
| is not more popular. the syntax is not obscure. roxen was a
| killer webdev server, 10 years ahead of its time. but no
| takers. why? (probably a mix of lack of marketing and community
| support/encouragement from the financial backers, but other
| languages become popular without backing, so what gives?)
|
| my point is that most times there is nothing you can do. unless
| you have the marketing power of sun (java) or google (go, etc),
| popularity of a language is mostly a case of luck and
| serendipity (ruby, python) or filling a unique need that no
| other language could (javascript, rust)
| cosmic_cheese wrote:
| I'm not so sure that popularity has any kind of correlation
| with capability, quality, viability, etc. That has more to do
| with marketing, social media trends, buzzword compliance, and
| what's caught the eye of the current crop of resume-driven
| developers and managers.
|
| Tools like Elixir which are focused on solving problems, aren't
| flashy or easy for web dev influencers (yes, they're a thing)
| to tout, and have a bit of higher barrier to entry are probably
| at a disadvantage in this way, even if they're actually quite
| good.
|
| This is why the industry is stuck on a revolving door of JS
| frameworks and the n-hundreth React self-reinvention. It's not
| about how good any of this actually is, it's about how well it
| scratches the itch for that new car smell while also being easy
| to pick up and make grand declarations on social media about.
| cpursley wrote:
| Fwiw, Claude 4 is really good with Elixir, including whipping up
| quality test suites.
| ch4s3 wrote:
| > whipping up quality test suites.
|
| YMMV, but I think it writes fine unit tests, but really sub par
| functional or end to end tests that need to check business
| logic. I think that's just a hard case for LLMS and not an
| elixir issue though.
| spike021 wrote:
| Can agree with this. I have had some funny hallucinations,
| though, where it mixes up Elixir keywords with totally
| unrelated to programming things and then acts very confident
| that said things are in Elixir. So you just need to be a bit
| skeptical and double-check it. But that goes with the LLM
| territory anyway.
| Jonovono wrote:
| Ya, it one shotted a Server driven ui app using elixir backend,
| expo with phoenix channels. Was impressed.
| ram_rar wrote:
| I have a ton of respect for Jose Valim and the Elixir core team,
| I have to say: Elixir just doesn't mesh well with the kind of
| infrastructure tooling that's become standard today. The
| ecosystem has been growing impressively and there's a lot to
| admire, but its philosophy often feels at odds with
| containerized, Kubernetes-based deployments.
|
| Elixir promotes a "do it all in one place" model--concurrency,
| distribution, fault tolerance--which can be powerful, but when
| you try to shoehorn that into a world built around ephemeral
| containers and orchestration, it starts to crack. The
| abstractions don't always translate cleanly.
|
| This opinion comes from experience: we've been migrating a fairly
| complex Elixir codebase to Go. It's a language our team knows
| well and scales reliably in modern infra. At the end of the day,
| don't get too attached to any language. Choose what aligns with
| your team's strengths and your production reality.
| ch4s3 wrote:
| If you can't get Elixir to work well in k8s, you're simply
| doing it wrong. Yeah you can build a lot of what k8s offers on
| the BEAM on a bare server but you don't have to at all. Elixir
| offers modern telemetry that works really well with pretty much
| any monitoring tool, and give you a lot of introspection into
| the internals of the VM if you need it. "Let it fail" works
| just fine in k8s, you can run a supervision tree in a container
| and have it manage process restarts internally just fine, its
| just an added layer of fault tolerance. Sure, you can't easily
| have long running stateful processes if you're doing a lot of
| blue-green deployments, but you probably don't need to do that
| most of the time.
|
| If you don't know Elixir and the BEAM well, of course you're
| going to have a bad time. That's true of any language.
| benmmurphy wrote:
| phoenix live view is effectively built around the assumption
| that the server process never dies and never restarts. its a
| very dubious model for a production deployment.
|
| > what happens when the server restarts / connection is lost
| / server dies?
|
| > you lose all of the current client state but you can work
| around this by persisting all the client state somewhere.
|
| > oh, so why am i using live view again?
| ch4s3 wrote:
| > phoenix live view is effectively built around the
| assumption that the server process never dies and never
| restarts.
|
| Not exactly, it's built to hold state in memory by default
| but doesn't assume how you want to handle deploys or server
| restarts. There's a built in restore mechanism for forms
| and it's trivial to shuffle state off to either the
| client/redis/your db[1]. You'd have the same problem if you
| were storing all your state in memory for any web
| application regardless of your library choice. Or you
| conversely have the problem that refreshing the page
| trashes client state.
|
| So there are two thinks here, you don't have to use
| live_view to use elixir or phoenix, and if you do you just
| need to actually think about how you're solving problems.
| The state can get trashed anywhere for any number of
| reasons. Tossing on the client and forgetting about it just
| moves the problem.
|
| [1] https://hexdocs.pm/phoenix_live_view/deployments.html
| benzible wrote:
| This isn't true. LiveView has buit-in form recovery:
|
| https://hexdocs.pm/phoenix_live_view/form-
| bindings.html#reco...
| jon-wood wrote:
| Sure, if your a company which is fully bought into ephemeral
| containers running on Kubernetes then Elixir is probably not
| going to be a great fit for you. I have once introduced it into
| a company like that and eventually the same thing happened, the
| application got rewritten in a language that fits the paradigm
| better.
|
| If I were starting a new company today though I'd probably go
| with Elixir, and then I simply wouldn't bother with containers,
| Kubernetes, and schedulers. Just run some servers and run the
| application on them, let them cluster, and generally lean into
| the advantages.
| em-bee wrote:
| most people/companies who think they need kubernetes don't
| actually need it. you are not google or amazon. and with
| erlang/elixir that's likely even more true.
| Towaway69 wrote:
| Elixir has a Ruby on Rails approach which is kind of all in
| one. Not everyone's cup of hot chocolate.
|
| Erlang is low level, lightweight processes and message passing
| - perfect for micro-services and containerisation.
|
| What Erlang lacks are high level web-oriented packages, i.e.
| markdown conversion, CSS and JavaScript packaging, REST (not
| quite true: cowboy is fantastic) - for which though Erlang was
| never intended.
|
| However the cool thing is that you can combine both in the same
| project, allowing you to have high level Elixir and low-level
| process management in one project. This is possible because
| both use the same virtual machine - BEAM.
| davidw wrote:
| Erlang isn't really that much lower level than Elixir. The
| Elixir syntax is just a bit different and they've improved a
| few things like string handling. Processes are still
| processes.
| lknuth wrote:
| We look at K8s more like "the Cloud Operating System". Many of
| its capabilities are more valuable for other runtimes, but that
| doesn't mean that Elixir is a bad fit with it.
|
| For example, the Erlang VM clustering can make use of K8s for
| Service Discovery. You can do ephemeral containers and use
| readiness probes to create a " hand over" period where new
| instances can sync their data from old, about-to-be-replaced
| instances.
| sisve wrote:
| Did you do hot updates? I ser that is mention in the post, but
| I thought the community has walked away from it? Or at least
| that its mixed feelings about it?
| ngruhn wrote:
| The only thing putting me off is the lack of static typing. But
| I'm open to be convinced that this doesn't matter.
| foxygen wrote:
| They are working on a type system.
| _acco wrote:
| It doesn't matter as much as you think. I believe this is in
| part due to how assertive most Elixir code tends to be. [1]
| These assertions not only aid the LSP and can cause compiler
| warnings/errors, they also help LLMs just like types do.
|
| Still, every release now contains new type system features.
| Next up is full type inference. [2] After that will be typed
| structs.
|
| [1] Jose Valim giving his balanced view on type systems:
| https://www.youtube.com/watch?v=giYbq4HmfGA
|
| [2] https://hexdocs.pm/elixir/main/changelog.html
| kingofheroes wrote:
| Pattern matching makes up for the lack of static typing for me.
| Combined with guard clauses it feels even stronger than static
| typing.
| Joker_vD wrote:
| > For those I managed to confuse, "glass-to-tin" just means
| "front-to-back" or "from the screen to the back end".
|
| So like a thin mirror? Which only serves to show the viewer back
| to themselves? And which also consists of just two extremely
| simple parts, that is, two panes/sheets of uniform materials, and
| nothing more?
|
| How do you even come up with _this_ metaphor for a web-based
| application? It 's horrible!
| matthewsinclair wrote:
| Sorry, it didn't land for you. It's something I've used for a
| while ("glass" for the screen, and "tin" for the back-end).
| Perhaps I'm showing my age or my Aussie slang. Thanks for
| reading, in any case!
| nichochar wrote:
| Elixir and Phoenix are very underrated.
|
| It combines the "opinionated" aspects of ruby and rails and the
| power of erlang. The BEAM is like no other runtime and is
| incredibly fun to work with and powerful once you get how to use
| genservers and supervision trees.
|
| We use Elixir for Mocha, and my one issue with it (I disagree
| with OP on this) is that live-view is not better than React for
| writing consumer grade frontends. I wish Phoenix took a much
| stronger integration with React approach, that would finalize it
| as the top choice for a web stack.
| 4b11b4 wrote:
| Any thoughts on Inertia for including React into the picture?
| jamauro wrote:
| Yeah it'd be nice if they had a mix task to include your js
| frontend of choice and it "just worked". Many have used inertia
| with success. I'm taking a different approach and pairing
| svelte with Phoenix channels.
| mike1o1 wrote:
| My current project is using React Native (for native and web)
| and getting GraphQL setup was initially a pain, but having
| React and GraphQL subscriptions gives me enough of the "live"
| functionality, but without having to worry about connection
| issues. With gql-tada, I get fully typed experience on the
| front-end too.
|
| If I didn't need native functionality, I'd probably just use
| the recently released `phoenix_vite`:
| https://github.com/LostKobrakai/phoenix_vite
| POiNTx wrote:
| Something like https://github.com/mrdotb/live_react might be
| what you're looking for.
| Dowwie wrote:
| being able to remote into the runtime, manage state and interact
| with internal BEAM processes is an amazing experience
| Towaway69 wrote:
| That's the BEAM and is common to Erlang, Elixir and Gleam.
|
| So it's not a feature specific to Elixir since the BEAM is the
| common virtual machine.
| Dowwie wrote:
| I'll take Elixir, thanks.
| Einenlum wrote:
| Am I the only one who never tried Elixir just because it has no
| strict typing? Seems very hard for me to go back to a language
| with dynamic typing. Maybe I'm just wrong and I should give it a
| try.
| michaelterryio wrote:
| I mean, lots of extremely talented and successful engineers,
| e.g., DHH, think strict typing is actually a negative. I think
| if you think strict typing is an absolute disqualifier, you
| should steelman the opposing side.
| Einenlum wrote:
| I tried both and I respect different opinions about this. I
| feel like TS' type system makes me crazy because it's going
| too far. But no typing makes me anxious. I guess there is a
| sweet spot to find for me personally.
| Towaway69 wrote:
| I prefer something like specs[1] that define a function's
| signature but isn't enforced by the compiler, instead the
| linter enforces them.
|
| This is what Erlang has and it's very convenient since once
| a design is fixed, I end up writing a spec to remind me
| what types the function expects.
|
| [1] = https://www.erlang.org/doc/system/typespec.html
| blipmusic wrote:
| His "argument" _for_ strict typing on the Lex Fridman podcast
| was also that it 's mostly if you have "hundreds or (of?)
| thousands of engineers collaborating", which "strictly" puts
| his opinion in the bin in my case. I have absolutely,
| positively become more productive as a _single_ developer due
| to strict typing. Parsing various kinds of binary data was
| enough to convince me. A.k.a. each to their own. On the
| whole, Elixir and BEAM seem really cool though, and there 's
| work being done on typing, as well as the new Gleam language.
|
| Note: I've not yet done any serious web-development, mostly
| command line tools, which I realise is not DHH's main focus.
| williamdclt wrote:
| I used it being a big proponent of the TS type system and I
| definitely missed it greatly.
|
| They are actively shipping a type system for Elixir though,
| which as far as I understand is pretty similar to TS so, great!
| codyb wrote:
| Type systems in this space seem to take a long time and never
| quite reach completeness. At least that's the experience I've
| taken away from occasionally glancing at Erlang's Dialyzer
| project every now and again which I don't think has ever
| reached any semblance of the maturity of something like
| TypeScript.
|
| But pattern matching in Erlang does do a lot of the heavy
| lifting in terms of keeping the variable space limited per
| unit of code which tends to reduce nesting and amount of code
| to ingest to understand the behavior you care about at any
| moment.
| lknuth wrote:
| It is alleviated quite a bit bz its pattern matching
| capabilities combined with the "let it crash" ethos.
|
| They have a success typing system (which isn't very good) and
| are working on a fuller system (which isn't very mature).
|
| If typing is the only thing keeping you out, have a look at
| Gleam.
|
| Having worked with Elixir professionally for the last six years
| now, it is a very mature platform, very performant and offers
| many things that are hard in other languages right out of the
| box.
| Einenlum wrote:
| Thanks for your answer! I already checked Gleam several times
| and it looks amazing. The ecosystem just doesn't feel mature
| enough for me yet. But I can't wait for it to grow.
| lknuth wrote:
| True. There is inter-op with both Elixir and Erlang, but
| thsts like early TypeScript.
|
| If you're at all interested, I'd suggest doing the basic
| and OTP tutorials on the Elixir Website. Takes about two
| hours. Seeing what's included and how it works is probably
| the strongest sails pitch.
| the_gastropod wrote:
| Elixir is a _strongly typed_ language (as opposed to a weakly
| typed language like JavaScript or Perl). You cannot, for
| example, do ` "4" - 1` in Elixir. Dynamic vs static typing is a
| mostly orthogonal scale, where Elixir is (mostly) dynamically
| typed.
|
| There are some very sharp Computer Scientists who believe
| static typing is unnecessary. Joe Armstrong (co-designer of
| Erlang) once said: "a type system wouldn't save your system if
| it were to get hit by lightning, but fault tolerance would"
| dminik wrote:
| Tbh, the strongly typed and dynamically typed combination
| seems like the worst option.
|
| You get zero help and punished hard for failing.
| throwawaymaths wrote:
| nah you just get log lines. crash is not as bad as you
| think it is.
| dminik wrote:
| I mean, it is a kind of a bug that is easy to prevent
| with a static type checking, but also one that will
| always (or almost always) get triggered.
|
| Log lines are whatever, but a system that goes into a
| crash loop or fails on most requests isn't great.
| em-bee wrote:
| how so? most dynamically typed languages are also strongly
| typed. that includes python, ruby, common lisp,
| smalltalk... if it was the worst option, this would not be
| the case.
| dminik wrote:
| A casual look at the history of basically anything will
| tell you that the best option isn't necessarily always
| the one that succeeds.
| em-bee wrote:
| sure, but when the majority of popular languages use that
| paradigm then it surely can't be the worst option either.
| what is it that makes it a bad combination?
| dminik wrote:
| Please, smalltalk and common lisp don't qualify as
| popular languages.
|
| I don't want to look at TIOBE, so let's look at the stack
| overflow survey from 2024.
| https://survey.stackoverflow.co/2024/technology#admired-
| and-...
|
| Strong + Static: TypeScript, Java, C#, C++, Go, Rust,
| Kotlin, Dart, Swift, Visual Basic, Scala
|
| Weak + Static: C
|
| Strong + Dynamic: Python, Lua, Ruby, R, GDScript(*)
|
| Weak + Dynamic: JavaScript, PHP, Matlab, Perl
|
| At this point I'm reaching into the low percentages. I
| think it's pretty clear that Strongly + Statically typed
| languages are massively over-represented on the list.
|
| Both Strongly and Weakly Dynamically typed languages are
| similarly represented.
|
| Note: I'm open to editing the comment to move languages
| from and to various categories. I haven't used many of
| them, so correct me if I'm wrong.
| em-bee wrote:
| _smalltalk and common lisp don 't qualify as popular
| languages_
|
| not anymore. they were very popular in the industry at
| one point. very few other languages have so many
| independent implementations as smalltalk and lisp. a
| testament to their wide spread use in the past.
|
| _Strong + Static: TypeScript; Weak + Dynamic:
| JavaScript_
|
| that doesn't make sense. typescript is javascript with
| types, it can't be both strong and weak at the same time.
|
| but i believe we have a different definition of weak.
| just because javascript, php and perl have some implicit
| type conversions doesn't make them weakly typed. i
| believe it takes more than that. (in particular that you
| can't tell the type by looking at a value, and that you
| can use a value as one or another type without any
| conversion at all)
|
| C is weakly typed, it was always a major criticism, C++
| too i think (less sure about that).
|
| once you correct for that you will notice that all
| languages in the strong and static category are less than
| 30 years old and many are much younger. (java being the
| oldest. but there are older ones like pike which is also
| strong and static and goes back to 1991)
|
| the strong and dynamic category goes back at least a
| decade more. (if you include smalltalk and lisp)
|
| what this does show is that static typing has experienced
| a renaissance in the last two decades, and also the worst
| is really using any form of weak typing.
|
| i still don't get what makes strong and dynamic a bad
| combination, other than it's bad because it is not
| static.
| dminik wrote:
| I mean, if you define weak like that, then yeah. But
| also, what languages are you left with? Assembly? Then
| again, it does fit with your definition of popular being
| popular 45 years ago. Tbh, I'm not sure if smalltalk was
| ever even popular. It was certainly influential, but
| popular?
|
| I know that there are discussion about what strong vs
| weak even means, but I think most people would place the
| weak distinction way above yours on a possible weak-
| strong spectrum.
|
| C can certainly be argued to be weak. My understanding is
| that it's mostly due to pointers (and void* especially).
| C++ is much better in this regard. I mostly just did not
| want to add a Weak + Static category just for one
| language.
|
| Well, now that you've defined Strong to also include all
| of the languages I consider Weak, then yeah, no issues at
| all.
| iLemming wrote:
| > smalltalk and common lisp don't qualify as popular
| languages.
|
| Sure, Smalltalk isn't, but Lisp is a different story. In
| this context I assume we all mean to say "Lisp" and not
| "Common Lisp" specifically.
|
| Lisp (as the entire family of PLs) is quite massively
| popular.
|
| Standard rankings have major blind spots for Lisp
| measurement, they miss things like, for example, Emacs
| Lisp is everywhere. There's tons of Elisp on GitHub
| alone, and let me remind you, it's not a "general-
| purpose" language, its sole function is to be used to
| configure a text editor and there's mind-boggling amount
| of it out there. AutoLISP is heavily used in
| CAD/engineering but rarely discussed online. Many Lisp
| codebases are proprietary/internal. Also, dialect
| fragmentation artificially deflates numbers when measured
| separately - many rankings consider them different
| languages.
|
| If you count all Lisp dialects together and include:
| Emacs Lisp codebases, AutoLISP scripts in engineering,
| Research/academic usage, Embedded Lisps in applications,
| Clojure on JVM and other platforms - babashka scripts,
| Flutter apps, Clojurescript web apps, etc;
|
| ...Lisp would likely rank much higher than typical
| surveys suggest - possibly in the top ten by actual lines
| of code in active use.
| coffeeindex wrote:
| Seems a bit strange to posit fault tolerance as an
| alternative to a type system. Personally, I view type systems
| as a bonus to DX more than something strictly designed to
| prevent errors
| pmarreck wrote:
| It's in line with the erlang philosophy of letting things
| crash trivially and restart instantly. Due to the universal
| immutability, starting a new process from a given state in
| Erlang/Elixir is nearly instantaneous and has extremely
| little overhead as they are not OS threads, they are BEAM
| VM threads.
|
| Very opposite the Go model, btw.
| tossandthrow wrote:
| Letting you wrong computations crash does not make them
| right.
| pmarreck wrote:
| LOL. This only makes sense if you can know all the ways
| your code will fail... which you cannot.
|
| Erlang/Elixir's approach is to simply say, "It's gonna
| fail no matter how many precautions we take, so let's
| optimize for recovery."
|
| Turns out, this works fantastically in both cellphone
| signaling, which is where OTP originated, as well as with
| webserving, where it is perfectly suited.
| tossandthrow wrote:
| I don't know who are arguing with? Everyone loves the
| otp.
|
| It just does not catch logics errors.
| em-bee wrote:
| whether that matters or not depends on whether the logic
| error occurs because of a rare combination of events or
| as a result of a certain state and whether that state
| remains after recovery. if there is for example a logic
| error that causes the app to crash after say 10 minutes
| of runtime, or eg. at a certain message size, then a
| recovery will reset the runtime and it will work again.
| it will of course invariably fail again after another 10
| minutes or when the same message is resent, because it is
| a logic error, and logic dictates that the error won't go
| away no matter how often you restart, but it will work in
| the meantime.
|
| in other words, any error that doesn't occur right at
| start can be recovered from at least for all those
| operations that do not depend on that error being fixed.
| tossandthrow wrote:
| This sound like a wild and very contrived argument.
|
| Both because that memory leaks are normal is types
| languages - and does usually not matter in most serious
| applications - and because this class of errors is
| usually not what types catch.
|
| Types have value when you 1) refactor and 2) have
| multiple people working on a code base.
|
| The error you see when you don't have types is something
| like a BadArityError.
| never_inline wrote:
| To restart and fail again? How does that help with logic
| errors caused by wrong type objects?
| victorbjorklund wrote:
| Depends on the error. Lets say it is an error that
| happens once every 1 million users.
| pmarreck wrote:
| It doesn't prevent the error, but it also won't take down
| your server when malicious users (or just lots of normal
| users) start to bang on that input with the problem, and
| your non-BEAM VM pool starts to run out of available
| preloaded stacks... You get a new Erlang process in well
| under a millisecond on modern hardware
|
| It WILL log the error, with a stacktrace, so you have
| that going for you
|
| Note that even with typing, you cannot avoid all runtime
| errors
|
| Also note that this tech was first battle-tested on
| cellphone networks, which are stellar on the reliability
| front
| tossandthrow wrote:
| While I greatly appreciate elixir it is completely malplaced
| to contrast fault tolerance and type systems - they solve
| very different needs.
|
| As such fault tolerance does not guarantee that you MRI
| scanner does not kill your patients.
|
| You likely want both.
| throwawaymaths wrote:
| no, but effort is a finite resource so it justifies why
| they didn't bother.
| tossandthrow wrote:
| Well, the people behind elixir seems to have accepted
| that typing is necessary.
|
| I see this story on an on: some hacker makes a language,
| they hate types because they want to express themselves.
| The languages gets traction. Now enterprise application
| and applications with several devs use it and typing gets
| essential - types will then gradually be added.
| throwawaymaths wrote:
| sure, a few years behind typescript/mypy isnt really so
| bad for a language without a microsoft or a google behind
| it, is all im saying.
| tossandthrow wrote:
| > isnt really so bad for a language without a microsoft
| or a google behind it, is all im saying
|
| What? Elm was literally the result of a single grad
| students side project - elm incorporates both a sound
| type system and FRP.
|
| This has nothing to do with time. It was a _decision_ not
| to support it.
| bccdee wrote:
| Okay? But "the features you need would have taken effort
| to implement, so we didn't implement them" is not a very
| good sales pitch when you're trying to convince me to use
| your tool to do my job.
| throwawaymaths wrote:
| ok. don't use it then. but be aware: your attitude is why
| things get stuck in (sometimes really awful) local minima
| in tech.
| bccdee wrote:
| Any tool that justifies the choice not to implement an
| important and highly-requested feature with "effort is a
| finite resource" alone is not viable for serious
| development work. It's not prioritizing, it's a refusal
| to prioritize.
| OkayPhysicist wrote:
| It's likely Armstrong conflated the two there because a
| significant part of the fault tolerance of Erlang comes
| from the loose coupling via message passing between
| components, which in no small part is tied to the dynamic
| typing. It's a Postel's law thing, being generous in what
| you accept and strict about you send.
|
| Elixir's seamless pattern matching paradigm, IMO, largely
| negates the need for strict typing. If you write your
| function signatures to only accept data of the type / shape
| you need (which you are incentivized to do because it lets
| you unpack your data for easy processing), then you can
| write code _just_ for the pretty path, where things are as
| expected, and do some generic coverage of the invalid
| state, where things aren 't, rather than the norm in
| software development of "I covered all the individual
| failure states I could think of". This generic failure mode
| handling, too, greatly benefits from dynamic typing, since
| in my failure state, I _by definition_ don 't know exactly
| what the structure of my inputs are.
| tossandthrow wrote:
| Yep, I have written and maintained several large scale
| applications In elixir and live the computation model.
|
| However,elixir depreately needs proper types. IMHO the
| needs for types are in no means negated by pattern
| matching, and I also see hints at why you would say so.
|
| > If you write your function signatures...
|
| The point of types is worry less refactoring.
|
| If you work at a place where you can define the arhicture
| for the entire lifecycle of the application without ever
| needing to Refactor, then sign me up! I want to work
| there.
| bccdee wrote:
| I've never had a system crash from a lightning strike, fault-
| tolerant or otherwise. I have had systems crash from null
| pointer errors though, and fault-tolerance did nothing to fix
| that except turn a crash into a crashloop.
|
| I have the same attitude toward overly permissive type
| systems that I do toward the lack of memory safety in C:
| People sometimes say, "if you _do it right_ then it isn 't a
| problem," but since it objectively IS a problem in practice,
| I would rather use the tool that eliminates that problem
| entirely than deal with the clean-up when someone inevitably
| "does it wrong."
| bluesnowmonkey wrote:
| We had a cluster of servers, dynamically scaling up and
| down in response to load, and one day started seeing errors
| where an enum string field had an impossible value. Imagine
| the field is supposed to be "FOO" or "BAR" but one day in
| the logs you start seeing "FOO", "BAR", "GOO", and "CAR".
| Impossible. "GOO" and "CAR" did not exist in the code,
| nothing manipulated these strings, yet there they were.
|
| Long story short, a particular machine that joined the
| cluster that morning had some kind of CPU or memory flaw
| that flipped a bit sometimes. Our Elixir server was fine
| because we were matching on valid values. Imagine a typed
| language compiler that makes assumptions about things that
| "can't" happen because the code says it can't... yet it
| does.
| rendaw wrote:
| I tried it for a job interview, and it was awful - because of
| no static typing. I spent most of my time tracking down dumb
| type errors, compounded by various language footguns (I can't
| remember exactly, but I think for example making a typo on a
| field name in a for loop condition is treated as "condition
| false" and so the for loop just doesn't do anything, no error).
|
| It seems like the Elixir/Erlang community is aware of this, as
| is Ruby, but it's a rather large hole they have to dig
| themselves out of and I didn't feel particularly safe using the
| tools today.
|
| I've heard a lot of good things about the Erlang runtime and I
| did really like Elixir's pipe operator, so it was unfortunate.
| kingofheroes wrote:
| Pattern matching makes up for the lack of static typing to
| me. It provides nearly all the same benefits especially when
| used with guard clauses.
| jamauro wrote:
| Generally I find static typing to be overrated, even more so
| with elixir due to pattern matching and immutability. I think
| elixir's set-theoretic types will be a nice addition and will
| provide some compile-time safety checks without needing to
| explicitly define types for everything. It remains to be seen
| how far they'll take this approach.
| throwawaymaths wrote:
| really you wind up making only a handful of type errors that
| make it into prod.
|
| there are other things that contribute to this like pretty
| universal conventions on function names matching expected
| outputs and argument ordering.
|
| it does suck hard when library authors fail to observe those
| conventions, or when llms try to pipe values into erlang
| functions, and yes, it WOULD be nice for the compiler to
| catch these but you'll usually catch those pretty quickly.
| you're writing tests (not for the specific reason of catching
| type errors), right? right?
| victorbjorklund wrote:
| I let the LLM write my tests. And when they fail it just
| rewrites the tests to pass.
| davidclark wrote:
| Well written typespecs + dialyzer catches most things you'd
| want to catch with a type system:
| https://hexdocs.pm/elixir/typespecs.html
|
| There is also pattern matching and guard clauses so you can
| write something like:
|
| def add(a, b) when is_integer(a) and is_integer(b), do: a + b
|
| def add(_, _), do: :error
|
| It's up to personal preference and the exact context if you
| want a fall through case like this. Could also have it raise an
| error if that is preferred. Not including the fallback case
| will cause an error if the conditions aren't met for values
| passed to the function.
| arrowsmith wrote:
| Imo this complaint is really overrated:
| https://arrowsmithlabs.com/blog/you-might-not-need-gradual-t...
| Jonovono wrote:
| > But honestly, I've always felt like this objection was
| overblown. I've got nothing against static typing; some of my
| best friends use statically-typed programming languages.
|
| lol
| victorbjorklund wrote:
| Maybe try Gleam? 80% of the goodies of Elixir is the BEAM
| anyway and you get that in Gleam too.
| harrisi wrote:
| I believe you meant static typing. There's active ongoing work
| in this space, and Elixir is actually gradually typed now. You
| can read more about it in the docs:
| https://hexdocs.pm/elixir/gradual-set-theoretic-types.html
| ludicity wrote:
| It's not so bad in Elixir for various reasons. Firstly, they're
| doing some work on set-theoretic types.
|
| https://hexdocs.pm/elixir/main/gradual-set-theoretic-types.h...
|
| There's also tooling like dialyzer, and a good LSP catches a
| lot too. The language itself has some characteristics that
| catch errors too, like pattern matching and guard clauses.
|
| With all that said, I'm still very keen for static typing. In
| the data world we mostly start with Python without mypy, and
| it's pretty hard to go back.
| bsder wrote:
| One of the problems with strict typing is that it makes it very
| difficult to hot upgrade a function to a different signature.
|
| Erlang OTP relies on being able to swap to new functions to do
| upgrades without downtime.
| iLemming wrote:
| > Maybe I'm just wrong
|
| Yes you are. First of all there isn't such a thing as "strict
| typing", types are either static/dynamic and/or strong/weak. I
| suppose you meant Elixir has no static types. It is however a
| strongly typed language.
|
| And just like it usually happens, static typing enthusiasts
| often miss several key insights when confronting dynamically
| typed languages like Clojure or Elixir (which was inspired by
| ideas implemented in Clojure).
|
| It's not simply "white" and "black", just like everything else
| in the natural world.
|
| You have to address:
|
| - Runtime flexibility vs. compile-time safety trade-offs --
| like most things, things have a price to it, nothing is free.
|
| - Different error handling philosophies. Sometimes, designing
| systems that gracefully handle and recover from runtime
| failures makes far more resilient software.
|
| - Expressiveness benefits. Dynamic typing often enables more
| concise, polymorphic code.
|
| - Testing culture differences. Dynamic languages often foster
| stronger testing practices as comprehensive test suites often
| provide confidence comparable to and even exceeding static type
| checking.
|
| - Metaprogramming power. Macros and runtime introspection
| enable powerful abstractions that can be difficult in
| statically typed languages.
|
| - Gradual typing possibilities. There are things you can do in
| Clojure spec that are far more difficult to achieve even in
| systems like Liquid Haskell or other advanced static type
| systems.
|
| The bottom line: There are only two absolutely guaranteed ways
| to build bug-free, resilient, maintainable software. Two. And
| they are not static vs. dynamic typing. Two ways. Thing is - we
| humans have yet to discover either of those two.
| maratc wrote:
| Elixir's syntax is very intimidating. We maintain a fork of
| "bors-ng", I'd very much like to hack around a fix or two, but
| just stare at the code in awe.
| asib wrote:
| What part of the syntax is intimidating? To my mind, it's not
| all that dissimilar from e.g. Python, which is not a language
| about which people express the same feeling.
| cybrox wrote:
| Structure and control flow feels very Python/Ruby-ish,
| however, when you get into the depths of pattern matching and
| binary deconstruction or even macros, Elixir syntax can
| become somewhat messy. However, the same concepts, once
| understood, are extremely powerful for parsing or protocol
| handling.
|
| Talking about stuff like this: nodes =
| node_data |> Input.split_by_line(trim: true)
| |> Enum.map(fn << t::binary-
| size(3), " = (",
| l::binary-size(3), ", ",
| r::binary-size(3), ")"
| >> -> {t, {l, r}} end)
| |> Enum.into(%{})
| OkayPhysicist wrote:
| One thing the author didn't mention is how incredibly polished
| the primary ecosystem of documentation, standard library, and
| tooling is. The Elixir standard library is _incredibly_
| consistent in order to support Elixir 's piping operator, such
| that the first argument will basically always be the information
| you want passed from the function before it. In comparison, I
| frequently have to check the docs to confirm argument order on
| any lesser-used function in Python, Javascript, or C#. Then
| there's the fact that the second-layer of standard library, the
| OTP inherited from Erlang, which is expansive to the point of
| containing _most_ things you 'd want to do on a server. The
| documentation, in turn, is the gold standard that I (typically
| negatively) compare all other language docs to. It's organized,
| discoverable, and covers not just the "what" but the "How" and
| "Why" exceptionally well, not just at the function level, but the
| module layer as well. Frankly, only MDN comes close. All
| combined, it's just an incredibly productive language.
| nanna wrote:
| Am I the only person who is put off by Elixir by the lack of
| S-expression syntax?
|
| I decided to learn Clojure for my next language.
| em-bee wrote:
| while i love s-expressions, i am not aware of any language
| outside the lisp ecosystem that supports it natively. are you
| saying that you are put off that elixir is not lisp?
|
| i am interested in clojure, but i am put off by it using the
| java run time. ;-)
| iLemming wrote:
| > i am interested in clojure, but i am put off by it using
| the java run time
|
| Clojure runs not only on Java - you have Clojurescript, you
| have babashka and nbb, you have Clojure-Dart -- if interested
| in building Flutter apps, you can even use Clojure with
| Python libs. If you need to target Lua, there's Fennel, which
| is similar as it's inspired by Clojure.
|
| For me - Clojure is a hands-down best medium for data
| manipulation - there's just nothing better out there to
| explore some data - investigate APIs; sort, group, dice and
| slice any kind of data - CSVs, JSON, etc. Nothing else simply
| can match the joy how one could incrementally build up
| complex data transformations, it makes it incredibly
| productive for the "let me just quickly check this shit"
| scenarios that can easily turn into full analyses. REPL-
| driven nature of it makes it so much fun - you feel like
| you're playing a videogame.
|
| I honestly wish every programmer knew at least some Clojure.
| I lost count of how many times I gave up on figuring out
| complex jq syntax and reached for Clojure instead. Or the
| times I'd quickly build a simple Playwright script for
| reproducible web-app bug trapping or quick data scraping that
| saved me hours of frustration and manual clicking.
| aeonik wrote:
| There's also
|
| Fennel -> Lua
|
| Jank -> C++
| Jtsummers wrote:
| Considering the vast majority of languages don't use s-exprs,
| possibly. There aren't many hardcore lispers who refuse to use
| anything but s-exprs.
| iLemming wrote:
| > Am I the only person
|
| No, you're not alone. After learning Lisp, structural editing
| and REPL-driven-development, I just don't feel like needing to
| learn new languages no matter how powerful they seem to be.
| Lisps like Clojure are highly pragmatic and offer something
| fundamentally different from the endless parade of syntax-heavy
| languages that dominate the mainstream.
|
| Once you've experienced the fluidity of paredit or parinfer,
| where you're editing the _structure_ of your code rather than
| wrestling with textual representations, going back to manually
| balancing brackets, fixing indetnation and carefully placing
| semicolons feels like reverting to a typewriter after using a
| word processor. The code becomes malleable in a way that 's
| hard to appreciate until you've lived with it.
|
| And the REPL changes everything about how you think and work.
| Instead of the write-compile-run-debug cycle, you're having a
| conversation with your running program. You can poke at
| functions, test hypotheses, build up solutions incrementally,
| and see immediate feedback. It's exploratory programming in the
| truest sense - you're not just writing code, you're discovering
| it.
|
| The homoiconicity - code as data - means you're working in a
| language that can easily reason about and transform itself.
| Macros aren't just text substitution; they're proper AST
| transformations. This gives you a kind of expressive power that
| most languages can't match without tremendous complexity.
|
| So when the latest trendy language appears with its new syntax
| and novel features, it often feels like rearranging deck
| furniture. Sure, it might have nice type inference or clever
| concurrency primitives, but you're still stuck in the old
| paradigm of fighting syntax and losing the conversational flow
| of development.
|
| You've tasted something closer to the pure essence of
| computation, and it's hard to go back.
| amarsahinovic wrote:
| There is Lisp Flavoured Erlang https://lfe.io/ created by
| Erlang co-inventor Robert Virding.
| danman114 wrote:
| Hi! I recently tried to get into Elixir as an antidote to an
| acute javascript-fatigue...
|
| To my surprise this there isn't really a good mobile story to
| build mobile apps for both Android and iOS with it, although it
| looks like it could be a great option for quick turnaround mobile
| apps with a web- or native frontend...
|
| I know that there is something being worked on, eg. LiveView
| native: https://native.live/ , but that seems to target two
| entirely different frontend frameworks, one for each platform...
|
| I started using capacitor as a wrapper for a HTML frontend, but I
| think I might potentially run into trouble when I'd try to move
| into production builds...
|
| I think there's some space for research and maybe some nice
| starter packs / tutorials there... Because I think it is a big
| and pretty relevant market for browser-based apps, which Elixir
| seems to be very well suited to!
|
| I'm grateful for any additional pointers, peace out! :)
| KevinMS wrote:
| Some don't use it because the performance on anything other than
| IO is just bad. This isn't just because its "not compiled", but
| because it has a scheduler taking up cycles and it enforces
| immutability, when can be brutal for some tasks when mutability
| can really speed things up.
| matthewsinclair wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=44495879
| kingofheroes wrote:
| I just started learning Elixir recently and I'm honestly loving
| it. Pattern matching is awesome and how it approaches concurrency
| and async work was so easy to wrap my head around. Pragmatic
| Studios has a great tutorial.
___________________________________________________________________
(page generated 2025-07-23 23:00 UTC)