6 ms·
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
by the_gastropod 1y ago
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 1y agoTbh, the strongly typed and dynamically typed combination seems like the worst option. You get zero help and punished hard for failing.
- throwawaymaths 1y agonah you just get log lines. crash is not as bad as you think it is.
- dminik 1y agoI 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 1y agohow 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 1y agoA 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 1y agosure, 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 1y agoPlease, 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-desired 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 1y agosmalltalk 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.
- crabmusket 1y agoNope, 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.
- hinkley 1y agoOpenTelemetry.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.
- dminik 1y agoNot 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.
- LionelLassiter 1y ago[dead]
- coffeeindex 1y agoSeems 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 1y agoIt'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.
- never_inline 1y agoTo restart and fail again? How does that help with logic errors caused by wrong type objects?
- victorbjorklund 1y agoDepends on the error. Lets say it is an error that happens once every 1 million users.
- pmarreck 1y agoIt 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 1y agoLetting you wrong computations crash does not make them right.
- tossandthrow 1y agoWhile 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 1y agono, but effort is a finite resource so it justifies why they didn't bother.
- tossandthrow 1y agoWell, 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 1y agosure, 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 1y ago> 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.
- throwawaymaths 1y agosure 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.
- bccdee 1y agoI'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 1y agoWe 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.
- 3eb7988a1663 1y agoI 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?
- spooky_deep 1y agoDepends how you use the statically typed system. For example match parseFoo json with | Ok foo -> process foo | Error message -> print message This will skip bad messages and be statically typed in the valid case.
- bccdee 1y agoThat only works for enum discriminants. What if it were modifying the data payload, producing valid but corrupt messages? The only way to tolerate that kind of error is checksums on your data, and I don't think any language has that kind of redundancy built in.