Erlang and Elixir are “compile to BEAM languages”.
lud
mmmrrr
Please insert the word “experimental” to get the correct meaning 
@asianfilm thanks for your field report regarding Norm and Witchcraft! 
1
dimitarvp
amarandon
FWIW I’ve been using Elixir in production for almost 3 years and I can’t remember having a type-related bug. We do write automated tests for the functionalities of our apps, without thinking about types. Do Elm programmers avoid automated tests entirely?
To me this doesn’t seem to be an issue. Getting supervision trees right or avoiding race conditions are the challenges I’ve been facing, not typing issues. Maybe I don’t know what I’m missing.
3
Adzz
I was trying to figure out how to articulate exactly that.
I think often it’s a problem people think they are going to have, but in practice it comes up less often than one would imagine.
1
lud
That is related to the original post:
I’d like to stay away (for now) from [experimental] compile to BEAM languages, like Alpaca, Gleam, Purerl and Elchemy, since none of them feel ready to me.
2
asianfilm
Both Elm and Elixir are known for “developer happiness” but they achieve that in different ways. I use both (hopefully for the right problems), but when I do so I’m wearing different hats with, I suspect, different brainwave patterns if my headwear of the day could measure them.
With Elm, it’s true that “type-driven development” is probably practiced as much as (or more than) test-driven development. But testing is a first-class citizen in Elm, with excellent testing libraries, and the fact that functions are always pure (without side effects) makes code particularly easy to test.
What do I mean by type-driven development?
The type system of Elm is actually quite limited when compared to Haskell (which has its own limitations, and has influenced other functional languages with more descriptive type systems) but it’s more expressive than Elixir. Like Elixir, programming in it is very much about transforming data by pipelining it through functions.
When programming in Elixir, one is primarily modeling data with product types (structs or “records”). In Elm, equally important (and complementary) are sum types (aka tagged unions). Algebraic data types in short. One can introduce sum types in Elixir with third-party libraries such as the “Haskell fan-fiction” Witchcraft suite.
With this descriptive power, Elm programmers put a lot of focus on getting the types right (not only of data, but also of functions), of “making impossible states impossible”, and then trusting the compiler to guide them. And because of this type-driven safety net, one can do wild refactoring in confidence, even without tests.
While there are (gaping) holes in the theory, there is some truth in the saying “if it compiles, it works”. When programming in Elm (and Haskell), you juggle less mental baggage in your head because the compiler - and its type inference engine - has your back because the contracts in your code are enforced.
As such, it’s common in the life of an Elm program for one to make radical changes to one’s types (and module structure), and to be able to confidently fix all dependent code by just following the type errors. And the Elm compiler has excellent error messages that help pinpoint the where, why and what of changes that need to be made.
I don’t need to explain on this forum the real joy and multiple sources of “developer happiness” when reading and writing Elixir code. But too many of my brain cells are doing the work that I would expect a compiler to do for me. It sometimes feels that only half my brain can focus on the problem at hand, while the other halve is unnecessarily juggling ten balls.
Or, in another analogy, when writing a particularly gnarly piece of data massaging in Elixir it can like a SWAT team is loudly breaking through the door while I need a little bit of quiet please to break into the safe. In Elm, that SWAT team is working for me and keeping people out, and have hired a talented pianist playing Debussy.
So, yes, I’ve tried to make type-driven development more of thing for me in Elixir with Norm (although contracts are only enforced at run time) and with the Witchcraft Suite (which opens up even more type-power than with Elm), but it brings with it a lot of boilerplate, and without a stricter compiler one can still feel that SWAT team breathing down one’s neck.
In Elixir, feel I did get to write more expressive and more ambitious code when using the safety net of Norm and the expressive power of Witchcraft. Yes, maybe that suggests that I’m not in the 1% (or even 10%) of top-tier Elixir programmers, but the point is that I don’t need to be to make progress. A test-driven approach may have resulted in good code, but it would have been a different developer experience, and on the off ramp of the highway of developer happiness in Elixir.
On a podcast, Dave Thomas recently discussed his lament that the Elixir programming language is considered “finished”, because it isn’t exploring possible futures (and reimagining of choices it made). He explored what Elixir might look like if it took more inspiration from other functional languages (and how that would empower Phoenix pipelines, etc). José has given his response on this forum to some of Dave’s arguments.
But getting back some of the original questions above, yes, I believe the use of Norm (and Witchcraft) can make one a better Elixir programmer, and make one’s code more expressive and better documented. But they are limited to decisions made by the language design (in part because of Erlang and BEAM), which is not to say that those decisions are wrong. (See arguments that Elixir is better described as a “concurrent programming language” than as a “functional programming language”.)
1
mmmrrr
Actually quite the opposite: with a decent type system, like for example in Elm or even Rust, you’re actually writing a ton of automated tests in the form of type annotations.
The additional unit tests you’re writing are hence seldomly concerned with the shape of the data.
Actually, in my experience at least, this is a problem you’re facing on a daily basis:
- The vendor API changed? Now I’ll have to refactor each function that uses the response of that endpoint.
- We need to display more data in this table? Ok I’ll better check that I don’t access this possibly empty thing at runtime.
- You realize half way through your prototype that you had better used a Set instead of a List? Start looking for each function that accesses this data
Of course: unit tests help with this since they might crash due to wrongly shaped data, but a really good type system will simply be more thorough and point you to each and every function that is not following the spec.
N. b. I also felt a static type checker was more of a burden when I transitioned from C, C++ and Java to Ruby and JavaScript where I felt liberated. But that is because in the aforementioned languages the type checker will actually not prevent a lot of type errors (NULL pointer exception anyone? 
) and you might not realise that the problems you’re facing are, indeed, type problems.
1
mmmrrr
I think my own take on this problem when writing Elixir will be the following:
- At the edges of the application I’ll use tons of guard clauses and pattern matching to ensure that no garbage data makes it into the system. This should be accompanied by fuzz tests.
- Inside the application (i. e. everything under my direct control) I’ll use type specs and try to express data types as Structs as much as possible and then use Gradualixir to type check the application at the CI-level
Maybe Norm or Witchcraft (and it’s descendents) could help with point 1.
Thanks again for your opinions and experiences. It’s much appreciated!
4
Adzz
Thanks for the insight!
For cases like this, definitely serializing things at the boundaries of your system helps, I just use ecto structs for that (embedded schemas), and try and do the Parse Dont Validate approach.
I agree types could be helpful if you change the return type of a function. But in reality, greping for the function name hasn’t yet been an issue for me, though it is not as slick I agree!
1