darkmarmot
Someone recently asked “What feature would you most like removed from your language?”
And, for me, it has to be structs or the way Elixir currently handles them.
In my job, we do a lot of deployments on distributed clusters, either pushing hot code updates against running servers for small changes or running multiple versions of our code side-by-side in the cluster as we do rolling deployments for large changes.
Thus far, we’ve had zero downtime running with a cluster of roughly 30 servers (knock hard on wood) over the last year and a half (since we went into production).
Our biggest difficulty (and danger) has been Elixir’s structs. While Erlang was designed for our kind of environment, it feels like Elixir broke away from it with its struct implementation.
To explain, functions that handle structs don’t happily duck-type them. If you make changes to a struct definition and move it between nodes, you can’t match on it unless all the fields are in perfect agreement. So there’s no easy way to update them in the running system.
We don’t let any data that moves between nodes contain them.
And this is where it gets really ugly. A lot of Elixir’s base data types are implemented as structs, such as Range and DateTime.
So, what seems like a simple non-breaking change for the language, as when the recent version of Elixir added step to Range, could actually cause catastrophic chaos on our distributed system.
I would propose that Elixir consider making structs act as duck-typed maps in the future as I love the language, but I hate to see it limiting the power of the original VM and ecosystem.
Where Next?
Trending in Discussions
Other Trending Topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #ai
- #genstage
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First 10 of 23 Posts
lpil
Rather than removing structs I would be interested in hearing how structs and hot-upgrades could be improved to work better together. I think there’s value in both, and removing either would be a huge change that would likely make a large proportion of users (most users?) of Elixir unable to upgrade to this hypothetical version.
I would expect Erlang to be worse as records are even harder to match on structurally than Elixir’s structs are.
darkmarmot
I would be happy to have things under the hood use the
__struct__field for things like protocols and types. I would just like to be able to mostly use them more like maps in general. As for records, they aren’t something that’s ever come up as an issue for us as we mostly don’t use them.dorgan
Removing structs = no protocols
cevado
but protocols are just “type”(thinking of structs as types) based dependency injection. I’d rather like an explicit options dependency injection. I think the only place they’re not interchangeable is in nested stuff.
darkmarmot
Why can’t the language just dispatch on matching
%{__struct__: some_name}and ignore the rest of the fields?lpil
They come up rather a lot in Erlang libraries and codebases in my experience, so I think Elixir may do better than Erlang here.
This would not work if a field is added as it would crash when the field is found to be missing. That or you would have corrupt data after the upgrade due to missing fields.
The struct pattern is effectively an assertion to say that your data conforms to the schema. If these assertions do not find the problem from the upgrade that did not correctly migrate the state to the new format then it would likely cause errors later when the data is attempted to use.
darkmarmot
Yeah, that could definitely be from my comparative lack of experience in Erlang.
darkmarmot
Perhaps structs could also include a
__version__number such that code could handle structs with different formats?lpil
There’s not any way to know when the version needs to be bumped or what should happen when there is a version mismatch. At best we can check the structure of the struct and crash if the data doesn’t match the schema, which is what structs currently do.
Until someone makes a sufficiently powerful type checking tool that could be run against both versions of the codebase the business of upgrading state in hot upgrades is going to be a manual process for the programmer to implement via the appropriate OTP callbacks. It’s a very challenging job, and I recall reading once that Ericsson spend as much time testing and developing their upgrades as their application code.
darkmarmot
We often do daily multi-version deployments or hot code upgrades on our cluster. For us, the key is that the data transferred between nodes has to be to inferred (no structs, just maps) and we avoid hot code loads that modify GenServer states (these are usually based on modifying pure functions).