I will be at Code BEAM Berlin featuring our first live episode of BEAM Radio. It will be a short and tight 30 minutes with Saša Jurić and José Valim on the topic of Fully utilizing the BEAM.

If you see me in Berlin, do come up and say hi. Dive in even if I'm talking. I'm never not talking unless I'm poking at my camera and that's also fine to interrupt :)

Am I being immature?

Maybe it is a consequence of a bleak market. Everyone seems to be making conservative moves. Suddenly I find myself considering whether I need to grow up in my programming. Write code more corporately, perhas? Be serious, enterprise-grade. Or maybe it is a robustness and rigeur question. I need more tests and types. Am I immature if I don't? I still don't have strong evidence that this conservatism about how software should be wired up is better. I know some people feel strongly that it is and I do understand their points.

Is the new type system for Elixir an attempt at the language growing up?

Is the strong interest in Ash Framework a sign of devs wanting Elixir to grow up?

It is decidedly intended to give you more layering and a prescriptive way of solving the common needs of growing software. I think it mainly serves a different customer.

Is it growing up or just .. growing. Or is it about appealing to more conservative markets? As our startups mature into scaleups or the even become profitable going concerns. As the language sees adoption in larger orgs the requirements and desires shift. The appetite for risk changes.

I've argued that I don't want, like or care for type systems. I think my stance is slowly shifting. Probably mostly from experience with Elm which wields its type system very well. It is also from the challenges of growing less strictly formed code bases. Some would say that the idea of dynamic typing is just bad and should be avoided. I think dynamic typing is fundamentally more high level and easier to get started with but also has fundamental challenges.

Elixir and Erlang use this dynamic nature for considerable upside, it is intrinsically connected with the capabilities of the BEAM. Elixir figuring out a novel way of doing type specification that can fit with this is really interesting.

Most likely I'm feeling pressure from a trend. Partially looking at what surviving companies are up to and at a certain size of org. Here structure becomes very important and surviving companies that are visible are generally not small. The tiny success stories are fewer, not necessarily because they don't exist.

Perhaps the TypeScript kerfuffle is a counter-culture reaction to this. Part of that might be that TypeScript is pretty much C# from what people tell me. And C# is very meh to me. It might not really be about types. I would also rather deal with undefined than enterprise class nightmares. The kerfuffle also seems like a storm in a teacup, not actually a movement.

In the back of my head there is this grass-is-greener hope of finding a better way of working. I have never in my life developed a real product under anything other than pressure to produce features or put out fires. The few times I've had the pleasure of having time to layer things properly and think things through we went way off base. The requirements made the wrong assumptions. We made poor technical choices. So we rolled our own microservices architecture with custom almost-everything. It ate all the dev-time we had and then the product built on it was crunched out.

Having dealt with so much high-pressure spaghetti even a messy Phoenix code-base looks like structure to me. And sometimes I worry that this is an inherent flaw in my approach to programming. But I generally don't recreate this problem if I build a library for others to use. The incentives are different. The requirement isn't to ship features now but rather to produce a lasting good piece of craft.

I don't think the absolute truth is that more tests is better and staticer types is better. They are extra things and that can affect your speed and progress. They are also investments in the future that may or may not pay off. You go slower and build more reliably. Some of it may also become harder to change. While it also makes changes less risky because it forces the changes to be slower and more methodical. Managing change is important so this should not be dismissed.

For example, I'm embarking on some research-oriented building for a new client. The thing I'm building will not be the end-game product. It just needs to be able to evolve to that. I need to verify concepts, assumptions and possibilities. Not build the correct algebra for a domain up front.

I think regular Elixir code, dynamic and untyped can still be structured well, still be kept and maintained well. Without necessarily going wild on unit testing and type specs. I think writing some tests is always very worthwhile after your first prototype. It might be that this is a harder discipline to pull off. Discipline is hard. And making things mechanically stricter is a good way of reducing how much people need to think to do their work. That's often the good move. Asking everyone to stick to an artful balance will get you results from both ends of the range, easier than to enforce a level.

I don't enjoy it as much. Building for boring, scale, etc. But I probably should practice it more. At least to figure out what's what. I don't think it is about immaturity or growing old. It ends up feeling much more complex than that. I think there are more axes, 3 or 4 dimensions more, than we can usually see when we estimate technologies and other developers. Humanity is exhausting that way.

Are all your colleagues immature bastards who can't code straight? Or are you surrounded by stodgy dullards who can't appreciate your creative brilliance? You can reply to this email or poke me on the fedi @lawik@fosstodon.org, I enjoy hearing your thoughts.

Thanks for reading. I appreciate your attention.