Comment by yarekt

2 years ago

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

12 comments

yarekt

Reply
rqtwteye  2 years ago

I think Newtonsoft is quite ok, but the MS library lacks a lot.

  • nathanaldensr  2 years ago

    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.

Yoric  2 years ago

Are then even worse than Go's?

  • tmpz22  2 years ago

    What is bad about encoding/json?

    • TheDong  2 years ago

      What do you think the following does?

          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.

      1 reply →