Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I sped up serde_json strings by 20%

purplesyringa.moe

Post reply on HN
Print view View original

91–100 of 124 posts

Re: I sped up serde_json strings by 20%

#91

Post by ModernMech »

wiseowise wrote: post #48
echelon wrote: post #29

Earlier quoted context omitted.

> The dependency trees for any meaty Rust project quickly become pretty horrifying. s/Rust// This is really no different from any other language. At least Rust, with Cargo, makes it easy to scan your dependencies. And many notable Rust projects attempt to keep third party dependencies to a minimum. C++ gives you absolutely nothing to work with. Other languages with package managers don't keep dependency trees shallow…

And yet with Python and JS I don’t need to pull a freaking third-party library for something as basic as JSON.

If I don't need it, it's not basic it's just useless.

Re: I sped up serde_json strings by 20%

#92

Post by ModernMech »

wiseowise wrote: post #50
throwup238 wrote: post #19

Earlier quoted context omitted.

Almost nobody is shopping around Rust JSON libraries unless they need some specific feature not provided by serde and serde_json. They are the default everyone reaches for.

The moment you NEED to include a library to parse some basic JSON file - you’ve lost already.

Based on your other reply about JSON being a "basic" feature I assume you do a lot of work with JSON.

What you need to understand is not everyone works with JSON, and for them it's a feature to not have JSON parsing code in their binaries. It's not a loss for them.

Re: I sped up serde_json strings by 20%

#93

Post by hombre_fatal »

wiseowise wrote: post #49
purplesyringa wrote: post #12

Earlier quoted context omitted.

> Rust should have Jason built in. I don't think this is a reasonable approach. That's just a way to introduce bloat. Importantly, std does not differ from other crates, except for stability guarantees, so there would be no positive here. All it does is link the library's release cycle to the compiler's. (In fact, rustc-serialize used to be built-in, so Rust tried to go that way.) But also, serde_json isn't large by…

> I don't think this is a reasonable approach. That's just a way to introduce bloat. Can this meme die already? The fact that out of the box install of Rust can’t parse JSON is a joke, and you know it.

I don’t want to wait on language releases to get updates to json, regex, etc. Nor do I want a crappy stdlib impl of something to become widespread just because it comes out of the box like Go’s worst of breed html templating and http “routing”.

Re: I sped up serde_json strings by 20%

#94

Post by wtetzner »

7bit wrote: post #88
wtetzner wrote: post #74

Earlier quoted context omitted.

I don't think there's any arrogance in the statement. It doesn't assume others don't think. It's simply observing that most blog posts and how-to articles show the final result, but not necessarily the steps that were needed to get there.

I don't see what one has to do with the other.

I'm not really sure I understand what you're saying and/or asking.

As far as I can tell, the statement in question was simply saying that showing the steps to come to a solution is rare, and also that it helps to teach how to think (how to solve a problem). I guess don't see where the arrogance lies.

Re: I sped up serde_json strings by 20%

#95

Post by wiseowise »

hombre_fatal wrote: post #93
wiseowise wrote: post #49

Earlier quoted context omitted.

> I don't think this is a reasonable approach. That's just a way to introduce bloat. Can this meme die already? The fact that out of the box install of Rust can’t parse JSON is a joke, and you know it.

I don’t want to wait on language releases to get updates to json, regex, etc. Nor do I want a crappy stdlib impl of something to become widespread just because it comes out of the box like Go’s worst of breed html templating and http “routing”.

Somehow Python and JS can get away with json in std lib, but thing that builds binaries can’t?

How often does it even need to be updated to parse freaking json?

Re: I sped up serde_json strings by 20%

#96

Post by wiseowise »

DougBTX wrote: post #56
wiseowise wrote: post #49

Earlier quoted context omitted.

> I don't think this is a reasonable approach. That's just a way to introduce bloat. Can this meme die already? The fact that out of the box install of Rust can’t parse JSON is a joke, and you know it.

Rust has a great package manager, so moving libs into std doesn’t bring much benefit. On the other hand a change like this perf improvement can be released without tying it to a language version, that’s good too.

> On the other hand a change like this perf improvement can be released without tying it to a language version, that’s good too.

And you pay for that by having literally no way to parse something ubiquitous like json out of the box on install, relying to either installing third party lib (which is yet another security attack vector, requires yet another approval for upgrade, API can change on a whim by maintainer and other can of worms) or by using other language.

Re: I sped up serde_json strings by 20%

#97

Post by wiseowise »

wtetzner wrote: post #76
wiseowise wrote: post #48

Earlier quoted context omitted.

And yet with Python and JS I don’t need to pull a freaking third-party library for something as basic as JSON.

Nope, instead it's pulled into every project whether you need it or not.

Pulled how?

Re: I sped up serde_json strings by 20%

#98

Post by wiseowise »

ModernMech wrote: post #92
wiseowise wrote: post #50

Earlier quoted context omitted.

The moment you NEED to include a library to parse some basic JSON file - you’ve lost already.

Based on your other reply about JSON being a "basic" feature I assume you do a lot of work with JSON. What you need to understand is not everyone works with JSON, and for them it's a feature to not have JSON parsing code in their binaries. It's not a loss for them.

Where did you get a notion that JSON parsing code will end up in a binary if it’s not used? Or Rust compiler is so obtuse it can’t tree shake unused code?

Re: I sped up serde_json strings by 20%

#99

Post by samatman »

troad wrote: post #16
zadokshi wrote: post #3

Serde json has 3gb of dependencies once you do a build for debug and a build for release. Use serde on a few active projects and you run out of disk space. I don’t know why json parsing needs 3gb of dependencies. I’m all for code reuse but Serde for json is a bit of a dogs breakfast when it comes to dependencies. all you need is an exploit in on of those dependencies and half of the rust ecosystem is vulnerable. Rust…

Dependency bloat is an issue with Rust in general. The dependency trees for any meaty Rust project quickly become pretty horrifying. Auditing all these dependencies is infeasible, and my level of confidence in a lot of them is fairly low. I worked with Rust for a few years, and with the benefit of a few years' experience, I don't think I'll be touching Rust again until the ecosystem matures a great deal (which will o…

> Though Zig might edge out Rust for this use case once it stabilises.

Zig has a meaningful advantage in the context of this discussion: lazy compilation. The compiler won't even semantically analyze a block of code unless the target requires that to happen.

Currently, dependencies are more eager than they really need to be, but making them just as lazy as compilation is on the roadmap. Lazy compilation means no tree shaking is needed, and it means that the actual build-graph of a program can be traced on a fine-grained level. We might not be able to audit a hundred dependencies, but auditing the actual used code from all those dependencies might be more practical.

This is well positioned to handle a common pattern: `small-lib` provides some useful stuff, but also has extensions for working with `huge-framework`, and it needs to have `huge-framework` as a dependency to do so. Currently this means that the build system will fetch `huge-framework`, but if we can get it lazy enough, even that won't have to happen unless the code consuming `small-lib` touches the `huge-framework` dependency, which won't happen unless the program itself needs `huge-framework`.

Existing build systems don't do such a great job with that kind of structure, and the culprit is eagerness.

Re: I sped up serde_json strings by 20%

#100

Post by jessekv »

wiseowise wrote: post #95
hombre_fatal wrote: post #93

Earlier quoted context omitted.

I don’t want to wait on language releases to get updates to json, regex, etc. Nor do I want a crappy stdlib impl of something to become widespread just because it comes out of the box like Go’s worst of breed html templating and http “routing”.

Somehow Python and JS can get away with json in std lib, but thing that builds binaries can’t? How often does it even need to be updated to parse freaking json?

Python's json is an often-quoted example of why not to have it in the standard lib. There are some bad defaults that no one can fix for stability reasons. Though I admit it does come in handy sometimes.

In production, I've lately seen serde_json backed python implementations, this makes sense for performance and memory safety.

Post reply on HN