duesabati

Release should be separated from deployment, there should be virtually no difference between the code running production and other envs, instead of creating a release per environment you should just tag your code with an easy to read label (e.g. a version number) produce artifacts from that version of the code, then at deploy time you decide (either manually or through an automated logic) which version of the code you want to use. Ideally all "differences" at runtime between production and other envs should be defined at, well, runtime i.e. through environment variables (even the frontend stuff that you see usually made at build time, there should be a mechanism at runtime to avoid it) this way you have much more predictable behavior and it's easier to reason on, also you can physically separate building from deployment pipelines, so you can have much more agility on switching to whatever is needed, it's also much more easier on the brain (and for LLMs) to clearly see the steps and fix ci pipelines problems.

If you really need build time differences, then you should identify this difference by what really is not by the env you assume it will run on, because explicit is always better than implicit, especially for LLMs and new devs.

I don't know if we are talking about the same stuff, also let me first state that I don't like Effect, Zod, and the like, so I'm really talking about types here.

If you get them out of the way, I literally need to do the type inferring myself, not a problem if I'm looking at a small and trivial function, but if I'm trying to understand a "conversation" inside my code I really want that job already done by the compiler, this is also to tell that more of the "dumb/mechanical" computation is done by the compiler/interpreter the better, this is why we always wanted to get rid of syntax because we want to read english but at the same time we cannot use english because we don't want ambiguity. Writing clean code allow for the right compromise. I believe LLMs can write clean code with the right instructions, the same you would tell a junior dev, but one thing they will never succeed (unless they litreally copy) is architecture, because that is not teachable by writing (instructions/guides/etc.), only by doing and feeling.

What you refer to as "clutter" is what actually documents the code without the need of comments if done correctly i.e. naming things properly i.e. ubiquitous language. Before rushing to throw away things you don't know, learn about them.

NodeJS has just a long history of mistakes and stubbornes. CommonJS, node_modules mess, hostility against standards, low attention to performance just to name a few. Only recently they finally decided that TypeScript is fundamental, they are what is wrong in the JS ecosystem. I don't hate Bun, but it could've been just a slightly better NodeJS they don't solve fundamental issues like Deno has, so I don't like it. I'll just try as much as I can to wrap/hide NodeJS in my toolchain.

you are definitely right, thank you for this reminder, it's just that I'm a bit tired of managing trash like NodeJS

Insane, I'm deeply saddened and embittered, I don't want to go back to NodeJS and I don't find any advantage in Bun. I guess this is my sign to just get off of JavaScript entirely.

node is a big part of what is wrong in the JS ecosystem, is literally the example of "LLMs actually write better code than the average programmer". Deno on the other hand is striving to make better decisions and try as much as they can to make the right contribution to the ecosystem. I can agree that lately as a company it has lost a bit of direction, but I would rather see NodeJS die than Deno.

I can't point my finger to anything right now, but I feel that the quality of code still matters because afterall LLMs are trained on what we did, so it feels natural to me to still have them write the code in a good manner (DDD, SOLID, etc.) especially the names and imports, those are very heavy in the context, to help them out

I really can't believe there are people that still think this is about terrorism in 2026, at least not on HN

While I think everything written in this post is correct, what really is starting bothering me is this over-focus/attention on data even when what you want to express is behavior, let me explain:

The post talks about "transition invariants" that should be somehow different from "state invariants" yet it describe them as:

> These are predicates over a <<state, next-state>> pair ...

i.e. it still is about state, but I find it much more useful to focus on behavior so instead of thinking about how state transition you focus on what the program is allowed to perform, regardless of the underlying data structure.

What I mean is that I'd like the code to tell me why a certain piece can't do such move instead of why it cannot transition it's position to another position and basically dumping its state in my head and there I have to execute the program myself.

Yeah exactly, came to the comments just for this check

I think this project is super interesting and I really like the rust inspiration here. How can one get in touch with you and/or help out the project?

You mean as arguments that proves the author's pov? Yeah definitely

With ALL due respect (seriously), this is just a misconception of yours.

When you write software to solve a problem you start with as little as possible details such that when you read it, it would only talk about the business logic. What I mean by that? That you abstract away any other stuff that does not concern the domain you are in, for example your first piece of code should never mention any kind of database technology, it should not contain any reference to a specific communication layer (HTTP for example), and so on.

When you get to this, you have summarized the "spec", and usually it can be read very easily by a non-techincal person (but obviously is a "domain expert") and can also be very testable.

I hope this helps on why the author is right 100%