|
|
|
|
|
|
by niftich
2541 days ago
|
|
|
It's a gem of an observation that newcomers to an environment often only make it to the first few rungs of the system complexity / actualization ladder. Once you look, you see this everywhere, and not just in IT but with any sort of design exercise or institutional process, any complex system that's full of Chesterton's fences, and people will either evolve to debate their rationale from a position of experience, or be selected (or self-selected) away into fresh environments where the novelty and discovery-until-discouragement can begin again. It also shows that the first few rungs matter a lot; this is the territory of easy answers, where following a few simple rules leads to rapid productivity, and there will always be people for whom that level is good enough, either through carefully weighed decisions from limited information, or ignorance and deferment of future problems and their solutions. You can't solve everyone's problems for them, but you can try to evangelize, and you can try to build your system in a way that best practices can be incrementally adopted from existing fumblings. Anticipate that most of it will stay mediocre. History is littered with systems that, in hindsight, seem to have offered sensible solutions to complex problems, yet didn't survive in the end. Much knowledge and wisdom is lost, and others independently discover it when trying to ascend an unrelated stack. Erlang/OTP is truly the sort of environment that masquerades as a programming language yet asks questions at a much higher conceptual level: what do we want systems as a whole to look like if we have to maintain them indefinitely? Its architectural innovations have been copied elsewhere, where they rarely form part of a coherent stack, but at least expose people to the advantages of its model. This may also be the most viable source of adopters of Erlang at higher levels: people who've sought out similar model for its benefits, and could thrive with an offering that pays attention to these concerns throughout. |
|
|
I discovered BEAM while looking into a way to run concurrent, distributed Golang/gRPC services in a supervisor-worker set up. I've continued tinkering with OTP ever since.
Edit: added quoted portion.