A new Go API for JSON

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)

https://homepages.inf.ed.ac.uk/wadler/topics/gj.html

Before Featherweight Go, there was Featherweight Java.

So maybe a language designed in 2012 (v 1.0 release year), should learn from history instead of hand-waving it away as needless fluff.

> In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier.

https://github.com/golang/proposal/blob/master/design/go2dra...

And not all on the team were convinced even after Featherweight Go, here Rob Pike,

> I think the transition to getting polymorphism into the language through generics is has still got some years to work through there's still things that don't quite work right

https://youtu.be/yE5Tpp2BSGw?t=2134

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.

Expressive and type safety of a functional language, without the odd semantics of Haskell, where laziness can make performance difficult to predict and purity can make simple things like IO difficult to understand.

Does it still lack easy to use concurrency primitives?

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

Letting it generate machine code directly would be the opposite of that.

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.

  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.

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.

It’s versioned because the function signature differs but the abstraction itself doesn’t.

That’s not to say that Go doesn’t have multiple different abstractions for common problems too. Just that your specific argument here is incorrect.