This is mostly why I have come back to Go.

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.

Truly the argument can be made either way.

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? =)

As I do more agentic coding, I am starting to feel strongly that I need to set aside a project -- and time -- for strictly hand-coding, using AI (if at all) only to explain things, never to write any code.

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.

I still prefer Go over the alternatives because I'm reviewing the code carefully and trying to make it all look as good as if I'd written it very carefully by hand.

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.

People are sleeping on Go as a LLM language of choice. Everyone trying to rewrite in rust which is fine and rust is fine. However its compile times are several orders of magnitude greater than Go. You can have LLMs write and compile 20 apps in the time one rust app compiles. I've got a Go personal project that would take hours for rust to compile, I can't imagine making the same velocity in Rust. Though I do see the workplace appeal of bringing back the xkcd "compiling" meme.

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?

Some languages have a culture of doing things correctly and conforming strictly to the spec. These languages have indeed sorted it out years ago. Haskell for example. Any language that doesn’t have a special number type for JSON is a half-assed implementation, because 1e1000 is a perfectly valid JSON number that is beyond the typical IEEE754 double precision floating point numbers; does your language handle that correctly? Haskell does. This is but a small example of a strong culture bias towards correctness.

Ok so nothing is simple then?

I'm not sure if I'm missing something, but isn't this functionality just moved into jsontext? https://pkg.go.dev/encoding/json/jsontext#Value.Indent

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

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

?

I was working on metaparsing earlier this year (specifically over grpc because of its better support for types and better serialization format).

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

This approach is called "staged parsing":

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

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

Sometimes I wonder about Go's velocity - generics (something that I still haven't used beyond the tutorials) took an age as well

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

I think it'll bite some people, but probably is the better default for JSON specifically. Most of the nil-maps-become-null thing is just an extension of Go defaulting to nil for empty arrays and maps, which is usually not what you expect when you're writing a JSON schema like

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

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

Can you explain why? This seems like the appropriate expectation to me, given how JSON is constructed and consumed.

In Go, it’s a question of who owns the allocation. If you return a pointer type allocated within the function, the answer is “no one,” so the pointer escapes and has to be managed by the garbage collector.

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.

`out` params in C# are params that must be set within the function. They are way to implement multiple return values and tell the caller "this is written to, not read from."

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

The parameters named "out" here are not "output parameters" in the way you seem to be thinking. They are "input parameters" named "out", because they are the buffer or pipe you want the data written to.

"in" and "out" are the names of the parameters, not qualifiers.

C# `out` is kinda nice because it can be `var`d and used directly.

> why does marshal return an error? the only reason the marshal can return an error is that the input type is not marshalable

Not necessarily. Among other things, MarshalJSON methods called during marshaling can return an error for whatever reason the developer sees fit - one possibility that comes to mind is that part of the object tree being marshalled is lazily loaded, and failed to do so.

And, as others have mentioned, there are types like "any" whose marshalability can't be determined at compile time. Those types aren't necessarily at the top level, either; they could appear anywhere in the object tree.

Types may be mostly marshallabble, have a subset of values that are unmarshallable. E.g. non-finite floats.

AFAIK it's mostly because of floats. JSON doesn't support `NaN` and `infinity` for example.

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

I wouldn’t class unmarshallable data as a compile time error.

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

Then write yourself a MustMarshal wrapper that panics.

JSON is a runtime input of unknown type but in your example those are known types so the compiler can catch them.

i meant i hoped it's panic as opposed to return an error. if there was an error, how am i supposed to handle it? can i tell the user hey sorry my bad it's likely a code error? crash is better than possible eating the error siliently

do not know at compile time that input is not marshalable, every language marshal must return error for this reason, not only golang

It is trivial to ignore an error in Go if you know your use case cannot result in one. But at the end of the day, json.Marshal takes an `any` as a parameter, so it must return an error.