right, I think DHH's "Majestic Monolith" is another good approach here

This resonates a lot if you’ve ever worked in system integration.

In practice, most of the complexity comes exactly from what’s described here: every system has a rich internal model, but the moment data crosses a boundary, everything degrades into strings, schemas, and implicit contracts.

You end up rebuilding semantics over and over again (validation, mapping, enrichment), and a lot of failures only show up at runtime.

I’m skeptical about “one model to rule them all”, but I strongly agree that losing semantics at system boundaries is the core problem.

> You end up rebuilding semantics over and over again (validation, mapping, enrichment), and a lot of failures only show up at runtime.

I think die-hard fans of static typing mostly fail to acknowledge this objective reality and its implications. Every time they encounter this problem again and again, they approach it as if nobody thought of this before, and didn’t develop reliable abstractions to productively work in these environments.

I'm genuinely interested in examples of these reliable abstractions, or at least in some keywords I can look up.

The way I see it, Clojure was created to address most of the philosophical problems highlighted in the article, and its ecosystem has developed under the influence of such ideas.

It embraces the dynamic nature of things. Every program that must do I/O is dynamically typed at the edges - so statically-typed languages must have both the facilities for dealing with dynamic types and static types, and use those differently for "inner" and "outer" parts of the program. The Clojure ecosystem makes it more approachable to work with dynamic data, and as a result, program's parts (modules, even functions) use the same machinery as the program as a whole. What helps, off the top of my head:

1. Immutability of values, persistent data structures, explicit state management - it turns out most of the "problems" with dynamic types are not due to the fact that types are unknown, but the fact that they may change over time. Most of concurrency problems also become irrelevant with immutable values.

2. Powerful data specs/schemas allowing to express full business requirements and constraints on expressible values (not possible with static typing anyway) — making invalid states unrepresentable and actually meaning it.

3. Concise unified model for working with different logical data structures, also nested data structures.

4. Simple asynchronous communication mechanisms and patterns between independent modules of a programs.

5. Rich extensible aggregates of data with namespaced keys as the object model.

6. An ethos of extreme backward compatibility (and tools for achieving and maintaining it) through accretion of novel values/parameters/features, enabling reloadable workflows, which makes it easy not only to redefine functions in code while program is running, but also updating individual programs while interconnected system is running, without breaking things.

The downside is that tools that reduce complexity are not very easy to use for people with less experience, so they cannot be too popular. People tend to overcomplicate, and to be quick to dismiss well-thought-out solutions.

It’s one of the reasons AWS ended up happening, when you make REST APIs the only allowed contract.

I sometimes think the same, but look at it this way: you’re an IT worker—probably a specialist, at least a bit of a nerd in something. The days when we were seen as “wizards” are gone, sure. Right now a lot of people in business, and at the interface between business and IT, are riding a wave of confidence because of AI. But the difference is: you’re a critical thinker. They’re just using the tool at face value. Anyone can ask AI: “write me this code.” But you understand how things actually work in production—trade-offs, edge cases, long-term consequences. Thats the real leverage. So use AI differently. Don’t just generate code, ask better questions: How does the business actually work? Why is this process done this way? What are we optimizing for? In my perspective it's the normies knowledge that's at risk. A critical thinker with technical skills will have the edge and should get far more out of AI than someone who just feels empowered by it.

small scale farming to get your kids fed

Second this. Just because you're aware doesn't mean everyone else even realizes they're talking to a SalesmanGPT.

insane story!

  This is how others feel as well and how software engineering will feel for new generations

How can you make such universal statements? This is not true at all. There are plenty of people who find vibe coding mentally exhausting (not everyone wants to be a manager) and who think LLMs suck that joy that was left in programming.

Add my name to the list. I enjoyed thinking about all of the little problems. Being a craftsman.

What if Elon Musk had been born in a much poorer region/family instead?

Then we would have missed out on a great man (for a precondition to being a billionaire is obviously to be a great man, better than your fellows) and the world would have been a much poorer, grimmer place.

greatness is working illegally, tax evasion, defrauding consumers, and refusing to pay child support for all of your children.

I like your comment I think this is a pragmatic way to see oneself

I don't know if consuming world news makes you ethically better. That sounds a bit much and yes you can make something better in your society by what ever ... opening a hacker space in your village... I just do not get the relation between scrolling through news and affecting fellow human beings