As with everything, there’s some truth to that, but also C#’s json parsing libs are sub-par… and that’s really the least that a modern language should do well
Your information is very out of date. Microsoft long ago worked with the Newtonsoft.Json creator when introducing their native .NET replacement for Newtonsoft.Json. Performance in the new set of libraries is excellent as they rely heavily on the newer performance primitives like Utf8String, Span, etc.
No, it never does. There are better containers than dynamic, that do not have its performance drawbacks and have way better UX. The fact that this does not raise an eyebrow is a legitimate concern over the state of the codebase that uses it!
type Data struct {
Moon string `json:"m"`
Sun string `jsn:"s"`
}
func main() {
var d Data
err := json.Unmarshal([]byte(`{"m": "m1", "M": "m2", "Moon": "m3", "s": "s1"}`), &d)
fmt.Printf("err=%v, data=%+v\n", err, d)
}
The answer is "Moon:m2 Sun:"
In list form:
1. Specifying unmarshaling shapes isn't checked by the compiler at all, typoing `json:"s"` as `jsn:"s"` should be a compiler error in any sane statically typed language, but in go, struct tags are untyped strings, it does not help you.
2. There are hidden unchangeable unmarsheling rules, like the fact that Moon=m2 is because unmarshaling is case insensitive, even when you specify an exact key name.
3. It's very slow, due to reflection.
4. The API also is not really type safe, things like `json.Unmarshal([]byte, d)` return an error, but should instead not compile because that's a type-error (non-pointer passed to function that requires a pointer).
5. It's slow. It requires a lot of allocation.
6. `json.RawMessage` is subtle and difficult to use
7. It can't stream, so it's very easy to open yourself up to DoS, or to run across json documents `encoding/json` simply cannot handle
I can't think of any other supposedly statically typed language, other than C, where the most commonly used json library integrates so poorly with the language's type system.
Rust's `serde` is what a good well-typed json library looks like.
No matter how smart people are or how much money they get, they won’t create something good if the incentives for the individuals aren’t there. Everyone wants to prove that they are above the pack by instead implementing llms from scratch and boosting on Twitter, even though they just followed a guide for a week.
Im not sure how to fix it, but I think it starts with management that are strong willed, have pride, are aligned with the customers are able to make the developers proud in turn and dishing out low status tasks to everyone from time to time.
Thanks for the link. It looks like it might be a bit less painful?
It's still a pretty sharp disappointment to compare Go's json/encoding to Python's Pydantic or Rust's serde. One is all sharp edges, bad DX that permeates every use you make of them, and its only upside is that it provided as part of the stdlib. The other two are unobtrusive and just work.