A new Go API for JSON

And the things that we do to manage this, that are symbolic or based on visceral real-world analogy, are good for us and bad for them.

Go is kind of in the middle, in the way that many vaguely Wirth-like and CSP-like languages possibly are, I guess.

No, because good understanding of design comes from programming experience. Atrophied skills mean you lose touch with the actual nuts and bolts of what you are building.

This is also the worst kind of lock-in you can imagine, by outsourcing all of your understanding of a codebase and your skills you are now completely at the mercy of LLM providers. Even if you switch to open weight models you're at the mercy of graphics cards producers and scalpers.

> Sure, if LLMs are producing shit code you need to have an understanding of what it should do instead. But I think that day is already gone.

Maybe your standards are too low. By my standard, they still produce shit code and require lots of iterations to get reasonable designs (I often end up just rewriting the bits that are obviously wrong rather than trying to figure out how to "prompt engineer" the right output).

They do often produce passable code but my experience is the longer you spend reading the code the more things you find wrong with it, almost like an uncanny valley.

At least that's my experience with Opus and Fable. Maybe it's too old-fashioned at this point to complain about code quality, but I find it very strange how many people have started proclaiming that their code quality is good.

You don't expect everyone to stop wanting to do those just because they can be automated more or less effectively, right?

I am begging HN users to understand that some people enjoy writing software themselves

Considering it just pulls and remixes blocks, this is a very tall order for today's LLMs, and maybe a couple of generations as well.

Calling GCC/clang at the back and emitting ASM is both cheating and has no advantages whatsoever as well.

A lot of specs contain these optional limitations. The C standard allowed implementations to truncate variable names to 31 characters if they have external linkage and 63 if internal linkage. Would you be happy if your implementation actually does that? Of course not. Neither LLVM nor GCC does that. That’s because people writing compilers also hold themselves to a higher standard. Now imagine this kind of attitude being pervasive.

Dependency management is a freaking nightmare, nobody has managed to create something that is bulletproof, not cargo, npm, apt, yum, nix, homebrew, nothing.

The key issue is that you're managing 3rd party software that may or may not adhere to the prescribed lifecycle/versioning

The Linux variants do it by each having dedicated teams watching upstream sources, taking what they believe to be whatever they feel is right, building for their nominated target(s), then testing, before deploying (on top of that, all of these steps vary in importance and rigor depending on numerous variables)

For programming libraries (which is what depmod, goose, vgo, and modules are managing) it's just as bad, if not harder, because their very nature is to provide a base upon which other developers can turn into whatever their imagination.

Add to that, modules was (initially) written by people who were dealing with a slightly different ecosystem; Google rather famously has a monorepo, making their lives a little easier when it comes to managing dependencies.

So, with those things in mind, dependency management is always going to be a hard problem that is opinionated (eg. I have a firm opinion that there should be an easier way to "pin" a dependency, other than vendoring - note that this isn't an invitation to every junior Go developer to come and claim go.sum does that. It doesn't. go.sum is a log of what dependencies were used for the last build by whomever wrote to it)

  if (int.TryParse(str, out var value) && value == 5)
  {
      // value is available 
  }

   // value also available

If you wanted type safety with JSON in Go then don’t use the marshal interface. Period.