3 ms·
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
by yarekt 2y 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
- rqtwteye 2y agoI think Newtonsoft is quite ok, but the MS library lacks a lot.
- nathanaldensr 2y agoYour 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.
- rqtwteye 2y agoI may indeed be outdated. Does Microsoft now support deserializing into dynamic for example?
- neonsunset 2y agoYou should never do that. Please do not, and I can't stress this enough, use `dynamic`. If you need DOM-style JSON handling, please use JsonDocument and JsonNode instead: https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/use-dom https://learn.microsoft.com/en-us/dotnet/standard/serializat...
- rqtwteye 2y agoThere are plenty of cases where dynamic saves a ton of code.
- neonsunset 2y agoNo, 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!
- Yoric 2y agoAre then even worse than Go's?
- tmpz22 2y agoWhat is bad about encoding/json?
- pkaye 2y agoThere is a version 2 being implemented to fix some of the known issues. https://github.com/golang/go/discussions/63397 https://github.com/golang/go/discussions/63397 https://pkg.go.dev/github.com/go-json-experiment/json https://pkg.go.dev/github.com/go-json-experiment/json
- Yoric 2y agoThanks 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.
- TheDong 2y agoWhat 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.