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

71–80 of 124 posts

Re: I sped up serde_json strings by 20%

#71

Post by aldanor »

sweca wrote: post #10
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…

I swear the target folder for literally any project of any scale is at least several GB in size.

For a work project, my recent cargo clean removed 90 GB.

Re: I sped up serde_json strings by 20%

#72

Post by wtetzner »

s_Hogg wrote: post #67

Very strong jart feel about this person's blog, that was a nice read > We would need to reinvent the wheel, but this is quite neat if you think about it. Is this real or ironic though? I read it and started laughing at the writer but the rest of the page seems quite heavy on self-deprecation

I think it means the approach is quite neat, not the fact that it requires reinventing the wheel.

Re: I sped up serde_json strings by 20%

#73

Post by wffurr »

vecplane wrote: post #69
s_Hogg wrote: post #67

Very strong jart feel about this person's blog, that was a nice read > We would need to reinvent the wheel, but this is quite neat if you think about it. Is this real or ironic though? I read it and started laughing at the writer but the rest of the page seems quite heavy on self-deprecation

What does jart mean?

A commonly posted author: https://justine.lol/

Re: I sped up serde_json strings by 20%

#74

Post by wtetzner »

zorked wrote: post #57

> Teaching to _think_ is just as important as teaching to code, but this is seldom done Oh, the arrogance of thinking that the other person doesn't think.

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.

Re: I sped up serde_json strings by 20%

#75

Post by wtetzner »

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.

Out-of-the-box you can add serde_json to your Cargo.toml file in a single line and have JSON parsing.

    serde_json = "*"
I'm not sure I see the problem.

Re: I sped up serde_json strings by 20%

#76

Post by wtetzner »

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.

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

Re: I sped up serde_json strings by 20%

#77

Post by wtetzner »

runevault wrote: post #32
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…

I'm not sure languages without a package manager being the default are nearly as bad. When it is trivial (like running a single command line or a single line in a file like cargo.toml), having a proliferation of dependencies is so easy it almost becomes guaranteed. But in languages like c++ where not everyone uses them (even if several PMs exist) adding a dependency to a library is a much bigger deal as you either ha…

I think it's important to figure out what you're comparing though.

A language that makes it easy to pull in dependencies also encourages breaking code into separate modules.

Languages that make dependency management hard tend to have larger, heavier dependencies. Two dependencies in such a language are more likely to have duplicate functionality between them, instead of sharing the functionality through another dependency.

Is it better to vet many smaller dependencies, or fewer large ones that likely duplicate a lot of stuff? It depends on what those dependencies are.

I don't think just looking at dependency counts is that useful. Many libraries that would be a single dependency in other languages are split into several because they are useful on their own.

Re: I sped up serde_json strings by 20%

#78

Post by wtetzner »

troad wrote: post #42
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 many notable Rust projects attempt to keep third party dependencies to a minimum. I don't think this is true. The only two major Rust crates that manage to keep their dependencies light are tokio and serde, and these are highly atypical projects. For a more typical example, look at something like axum (running `cargo tree` for project with a single dependency on axum returns 121 lines). > This is really no diff…

> You add two dependencies in Rust, and suddenly you have a dozen dependencies of dependencies of dependencies, including at least three different logging crates. In the world of C, which is what Rust is trying to displace, that's just not going to pass muster.

In the world of C, how many libraries just vendor their dependencies, so they're just not easily visible in a dependency tree?

Re: I sped up serde_json strings by 20%

#79

Post by School-Cotton »

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.

Repeating the same claim more incredulously isn’t really a good debating tactic.

Re: I sped up serde_json strings by 20%

#80

Post by chipdart »

purplesyringa wrote: post #65
ramon156 wrote: post #63

Earlier quoted context omitted.

> is seldom done It's this part

Perhaps the wording was off on my part. What I meant is not that people don't think, it's that people seldom teach others to think , at least in web articles. Most posts of such format I have seen are "we did this and got this", not "we tried this, it failed because of this, then we figured out something else might work and it worked after these modifications".

> Most posts of such format I have seen are "we did this and got this", not "we tried this, it failed because of this, then we figured out something else might work and it worked after these modifications".

That doesn't resemble anything remotely related to teaching how to think. You're just logging your trial and error process, which is exactly what each and every single developer goes through on a daily basis.

What exactly do you think other developers do?

Post reply on HN