Why Elixir? Common misconceptions
matthewsinclair.com256 points by ahamez 4 days ago
256 points by ahamez 4 days ago
I've been writing Elixir on-and-off since 2017 for personal projects and since 2024 professionally, at a big tech company.
The two experiences couldn't be more different. While I loved the great development speed for my personal projects, where I am writing more code than reading it, joining an existing project needs the opposite, reading more code than writing it. And I can only repeat what many people say, dynamic typing makes this so much more difficult. For most code changes, I am not 100% certain which code paths are affected without digging a lot through the code base. I've introduced bugs which would have been caught with static typing.
So in my conclusion, I'm bullish on gleam, but also on other (static) languages embracing the cooperative green-thread/actor model of concurrency like Kotlin (with JVM's virtual threads). (On another note, I personally also dislike Phoenix LiveView and the general tendency of focusing on ambiguous concepts like Phoenix Context's and other Domain Driven Design stuff)
I worked a year or so at an Elixir shop, and this mirrors my experience. I had to navigate to call sites to understand what I was being passed and type hints were not sufficient. Dynamic typing fails larger orgs/teams/codebases.
Fun to develop and solo administer. Small teams with a well known codebase can do amazing things. I work at orgs with multiple teams and new hires who don't know the codebase yet.
For me, the sweet spot is Go.
Out of curiosity, at the tech company, did the team use typespecs and dialyzer?
The lack of type hint for function parameters is definitely a productivity killer (in my case).
There are type hints for function parameters. With some care and guards, Dialyzer can be somewhat helpful.
What actually drove me nuts was absence of guards and meaningful static analysis on return values. Even in my small but nontrivial personal codebase I had to debug mysterious data mismatches after every refactor. I ended up with a monad-like value checking before abandoning Elixir for my compiler.
Fully agree with this based on similar experiences. IME most devs hired without previous Elixir/Phoenix experience don’t end up liking the tech stack very much, even though they become productive quite quickly and don’t struggle too much with Elixir. A lot of Elixir/Phoenix fans make the mistake of thinking that everyone is going to love it as much as they do once they get up to speed.
Isn't there some kind of optional typing in Elixir?
What you're describing are the same uncertainties I've used to have writing PHP a long time ago, but since using optional types and PHPStan checker, it kind of serves as a compiler pass that raises those issues. The benefit being that I still can be lazy and not type out a program when I prototype the problem on my first pass.
>Isn't there some kind of optional typing in Elixir?
It’s in the works and recent versions of the compiler already catch some type errors at compile time, but it’s nothing remotely close to what you get from Typescript, or from any statically typed language like Go, Rust, Java, etc.
> Isn't there some kind of optional typing in Elixir?
Sort-of. Developers provide typespec which is like a hint and use dialyzer to find issues before runtime.
I am now super curious which big tech company is betting on Elixir?
Nubank, Latin America's most valuable bank, relies heavily on Elixir and even acquired Plataformatec, the company where Elixir was created.
A blog post by them about this: https://building.nubank.com/tech-perspectives-behind-nubanks...
Wasn't Nubank the Clojure posterchild not long ago?
Are they moving from Clojure to Elixir, or adding it?
The referenced post is from 2020, and nubank still posts clojure content and sponsors the big clojure conference, so I’d be shocked if they were dropping clojure.
Their tech stack is probably enormous, it wouldn’t surprise me if they’re using both for different things
Also the referenced post is about them acquiring plataformatec, not about using elixir. Jose Valim (the creator of elixir) left plataformatec after the nubank acquisition in order to continue developing elixir, I've never heard of nubank using elixir, afaik they're solidly a clojure shop with no plans on changing.
it's just an internal I/O-bound project, where BEAM concurrency makes lots of sense. Grown from an engineer's side project as it was useful and working well, not a company-wide effort to bet on Elixir
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.
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.
> combined with the "let it crash" ethos
I see this phrase around a lot and I wish I could understand it better, having not worked with Erlang and only a teeny tiny bit with Elixir.
If I ship a feature that has a type error on some code path and it errors in production, I've now shipped a bug to my customer who was relying on that code path.
How is "let it crash" helpful to my customer who now needs to wait for the issue to be noticed, resolved, a fix deployed, etc.?
>How is "let it crash" helpful to my customer who now needs to wait for the issue to be noticed, resolved, a fix deployed, etc.?
Let it crash is more about autorestarting and less about type bugs. If you have a predictable bug in your codepath that always breaks something, it just means you never tested it and restarting will not fix it. But this kind of straightforward easy to reproduce bugs are also easy to test the hell out of.
But if you have a weird bug in a finite state machine that gets itself into a corner, but can be restarted -- "let it crash" helps you out.
Consider hot reload -- a field exists in a new version of a record, but doesn't exist in a old one. You can write a migration in gen server to take care of it, but if you didn't and it errored out, it's not the end of the world, it will restart and the problem will go away.
I wonder what production monitoring is like for that. Does Elixir have a good monitoring platform like NewRelic for tracking the state of these processes?
Elixir has OpenTelemetry bindings which integrate into most of these platforms. At work, we use DataDog.
The core of a properly built, resilient/robust system is that you have compartmentalized code into different small erlang processes. They work together to solve a problem. A bug in one is isolated to that particular process and can't take the whole system down. Rather, the rest of the system detects the problem, then restarts the faulty process.
The reason this is a sound strategy is that in larger systems, there will be bugs. And some of those bugs will have to do with concurrency. This means a retry is very likely to solve the bug if it only occurs relatively rarely. In a sense, it's the observation that it is easier to detect a concurrency bug than it is to fix it. Any larger system is safe because there's this onion-layered protection approach in place so a single error won't always become fatal to your system.
It's not really about types. It's about concurrency and also distribution. Type systems help eradicate bugs, but it's a different class of bugs those systems tend to be great at mitigating.
However, if you do ship a bug to a customer, it's often the case you don't have to fix said bug right away, because it doesn't let the rest of the application crash, so no other customer is affected by this. And you can wait until the weekend is over in many cases. Then triage the worst bugs top-down when you have time to do so.
In addition to the other fine replies, it helps to remember that Erlang/BEAM, and by extension Elixir, comes from the telephony world. If something crashes in that world, you'd far rather terminate a phone call spuriously than bring the whole system down. (And in the 1990s, when the main alternative was C, and not just C as it may be today but 1990s C specifically, that was a reasonable concern.) Erlang is optimized for a world where that's a reasonable response to a failure. I've also used it in a context where a system makes a persistent connection up to a controller, and if either side crashes they automatically reconnect. "Let it crash" is a reasonable response to a lot of issues that can arise.
The farther you get from that being an issue, the less useful the "let it crash" philosophy becomes, e.g., if I hit "bold" in my word processor and it fails for some reason, "let it crash" is probably not going to be all that helpful overall.
I have seen systems that "should" have been failures in the field be held together by Erlang's restart methodology. We still had to fix the bugs, but it bought us time to do it and prevented the bad deployments from being immediate problems. But it doesn't apply to everything equally by any means.
Okay but “static typing avoids the crash to begin with”, is what everybody from the static typing world is thinking reading all these very long responses that don’t address this very basic idea.
I like to measure languages by "what do I miss when I leave them".
I used Erlang professionally for about 5-6 years.
I have not missed "let it crash".
It's an interesting idea that should be grappled with, but Erlang users have this tendency to very badly strawman their opposition and spout their propaganda like it's still 2005 and the rest of the world has just been twiddling their thumbs, gormlessly ramming into brick walls as they scale up and are just flabbergasted about how to handle the problems of scale, when in fact, to a first approximation all of the large systems in the world that are reliable are also not written in BEAM. There are other solutions to the problem. Strong types are a big component of how I deal with this in my current code, yes. It's not 100% a solution, but then, I can have both anyhow so I generally do.
I was just providing context. When trying to understand BEAM it is always helpful to have in the back of your head that it was written for telephony, with all that implies.
A discussion by Joe is helpful here; It contains some code: https://erlang.org/pipermail/erlang-questions/2003-March/007...
"Crashing is loud" below is a phrase to combine with "remote error recovery" from the link above. Erlang/OTP wants application structure that is peculiar to it, and makes that structure feel ergonomic.
> If I ship a feature that has a type error on some code path ... How is "let it crash" helpful to my customer?
The crash can be confined to the feature instead of taking down the entire app or corrupting its state. With a well-designed supervision structure, you can also provide feedback that makes the error report easier to solve.
However, while a type error in some feature path is a place that makes type annotations make sense, type annotations can only capture a limited set of invariants. Stronger type systems encode more complex invariants, but have a cost. "Let it crash" means bringing a supervisor with simple behavior (usually restart) or human into the loop when you leave the happy path.
> "Let it crash" means bringing a supervisor with simple behavior (usually restart) or human into the loop when you leave the happy path.
If a "human" has to enter the loop when a crash occurs, this limits the kind of system you can write.
I had to work on a system where a gen server was responding to requests from a machine, sent frequently (not high frequency, but a few times per second.) If for some reason the client misbehaves, or behaves properly but happens to use a code path that has a type error, the only option given by "let it crash" was to, well... crash the actor, restart the actor, then receive the same message again, crash the actor, restart the actor, etc... and eventually you crash the supervisor, which restarts and receives the same message, etc...
Let it crash definitely wasn't meant to be a cover for poorly typed code.
It's much more suitable as a replacement for adding try / catch everywhere and having to manually bubble exceptions.
Crashing is loud. You will get crashes in your logs. And you can let it happen because those crashes won't disrupt anything else - that's what the message passing gets you.
So sure, the code with the error won't work (it wouldn't work in any language - you can make an error in all of them), but you will get a nice, full stack trace and the other processes in your VM won't be impacted at all. You won't bring down the service with a crash. Sometimes this is undesirable - you could deploy a service where the only endpoint that functions is the health check - but generally people don't do that.
> And you can let it happen because those crashes won't disrupt anything else
Isn't that also covered at the framework (rails, django, whatever) level in other languages ?
I feel like the other comments I see here, are not expressing the deeper point, and you're asking to really understand something, so that's what you care about? So I'm sorry to pile on when you've got like a dozen good answers, but.
Let It Crash refers to a sort of middle ground between returning an error code and throwing an exception. It does not directly address your customer's need, and you are right that they are facing a bug.
So if you were to use Golang with Let It Crash ethos, say, you would write a lot of functions with the same template: they take an ID and a channel, they defer a call to recover from panics, and on panic or success they send a {pid int, success bool, error interface {}} to the channel -- and these are always ever run as goroutines.
Because this is how you write everything, you have some goroutines that supervise other goroutines. For example, auto-restart this other goroutine, with exponential backoff. But also the default is to panic every error rather than endless "if err != nil return nil, err" statements. You trust that you are always in the middle of such a supervisor tree and someone has already thought about what to do to handle uncaught errors. Because supervision trees is just the style of program that you write. Say you lose your connection to the database, it goes down for maintenance or something. Well the connection pool for the database was a separate go routine thread in your application, that thread is now in CrashLoopBackoff. But your application doesn't crash. Say it powers an HTTP server, while the database is down, it responds to any requests that do not use the database just fine, and returns HTTP 500 on all the requests that do use the database. Why? Because your HTTP library, allocates a new goroutine for every request it handles, and when those panic it by default doesn't retry and closes the connection with HTTP 500. Similarly for your broken codepath, it 500s the particular requests that x.(X) something that can't be asserted as an X, we log the error, but all other requests are peachy keen, we didn't panic the whole server.
Now that is different from the first thing that your parent commenter said to you, which is that the default idiom is to do something like this:
type Message {
MessageType string
Args interface{}
Caller chan<- Message
}
// ...
msg := <-myMailbox
switclMessageType {
case "allocate":
toAllocate := args.(int)
if allocated[toAllocate
msg.Caller <- Message{"fail", fmt.Errorf(...), my mailbox}
} else {
// Save this somewhere, then
msg.Caller <- Message{"ok", , my mailbox}
}
}
So the idea is that your type assertions don't crash the program, and they are usually correct because you send everything like a sum type.
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.
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.
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.
Writing typespecs (+ guards) feels really outdated and a drag, especially in a language that wants you to write a lot of functions.
It reminds of the not-missed phpspec, in a worst way because at least with PHP the IDE was mostly writing it itself and you didn't need to add the function name to them (easily missed when copy/pasting).
I wouldn't lump guards and typespecs together. Guards are a runtime feature of erlang/elixir's excellent pattern matching.
Typespec is an opt-in type hint for develop and build time.
True but by using guards + pattern matching structs you can approximate type hinting, but it feels cumbersome and more of a workaround than a real solution.
I'm of the opinion that Erlang/Elixir are terrible for repeat tasks like a standard CRUD server over a SQL database. Because yes, it IS cumbersome! Behaviors and type hints only get so far, and it is exhaustingly slow to sit with epgsql in the REPL to figure out what a query actually returns.
I find them much better suited for specific tasks where there is little overlap or repetition.
I’d recommend it. I used to think I needed statically typed languages to write sound code, but after enough time with Elixir (10 years professionally and going) I really don’t believe that to be true… A huge portion of my change of heart is due to Elixir (and Erlang) being functional and only having a handful of types:
atom, binary, boolean, function, list, map, pid, reference, integer, float, and tuple
There are a few others but they are generally special cases of the ones above. Having so few data types tends to make it much more obvious what you’re working with and what operations are available. Additionally, because behavior is completely separate from data it’s infinitely easier to know what you can and can’t do with a given value.
Ruby being dynamic drove me insane at times, but Elixir/Erlang being dynamic has been a boon to productivity and quality of life. I recently had to write some TypeScript and was losing my mind fighting the compiler, even though I knew at runtime everything would be fine. Eventually I slathered enough “any” on to make the burning stop… But! That’s something I haven’t had to do in years, and it was 100% due to type system chicanery and not preventing a bug or making the underlying code more sound.
There are still some occasions where having some static typing would be nice— but they’re pretty rare and often only for things that are extremely critical or expensive to fix. And IMHO even in those cases, Elixir’s clarity and lack of (implicit) state generally make up for it.
Here's my take as TS dev. You just never learned to use types in the first place where there is very little ambiguity on any types anywhere because there is close to no any's used. Sounds like you guys get high and mighty on your tunnel-visioned copium—I mean I used to write JS for god's sake and thought it was okay. And I remember when I first tried TS felt annoyingly hampered by having to actually use interfaces properly.
Sure, the nature of Elixir probably makes it easier but I find little joy in dynamic whack-a-mole and mental gymnastics to infer types instead of fricking actually being able to see them immediately.
I could go commando in TS as well and switch to JS and JSDoc, leaving everything gradually typed and probably be fine but I'd feel terribly sorry for anyone else reading that code afterwards. It'd be especially silly since I can now just infer my auto-generated Postgres zod schemas with little effort. Moreover, a good type system basically eliminates typing-related bugs which you guys apparently still have.
So please, don't over-generalize just because you think you got it figured out.
Lmao. This has to be the funniest comment I’ve ever read on here. I can assure you, the only copium being huffed is by you, mate. I have written Scala, Swift, Java, and more (including TypeScript). I have zero trouble with type systems, but I have wasted enough time fighting them for little real world benefit. In Elixir, and this is the best part, I don’t fight type bugs. You probably do because type erasure means you can still have them if someone has mistyped something or shit on something at runtime— the joys of JavaScript.
It sounds like you’re really trying to justify something and that’s great for you. I’m really happy for you. Keep it up. May you soar where no junior dev has dared to soar before. God speed.
Hah. Sure buddy, Mr. Sr Dev. Sorry if I offended you and your vast experience. Without types there definitely aren't type bugs, I grant you that, and JVM languages are quite different to TS. I don't know if your argument on type erasure is any better than advocating for dynamic typing but it definitely happens when you just start throwing anys.
And look, I'm first to admit that TS type system isn't perfect (and it can cause some devs to go overboard) but I have read my share of Python scripts that were read-only from the minute they were born.
It sounds like you’re really trying to justify something and that’s great for you. I’m really happy for you. Keep it up. May you soar where no junior dev has dared to soar before. God speed.
> I'd feel terribly sorry for anyone else reading that code afterwards.
I feel terribly sorry for people that have to read typescript and work with TS zealots
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.
I went from a Go shop to an Elixir shop and a year or two later went back to a Go shop.
The eng department velocity will slow as code complexity grows and teams change. Dynamic typing makes this worse.
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
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!
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.
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.
Biggest benefit of typing in TS is just autocomplete that knows to filter down suggestions to field name of the object type before the dot. That and constants without typos. That, exhaustive maps and interface implementations are really good to not forget things that have to be done outside of the currently open file.
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?
I let the LLM write my tests. And when they fail it just rewrites the tests to pass.
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.
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.
You can also peek inside objects and check for types and values of nested properties. In other languages you’d need to create composite types or even duplicate or extend types. In Elixir, all that is for free. I see that as much more powerful than types.
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"
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."
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.
Depends how you use the statically typed system.
For example
match parseFoo json with
| Ok foo ->
process foo
| Error message ->
print message
I am not sure I want the system to continue operating in that scenario. You have corrupted hardware that could be trashing other records. What if it is flipping bits on financial transactions?
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.
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.
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.
no, but effort is a finite resource so it justifies why they didn't bother.
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.
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.
> 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.
sure part of the decision is that you can't really soundly type (in a developer sanity preserving way) across a cluster that runs multiple versions of software (which is a real use case that the authors absolutely needed to support as part of the core business). but they let dialyzer in to the core so it's not like the team was actively hostile to typing.
These are some weird sentences thrown into this thread.
What you are describing is a runtime concern that has nothing to do with types.
These issues are neither amplified nor alleviated by using types.
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.
ok. don't use it then. but be aware: your attitude is why things get stuck in (sometimes really awful) local minima in tech.
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.
you probably shouldn't bulldoze into a situation with assertions like you've made with such a limited grasp of the history at play.
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
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.
Letting you wrong computations crash does not make them right.
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.
I don't know who are arguing with? Everyone loves the otp.
It just does not catch logics errors.
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.
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.
To restart and fail again? How does that help with logic errors caused by wrong type objects?
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
Depends on the error. Lets say it is an error that happens once every 1 million users.
Tbh, the strongly typed and dynamically typed combination seems like the worst option.
You get zero help and punished hard for failing.
Nope, getting a TypeError on "1"+2 is not being "punished". That's way better than getting malformed data that you weren't expecting which keeps the system "working" until an error happens somewhere else, later, where it's more confusing.
OpenTelemetry.js did this. Being written in typescript they wrongly believed they didn’t need to check the data type for user-supplied numbers. Yeah so my production data started having dropouts because somewhere we incremented by “2” instead of 2, and then OTLP choked on 100% of the data from that process because one stat out of thousands was not to its liking and had a three thousand digit ‘number’ in it.
I never did track down the last spot where we screwed that up. This was a system we shifted from statsd, so the offending callers were either working by accident or only killing some data points for one stat and nobody noticed.
So then OpenTelemetry.js had to start sanitizing its inputs and not assuming the compiler should catch it. I still think it odd that something called “.js” was actually “.ts” under the hood.
Not getting an error on "1" + 2 is very bad if that's not what you wanted to do. Agreed.
Getting an error on "Value: " + 2 is very annoying if that's what you wanted to do.
The solution here is Static typing, not Strong/Weak typing.
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.
A casual look at the history of basically anything will tell you that the best option isn't necessarily always the one that succeeds.
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?
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.
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.
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.