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.

you mean floci? https://floci.io/floci/

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%

I can see that too, this might be a reason for its success, all the articles are very straightforward and full of paths you may encounter

Me too, I started with Debian but after a few weeks, I found myself being more on the Arch wiki than the Debian's one so I did the switch and never used any other distro.

I'm sorry to say this but Debian's documentation sucked a lot some years ago.

I think you you're missing the point though, he did not say that adding those constraints was a bad idea per se, but they are leading to a bad path. If the path is "just add more guard-rails" then we will get to a point where we lose the "soft" part of "software" and you'll find yourself restarting each time you need to change something because at that point the language you chose was already the first wall of a bad program architecture (ease of change).

Yeah I can see that, but that lisp feature is not exclusive to lisp, if you know what you want and what you are doing you can implement the very same thing in any other language, you may say it is convenient that lisp already has it, but it does not make it more powerful. I don't know list, but there will surely be something that is missing from it that another language has it, now I ask you which is more powerful? See? Everything is relative to what you want to do. The very author of the blog you shared is falling in the same set of programmers he wants to criticize because now he thinks in lisp macro and the very moment he cannot use lisp, he will feel lost but has he stopped and thought that what he needed was something to manipulate code at compile time he could have used any language

I understand and agree, what I was trying to say is that one should not confine ones thinking by the constraints of a tool, would it be a programming language or whole framework, but to express everything as freely as possible without details of implementation only then one can go deeper and add concreteness that brings its set of constraints and all of this should be possible in any programming languages.

I hope I've cleared my standpoint.

No I wasn't, it was a really interesting read thank you, but that blog post seem to me like an argument for me not the OP point of view, because if you refuse to understand how things work by blindly delegating to libraries and frameworks (like RoR) you become a "Blub" programmer that thinks in the way of constructs and decisions that the library/framework authors made.

I completely disagree with the post.

All programming languages are equivalent meaning their level of expressiveness is the same, it's not an opinion it's a fact. Each language comes with its runtime and its peculiarities but potentially you can always make any feature that another language runtime has with any language, even though probably not with the same performance and efficiency has been that feature native to the runtime itself.

So there are no "more powerful languages" just runtimes that allow you to hide away some stuff considered stable enough that they become some kind of primitive for the programmer, now we may have different opinions on what elegant code is, but personally I'd like to avoid code that directly (i.e. no kind of abstraction) relies on runtime features and instead express clearly my intention in code, but I recognize the productivity gains.

I was very interested in Graphene, do you have other grounds for your suspicions?

Without taking anything away from the author, I think he could have saved a few words by simply defining the point that events should be seen as commands rather than messages or passed-events.

  > America First
  > anti-Israel

American Government became the parody of itself, so sad

I really love where Deno is going, it really is what Node should've been.

My only concern is that they lose patience to their hype-driven competition and start doing hype-driven stuff themselves.