Plus the point of the marshal interface is that it’s reusable.

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

Go has this concept baked into the language. For example read and write interfaces so you can write data to an endpoint without having to worry about whether it’s a file system object, TCP/UDP socket, gzip achieve, and a plethora of other options too.

It’s a nice convenience feature and makes up considerably for the restrictions that the Go type system places.

And if you need higher performance code, or compile time safety, or have any other constraints that limit your ability to use these generalised interfaces, then you can use different APIs from the Go standard library to achieve the same thing.

You don’t need to call json.Marshal() if you don’t want to. It’s an option, but it’s just one API into the JSON toolbox.

Secondly, other languages like rust, haskell, scala, etc. Have json APIs that are typesafe and give you compile time errors if you try to use a type that doesn't support (de) serialization . In the case of rust at least, the API is also general and can be used for other data types as well.

Even in go, you could have some more type safety if Marshall took an interface (such as MarshallerTo) rather than `any`. Although then you have the problem of how you implement that interface. So I guess you probably want some kind of "derive" functionality, or macros that can approximate it for a convenient and type-safe API.

P.S. gophers like to talk about how explicit being better than implicit, but using reflection for marshalling is very implicit.

If you want type safety then pass a struct to the marshal. Which is actually the idiomatic way to do it anyway. The type safety would be in that.

I’m not going to disagree with you that Gos type system is a rather blunt tool nor that Gos expressiveness is extremely rigid compared to many other popular languages. All of that is completely true. But I don’t agree that the v2 JSON API is a good example of that problem.

The function is in the `encoding/json/v2` package. It might have a similar design, and maybe they will use the same function signature for other encoders, but it the functions are very much json specific.

> If you want type safety then pass a struct to the marshal.

But if you use a struct that has a field that can't be marshalled, you don't get a compile error, you get a runtime SemanticError. That's the problem.

But the point you keep missing is that the function signature needs to be encoder agnostic for it to work as an interface.

> But if you use a struct that has a field that can't be marshalled, you don't get a compile error, you get a runtime SemanticError. That's the problem.

And as I said elsewhere, no such fields exist.

It's a function, not a method. So it can't be part of an interface.

I suppose you could make an argument for passing it as a function argument to a higher ordered function. But that is kind of an unusual way to use such a function. And isn't a common pattern in go.

> My point here was: if you know you’re creating a struct to pass to the mashaller at compile time, then you’re already going to use JSONAble fields. So it’s not an issue.

Maybe. Maybe not. For a simple struct where all the fields are primitive types sure. But if you have a complicated hierarchy, you might miss that some strict in the hierarchy has a field that can't be marshaled.

Say you are marshaling a struct that contains a struct from a third party library, and it works fine. Then you update to a new version of that library, and that added a new field for a type that doesn't work, say a map[A]string where A is a struct. Your program still compiles fine, but then you get an error at runtime when you try to serialize something that worked before. Hopefully you have tests that catch it.

The mashaller here is a function, yes. But having a consistent signature means you can interchange those marshallers. It’s a trick I use heavily in murex to enable typed pipelines.

And I do this via a pipe interface. So it’s not uncommon to reuse function signatures for interface types (fewer runtime abstractions) while retaining some level of dynamism.

> Say you are marshaling a struct that contains a struct from a third party library, and it works fine. Then you update to a new version of that library, and that added a new field for a type that doesn't work, say a map[A]string where A is a struct.

The first mistake there is to blindly forward an API struct that you don’t control and depend on that for business logic.

Which comes back to my point about if you want type safety then you’d create a struct.

I do take your point that the compiler in smarter languages would catch this. But you’d equally be told not to do this sort of thing on those languages too.

Compile time cannot check for runtime values (not even in Rust) - is your position that fields can only be populated at compile time?

I think the same is true for channels too but I’m not near a computer to check.

https://pkg.go.dev/encoding/json/v2#Marshal says otherwise:

> The Go map key must encode as a JSON string, otherwise this results in a SemanticError

> All other Go types (e.g., complex numbers, channels, and functions) have no default representation and result in a SemanticError.

v1 has the same constraints.

The doc you linked to literally proves me right.

Because they are common types, makes sense to precautionary have the error return.

I wish they'd left `MarshalIndent` in there though. The equivalent code is super complicated and non-obvious, so it's a pain to migrate, and it's a pain when you're banging out some quick code and want to dump some readable JSON. I suppose these days the LLMs can write the complicated version for us, of course.

Not an insult to you, its just how I feel things are going, myself inculded at times.

  v := jsontext.Value(b)
  v.Indent()
  fmt.Println(string(v))

    func WithIndent(indent string) Options

    json.Marshal(v, jsontext.WithIndent("  "))

?

Or more concretely, if we had a parser generator + json parser specification that can generate efficient simdjson style parsers, then we should be able to parse json restricted to a subset of json based on a schema at least as efficiently as simdjson can parse general purpose json.

That way we could have the best of both worlds, a (potentially lazy) statically type-safe model and simdjson performance!

I still think that this is definitely doable, it's just that a lot of infrastructure needs to be built for it.

I remember reading that Meta is doing something similar with binary formats. I find it weird that there's nothing like that for json yet.

https://dl.acm.org/doi/pdf/10.1145/2714064.2660241

https://dl.acm.org/doi/pdf/10.1145/3314221.3314625

I think most people who use JSON don't want strong typing or to use schemas. If you do, you just use a different serialization format: JSON is designed to be a generic, human-readable way to basically represent any kind of data structure (since it deserializes to JS objects). So everything about JSON is working against you if you do try to enforce type/schemas on it.

A grpc-like protocol with more prescriptive type registries/discovery (over the network) and better interop with http (like grpc-gateway) would be the best approach IMO. Definitely not JSON schema

Not necessarily. It's biggest advantage is probably that it has very good interoperability. Basically every language has a readily accessible library for json, and even if you don't, it isn't that hard to write a parser and/or generator for it. And being human readable isn't something to sneeze at either.

We use JSON because it's standard, human-readable, mostly self-described and works natively with Javascript.

You can read JSON object without having to know the schema even if one exists.

Protobuf is unusablr garbage without a lot of supporting tooling.

I have been using serde without issues, and never resorted to `serde::Value`[0], the untyped option, so far.

I have yet to experience anything working against me.

[0]: https://docs.rs/serde_json/latest/serde_json/enum.Value.html

Pretty much anywhere I've come across JSON (and xml before that,) everyone expected strong typing. The fact that JSON (and xml) can represent different data than they anticipated "did not compute" in their heads.

In many cases, they were treating JSON (and xml) as dumb serializers and not even paying attention to the output and corner cases.

So yea hopefully a nice new addition but only my prompts now matter. So need to make sure they pickup on the new API.

I am using local LLMs and Go has a bunch of strengths where smaller contexts are concerned; less complicated flow of control being one of them.

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.

However it kind of makes me feel like my professional life was wasted and I don't really know what kind of future I have. One of Go's main points was you can pick it up in a weekend. What career moat do people like us have?

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.

This isn't futurology, besides a few projects that already came up on Phoronix and around here, with Assembly generation, there are enough SIGPLAN papers on ML driven compilers already.

However, starting with LLMs directly generating machine code and moving to ML directed optimization passes, you're moving the whole stadium with a crawler-transporter, not only the goalposts.

Helping compiler in a well defined way, and working on IR or driving it repeatedly to optimize the output is one thing, generating machine code from a training set is other. Let's not mix them.

"Compiler 2.0: Building the Next Generation of Compilers with Machine Learning"

https://eecs.berkeley.edu/research/colloquium/compiler-2-0-b...

There are other researchers if you interest yourself on the matter.

Then the whole iPaaS agentic coding environments like Workato and Boomi, that even if they might generate 3GL as intermediate step, you don't get to see it.

https://github.com/zwang4/awesome-machine-learning-in-compil...

Using small, purpose built ML "things" to make things better makes sense. We use them everywhere. I never argued against it, as well.

If 3 GL code has to be generated, my option list won't certainly have Go on it.

In case you answer there don't fit the same purpose, there are tiny baggers that replace shovels altogether.

This demonstrates that you continue to misunderstand the analogy.

Let's speak plainly. Someone who attempts to use LLMs to generate assembly directly will be outcompeted by someone who uses LLMs to generate code in a high-level language, which then uses an ordinary compiler to generate assembly. The value of a high-level language is that it defines a more constrained abstract machine than the machine that a CPU represents, which both humans and LLMs alike benefit from.

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

As for proven wrong,

"Frame was created over the past month largely via Claude Code. The Assembly code in all its glory can be found on GitHub."

https://www.phoronix.com/news/Frame-X11-Server-Assembly

Binary bloat is not just about size; it impacts startup time and icache. It’s basically the speed of light launch time.

So you’re telling me rust is not good for UNIX style tools.

If you code in Go, the code is more high level, prettier, simpler.

If you code in Rust, the code is more robust, efficient, faster.

Both are important for LLM, why can't we have a high level, simple language that is also robust, efficient and fast? =)

I think many variants from Rust can be stripped to make it simple, especially in type system, which is way more complicated than go.

LLM can generate very cryptic rust code.

It's really great fun to build stuff in Crystal, I don't have anything prod-grade yet to say how it scores there but the community seems to be happy about that too.

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.

I' just starting OCaml, so can't really compare, but it seems a good progress there.

Go is about as far as you can "go" to the efficiency end without becoming Rust. It's a low-overhead language (like C) but with a GC that ensures memory safety. If you want to manage memory yourself and still prove safety it gets very complicated, as we see in Rust.

First, I like programming and don't want to stop doing it just because a machine can do it too. Second, I'm pretty sure atrophied coding skills will make me worse at directing the machines, thus worse at what seems to be "the job" these days.

In theory wouldn’t atrophied coding skills not matter if models are sufficiently good at coding? I mean isn’t whats left just design and architecture and testing?

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.

Its hard to think of a skill that you’d need to build with an LLM that requires writing meaningful amounts of code by oneself. From my end all the complexity is business logic and system design.

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

No, I didn't. I claimed that if my coding ability atrophies, I expect that my ability to code through LLMs will decrease. And this is an outcome I want to avoid for the stated reasons and others.

That said, I get your point: maybe "the thing writing the code" will be as abstract as "the thing moving the electricity through transistors" at some point. And maybe I will be wrong about coding skill translating to good agent-herding skill. But I don't think I'm wrong now.

Please reread my comment. That’s not what I’m addressing.

“Programming” is a bit loaded. Do you mean thinking through and typing everything out yourself?

What design skills specifically can you only develop from continually programming in this way?

Personally I’ve found the opposite to be true. As writing out code myself has shrank to nearly 0, I now have a much shorter feedback loop on design. You get a lot more repetition and feedback when that’s basically all you are doing.

Weeks and month for to wait for a feedback in developing software? Are you the sloth in zootopia?

The longest cycle for feedback for me has only been hours. And that was about redesigning the core architecture of an app. Otherwise, it’s like 10 minutes cycle if it’s edit-compile-run, 5 minutes if it’s REPL (lisp, bash, python,…).

As I write code myself I continously take into consideration stuff like following the consistency of the entire design, whether what I'm doing is efficient, etc. LLMs are terrible at this and I don't see how you could develop such skills by prompting only.

For example, I would never produce designs that require degenerate db access patterns (linear scans, etc.). Everything I write myself always takes into account using db & network efficiently from the ground-up. Every query is an index lookup, every api request is rate limited, everything is batched and cached, so on and so forth.

LLMs meanwhile don't care about any of this. I just had Claude happily try to fetch youtube page html because the api didn't expose something. Great idea, I'd love to be banned by google for scraping.

Designing with performance in mind is black magic too, I need to notice myself that stuff that I think has no reason to be slow (pretty much nothing does) is slow and hammering the llm to finally come up with a non-stupid design that's not ridiculously slow and wasteful. Yeah, why don't we pull 2.3mb of html to update a list, sounds good.

Agents make it too easy to gloss over too much. They're great at work where i care about productivity but I've zero interest at home where the point is learning and having fun

The few times I've needed a language without a GC and used Rust and C as target languages, I've reviewed the code less and enjoyed it less.

JIT and AOT compilers, REPL development, bleeding edge GC implementations, Java, Scala, Kotlin, Clojure, C#, F# to chose from, and modern IDEs inspired by Smalltalk/Lisp Machines experience, batteries included backed and frontend development frameworks.

I hope you're not still doing this, it's nothing to brag about.

Unfortunately, the world makes it hard to keep that cycle, and so instead I mostly do 17 hours awake / 7 asleep, which makes me feel constantly tired (though less tired than 16/8 at least).

Why? Because I don’t give time to wait for code to compile on my time and I don’t have time for people to learn a new language for review at work.

Life is good! Would recommend that split.

In what sense? Go has a GC and binary sizes are relatively pretty huge. Its closer to Java and C# than C.

I'm just getting the neuron-band back together where Golang is concerned. I have done some in the past for little system tasks, but I am switching away from interpreted languages entirely for web stuff, and initially to Go, as I switch away from hand-coding to at least LLM-supported coding.

So I am a bit out of date on the pain points (I never really felt pain points when I last used it, because the jobs I was doing had very small, quite Go-friendly shapes).

I'm not entirely surprised, and I'm glad the Go team is carefully considering their interfaces before launching. But 6 years seems like a lot of work to land a JSON API.

JSON processing, quite markedly, is renown in Go for being slow, so I don't really understand why it took so long

I kind of like that the standard library doesn’t move fast. It makes it easier to fit the ecosystem into my head (unlike, for example, the JavaScript ecosystem where I find code doesn’t survive 2 years before failing to compile).

But I do agree that slow and steady produces its own problems. Your example of generics is a good one. But think the example of Go modules is another, perhaps even better, example of how sometimes the Go team really should have accelerated their efforts on.

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)

But my point was Go waited until there were multiple established 3rd party package management tools for Go already in widespread use before even releasing their own experimental implementation.

Their inaction caused far more disruption to the ecosystem because people got fed up of waiting, implemented their own, integrated it into their workflow and then had to reintegrate a whole new system all over again a year or two later.

Your point about Googles needs is the one often cited for Gos inaction. But I think that actually makes the situation worse. Because if the Go team cannot empathise with use cases outside of one bespoke enterprise, then it really shouldn’t be released as a general purpose language available for all to use.

And I say this as someone who generally likes the language.

Especially since "Go team cannot empathise with use cases outside of one bespoke enterprise" — it shows self-awareness of their shorcomings. I think it's wise to let the target audience explore the design space themselves a bit first. Considerably lowers the risk of cementing the wrong design.

I do somewhat remember the drama around this at the time, but I my impression was that of a petulent community of various dependency management projects with too much ego attached to them to see the bigger, long-term picture.

Thanks for sharing.

Put this in your go.mod:

  replace example.com/package-to-pin => example.com/package-to-pin v1.2.3

Only about a year from when the Haskell guys lent their expertise and it landing in a release. That's actually fairly quick given that it was a pretty significant change under the hood and constrained by only two releases annually.

The Go team was always clear that they didn't have the necessary expertise internally and were relying on the open source community to lend a hand. Unfortunately, open source doesn't mean open willingness to contribute.

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, 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

If you go back and watch the original Go announcement it was made abundantly clear that they believed Go did need generics at the time but that they didn't have the expertise to do it. Yes it is true that the book was already written on it, but that doesn't mean anyone on the Go team was familiar with it or had the time to become familiar with it. Programming languages do not require gods to design them. Imperfect humans can too.

The experts on HN who know all the ins and outs of generics could have contributed but, you know, shitposting "go doesn't have generics lol" was apparently a better use of their time. But it is certainly not for anyone else to do decide how they live their life.

Go culture is not welcoming to experts contributions, Rust, D, C#, Swift and others, heck even Java, are more open arms to language designers.

You'd think one of the HN experts would have shown up to offer that expertise, but I guess there was a lot of "go doesn't have generics lol" to get out.

The Haskell muscle had proven their skills already with Featherweight Java, in 2006.

But obviously "go doesn't have generics lol" comments were even more important. Imagine what would have happened to HN if that wasn't repeated multiple times daily for years!

Within our company I saw people in other teams writing their own optimised JSON libraries for whatever hellish reason. I always reiterated the point that as soon as that app made a single IO request all those nanosecond savings are invisible. Yes, it affects your total CPU time for processing a request but compute was never ever a limitation for us and it's likely not a limitation for most people. And if the trade off is your app needs scale slightly larger versus writing custom JSON code or pulling in a third party dependency, then I'm accepting the larger scaling.

The biggest benefit of encoding/json/v2 isn't the speed, it's the improved API.

Wordpress powered by PHP is also the most widely deployed CMS.

That argument is not as great as you think it is.

> That argument is not as great as you think it is.

But at least it is an argument in contrast to the comment I was replying to.

Completely unrelated: can anyone tell me why language authors introduce in/out/inout function parameters (see also C#).

It feels like this is some rather bad workaround for something that breaks assumptions about parameters being passed into the function.

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

   // value also available

If the allocation is owned by the calling function which uses it internally and then doesn’t return it, it can be a stack variable. Or the same allocation can be reused many times in a loop. Or an array of allocations can be made all at once with foreknowledge of the total number.

But you might be conflating that with in/out for Contra/Co-variance when specifying a generic.

They are one way to implement multiple return values. For multiple returns, tuples can be used.

I feel that is the kind of broken default that will come back and bite a bunch of people, and will eventually need to be fixed in a v3.

    type ListUsersResponse struct {
        Users []User `json:"users"`
    }

    userRows := db.Query(...)
    var users []api.User
    for _, user := range userRows {
        users = append(users, api.User{...})
    }

This is definitely not what I expect in other language. I would argue this is a quick of Go though and not JSON's fault.

Just look at the inane rules for map and slice access, what gets nil and what is panic. Even if that were consistent, then you'd still left to wonder if json.field was truly zero or not there.

But that depends on whether they add monadic error handling in the first place, and if they do, if they intend to migrate the language's APIs to it - I don't think they would because the existing error handling is faster and everywhere.

Clearly it isn't, otherwise every language would have sorted it out by... a long time ago.

You can still use it though, and I built my tiny decimal library around it: https://github.com/ncruces/decimal

A JSON parser MAY accept non-JSON forms or extensions.

An implementation may set limits on the size of texts that it accepts. An implementation may set limits on the maximum depth of nesting. An implementation may set limits on the range and precision of numbers. An implementation may set limits on the length and character contents of strings.

At then there’s more vagaries with JSON schema.

Who knew the same object could have completely different definitions based on some flags?

There is no introspection and speed is superb. I would definitely recommend jsontext as a parser for anything non-straightforward.

I'm happy it's getting fixed!

"What if it sucks?"

"There are now TWO ways to do each thing! No more than TWO! I promise!"

It's like python again.

So yeah, if you ignore most of what matters, everything is the same.

The problem with “Batteries Included” is that batteries run out of juice eventually.

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.

"Sir we need a loop" "We will have for loop, and nothing else." "Only one lo.." "Only for loop"

I love it too, it’s a great way to keep the stdlib moving without actually breaking anything. Simple and efficient design.

https://news.ycombinator.com/item?id=44893833

Still searching the true solution:

https://github.com/golang/go/issues/27179#issuecomment-53634...

A proposal of the missing datatype for this operation mode has been just accepted:

https://github.com/golang/go/issues/69559