Hacker News

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

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

I definitely want jsonschema, it's a standard and i can use it for many tools. openapi spec is also a standard and built on top of jsonschema. I can use jsonschema to generate models, types, servers, client sdks, automate forms etc. I think it's better than grpc for some of these things, plus protobufs and grpc have bunch of tooling that i can pretend to understand but in depth i don't really.

> I think most people who use JSON don't want strong typing or to use schemas.

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 think most people who use JSON don't want strong typing or to use schemas.

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.

Ironically Go has(d) json.Number which almost no one used, so it got dropped from v2: https://pkg.go.dev/encoding/json#Number

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

The spec (RFC 8259) leaves significant leeway to implementations:

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.

Add to that things like duplicate keys being allowed by the spec. There’s a lot of implementation choices to decide on.

And then things can get really complex with JSON Schema.

    func WithIndent(indent string) Options

For like 99% of use cases encoding/json was fine. Of course improvements are welcomed. But personally I've lead development of the backend of part one of the biggest sites of its kind in the world, and we just used encoding/json and net/http. Most of our use cases are just building APIs, client facing ones, internal ones, trusted third-parties. These systems have pretty high throughput, more than most people will ever work on.

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.

I think in the case of JSON, it was “good enough”. People who found this to be a problem would use one of the many 3rd party options.

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.

> generics (something that I still haven't used beyond the tutorials) took an age as well

Only about a year from when the Haskell guys lent their expertise in designing it 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 capabilities internally, despite a lot of failed efforts trying anyway, and were relying on the open source community to lend a hand. Unfortunately, open source doesn't mean open willingness to contribute. It turns out that for all the experts on HN, posting "go doesn't have generics lol" was preferable to helping out.

Go is an incomplete language masquerading as a simple one.

not a lot of overloading complexity, very verbose with a small total language structure too helps.

No not a brag. I haven't done this in a long time. It's really unhealthy but I was trying to get a startup off the ground and became obsessed. Don't recommend it.

As long as you do it because you want to and not because you're forced to for work or something who cares? Whatever gives people energy

Efficient code means code with a large amount of embedded assumptions. Code that's more generic is almost always less efficient.

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.

OCaml fits your bill. Super fast compile times and also very fast runtime.

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

Goose?

Swift

If I want simplicity and maintainability, I’d pick Kotlin over Go. If I want speed, I’m picking Rust over Go. Why would I ever pick Go? It’s the best at nothing.

JVM and .NET platforms.

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.

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

Do it! I have the same feeling and the hardest part is picking something that you are interested in. I have just kept the idea of "thinking of ideas" on my mind for a few days once I finish something. I usually come up with a few ideas if I'm always considering any little thing for a project. It has been fun and I have learned a few things along the way - more than I feel I do letting AI write most of the code.

I haven't actually tried it yet, but I think it'd be good to write a dsl for whatever you're doing. Then have ai make an interpreter to run it. Sort of as a way to stay... interested? Engaged?

That's exactly how i do all my personal projects. No agents, AI just for planning/research/debugging and occasionally for small bits of code i am not super interested in. For example I'm currently working in Go, but need to use a C library, and don't know C much at all. So when i get stuck with the C interop parts, sometimes i let the AI write bits of C for me, or let it write scripts for cross-compiling or other stuff i just find to be a pain. But I'm doing all the writing and logic myself.

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

My only issue with it is that you can't ship a wasm go app in under 2mb. With rust you can make it under 100kb.

I would rather have LLM directly generate machine code, and best of all, macro Assemblers are blazing fast for decades.

If you pass a pointer into a function, the Go compiler can (and sometimes does) allocate it on the heap. Go has no allocation/ownership semantics, tragically, so the best we can do is depend on undefined behavior regarding the escape analyzer and hope the Go team doesn’t break it (which is a relatively safe assumption, considering that it’s unlikely that the Go team would start allocating things on the heap that were previously allocated on the stack—Go rarely regresses performance like this).

> They are way to implement multiple return values

They are one way to implement multiple return values. For multiple returns, tuples can be used. In fact, async methods can’t declare out params

Erm... what do you mean?

> 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

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.

Not the OP, but serializing both nil and empty arrays to the same json string means round tripping will not work for all objects.

That seems like a bad default to me.

It could be if go had a more powerful type system.

A generic Must[T] you mean ;)

The GP is talking about compile time errors. You’re discussing exceptions, which is still a runtime check