I am not so sure. I love rules for this clinking sound they do when you break them. The humanity could not (arguably) survive without the tablets, covered with 10 anti-patterns. If Leonardo stuck with the hard science, his heritage would have narrowed to a couple of murals.
In 2026, the Newton’s laws of motion are not hard science anymore, but I do still estimate when I’m to arrive at the destination without applying the relativistic adjustment.
We should not stick at all. They write the “anti-patterns” paper, I do write my rant, we talk, and everyone benefits from the argument.
Truth springs from argument amongst friends — David Hume
There’ll always be fuzzy at the edges of such guidelines, but usually someone starting out (without the tools of making their own tradeoffs yet) is unlikely to operate just in that fuzzy realm. In the past I’ve had my own experiences – before such guidelines existed – of trying to do something like ecto does it just for @michalmuskala to tell me ectos architecture is not where you want to start. The issues with it becomes really obvious once you start looking at the hoops ecto has to jump through with Repo.put_dynamic_repo - apis, which can be avoided if you do not have lagacy to maintain.
There however comes the time where you land on the fuzzy portion as well, but with the guidelines in mind you might be able to layer e.g. global behaviour over overridable per call/per process options instead of leaving the global switches as the only option.
While I agree with some points and don’t agree with the others in the post, I think that it highlights the bigger problem behind it: Official language documentation is not a place for coding recommendations. Here are my points why it should be changed or removed:
This can be just a regular documentation. Instead of saying “avoid using application env”, I think that Application module doc should be extended to something like “application env is global, so it is not applicable in cases where different configurations may be used simultaneously”. And this point is more important than it seem: documentation must be easily discoverable, and when engineer learns about application env, they must learn about the possible drawbacks of it in the documentation about application env. Engineer won’t randomly stumble across some doc with guidelines.
This is a poor band aid. Imagine you stumble across the nuclear plant and you find the big red button which says “Immediate self-destruction. Do not press it under any circumstances”. Why would a plant have this button in the first place if it’s so bad and wrong?
Coming back to Elixir, you can change the language to make wrong things inexpressible or just make sure that the developer explicitly acknowledges the drawbacks. For example, add the mix new --library which would generate a template for library without config/ directory and no connection to config/ in mix.exs. Or rename the Application.get_env to Application.GlobalEnv.get. Or for supervised processes, add the Task.Supervisor in the generated root supervisor code. Or for exceptions in control flow: deprecate handling exceptions without stacktrace and make sure that developer must always explicitly state that their rescue is handling the stacktrace, thus developer is acknowledging that this is not just a control flow, it is an exception which collects the stacktrace into a list, which affects performance.
These examples are not important and may be wrong, I am just trying to bring attention that the language can be self-contained and it can lead engineers to correct solutions without any recommendations. “Good” things can be easier to express than “bad” things.
This is opinionated. Again, I can list many thing I personally find more important than any of those present in the guidelines. For example, “Try to avoid using Application and instead expose the root supervisor which can be started independently”. Or “avoid singleton processes with global names”. Or “dont install any executables or download any binaries in runtime”, etc. We can’t fit all our experience in this guideline, it will always be incomplete, insufficient.
It would make a great blog post, but the official language documentation brings too much authority. I’ve been participating in discussions during code reviews (defending not only my own code) where this doc and the infamous “code smells” doc were used as the arguments appealing to the highest authority: the language documentation itself. And you may say that these guidelines are only guidelines, not strict rules, but that’s misleading. First, almost every other line in documentation is a strict rule, and I would argue that documentation must be as strict and as precise as possible. Second, it is just the weight of authority, it is really hard to argue with the opinion of the core team member or the language creator (as it should be), but the language documentation is the ultimate boss and I think that it is too much for just recommendations.
However, these code smells and guidelines are good in a sense that they highlight the problems the language has. And having recommendations articles in docs won’t help. These problems require proper solutions which include changing the language or improving the regular documentation.
In the age of LLMs, these anti-patterns can and will be replaced with various homemade or community linters – based on ast-grep, or just your own Elixir AST analyzer (Claude Fable rolled a primitive version of that for me in 2h).
I tend to agree that anything that people spot as “anti-patterns” in official docs loses all nuance immediately and people start following it unconditionally, with zero critical thought. I’ve been on the receiving end of “Why are you questioning Jose Valim, do you know better than him?” and my response of “I likely don’t but he’s not here now and he does not know the intricacies of our projects, requirements and priorities” absolutely did not land even when I presented an alternative. On that basis alone, I dislike the “official anti-patterns” and have been vocal about it in the past. Dogma is rarely good.
On the other hand, if that leads to little bit less crappy code out there, it would be a win. I have my doubts but in the grand calculus of the entire Elixir area, it’s probably still a net gain.
I’m not sure this analogy holds. I’d rather compare anti-patterns to Freon, which is by many measures a great thing but one whose side-effects weren’t discovered until much later. Quite often we have to deprecate things after learning they’re bad after lots of trial and error.
At which point I’m sure you politely pointed out that the document itself says to not take it as dogma, and that a particular anti-pattern may indeed be the best approach to the problem at hand.
If someone does not have the confidence to make a judgment call over whether a particular “anti-pattern” is justified given the circumstances, then they’ve pretty much declared themselves incompetent. If we simplify things a bit (perhaps too much) our whole industry is about adapting our particular requirements into something machines can work with, and we’d be entirely redundant if that could be done by following the documentation without reflection. Someone would’ve turned that into a program that does it for us by now, and to the extent that Claude Code et al can do it, we’re still needed for grounding the result in reality.
Hence, I’d say the fault lies not with the documentation but with the folks who take recommendations as gospel and/or wield them like a cudgel.
Thats exactly the problem, obviously you could just say that whatever place that person work at is toxic and they should find a new place to work ASAP. But that would miss the whole point of this, that people might be in a place where they don’t have that much control, and should we really make it easier for incompetent people to do the wrong thing?
There are better ways to help people then writing a declaration.
Just to add my 2c, the anti-patterns section has helped me more than it has caused issues when I was starting out.
Also, trying to pander to the lowest denominator, i.e. those who are not able to interpet the “this isn’t gospel” part, is a losing battle. If it isn’t this, then there’d be something else to latch onto. If the anti-patterns were taken out from the Elixir docs and Jose hosts it on his own or dashbit’s blog, you’re going to still run into the same exact problem with those people at work but now newcomers would likely not see it.
It’s really a people problem of that workplace, not the language maintainers’, in my opinion. Obviously not to discount the difficulty of that problem.
Absolutely. And sadly that’s exactly what is happening: they wield the antipatterns like a cudgel.
Conversely, adding such documentation they perceive as being handed a cheap and easy-to-use cudgel. It’s a two-pronged problem.
I’ll agree that we can’t ban having rocks in the city just because somebody can use them as a murder weapon though.
A lot of people just want to get something done and move on; I sympathise with that in a startup setting – but a nuance often missed is that “moving fast and breaking things” while keeping customers satisfied hits a plateau, hard, sooner than they expect. Just a mere 6 months later your CEO is in talks with 4 more customers and now you suddenly don’t have only one customer anymore and lo and behold, half your system has hardcoded business rules inside the code, global state everywhere (how people allow more than the absolute very minimum amount of Application.get_env calls in their code remains a mystery to me), sync tests (in Elixir of all PLs!), an app full of timeline processing people still uses DateTime.utc_now and not a easy-to-mock shim, etc.
And then the classic problem: “Why can’t you just do X? We moved so quickly before!”. If I hear that one more time this year, I might actually go retire to farm tomatoes and potatoes.
The problem with good practices is that people wisen up about them 6-12 months down the line. The long tail of negative consequences of “winging it” and “do you know better than Jose Valim?” is not visible in the meetings where your experience gets overruled by vibes and impatience. It’s always later.
The amount of times I was called by former colleagues (CEOs included) telling me “You were right, Dimi” might sound like a covert brag but with the years this began giving me bitterness much more than satisfaction.
Agreed on the premise and you’re both crushingly correct. The nuance here is that often people can’t just leave a bad workplace, especially today when the illusion that “devs are easy to get rid of and get a new one” is still in full swing for a lot of businesses, and many of them have severely reduced their hiring. Add to that the fact that Elixir, much to my regret, remains niche, and you get a picture of “well maybe I shouldn’t leave because my experience yet again got overruled and I know people will call me in a year telling me I was right”.
Let’s not forget a lot of people are with families and just leaving and finding a new job might be anything but “just leave and find a better place”; kids need clothes, school tuition, and a thousand other things.
So very often one has to stay and fight a doomed battle with people who made up their minds three years ago.
But I don’t fully detest that. When I was in such less privileged positions, I partially learned to navigate stubborn people. And as mentioned above, not all are truly unreasonable; some are just overwhelmed and rushing. Sitting them down and trying to dissect a problem works, part of the time, especially when you show them that you all are fighting the same problems and have the same mission.
And I agree with @mudasobwa; framing and phrasing matters a lot. But admittedly, I have no better idea. I’d not put those antipatterns in the official docs in the first place – but that ship has sailed.
To clarify, it was a response to remarks about workplace scenarios which was definitely mentioned at least once and without me going back through the thread, I feel like, was referenced more than once. So it was an extrapolated implication since there’s only 2 parties in that scenario. Apologies, as I thought my wording when I submitted was clear it was an implication and not a call out to people’s explicit statements.
Yes for sure. I was picturing an individual, I think it was your post mentioning an incident of, (loosely quoting) “you think you know more than Jose”, and not an entire workplace.
That said, is a workplace really that bad because they force everyone to strictly adhere to the anti-patterns section, or is it that a workplace is bad because of something more general, such as not trusting their developers, or whatever may be the case. If a workplace forced the anti-patterns section as gospel, even though it says not to, but otherwise was a good place to work, I’d be able to live with that since that’s rarely the case
