I sped up serde_json strings by 20% • Hacker News Board

Re: I sped up serde_json strings by 20%

#41

Post by Lvl999Noob » Sat, Aug 24, 2024, 5:41 AM UTC

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…

The thing is, when adding dependencies _isn't_ trivial, you end up vendoring. You aren't gonna thoroughly test your command line parser if it is a very small feature of your overall project. A dedicated command line parser lib will (more likely than you in this case) thoroughly test their implementation.

Re: I sped up serde_json strings by 20%

#42

Post by troad » Sat, Aug 24, 2024, 6:13 AM UTC

echelon wrote: post #29

troad wrote: post #16

Earlier quoted context omitted.

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…

> 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 different from any other language.

> You're holding Rust up to a standard that nothing meets.

Respectfully, I think you're creating a bit of a false dichotomy here. I'm not demanding perfection, I'm merely noting that I've found Rust dependency trees to grow noticeably faster than dependency trees in equivalent languages. 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.

Rust is a very fine language with a bit of a dependency addiction (a dependency dependency?). I honestly don't see what service it does to the language to pretend otherwise.

Re: I sped up serde_json strings by 20%

#43

Post by [deleted] » Sat, Aug 24, 2024, 6:46 AM UTC

SkiFire13 wrote: post #33

troad wrote: post #16

Earlier quoted context omitted.

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…

Let's be real about dependencies https://wiki.alopex.li/LetsBeRealAboutDependencies

[deleted]

Re: I sped up serde_json strings by 20%

#44

Post by haberman » Sat, Aug 24, 2024, 6:50 AM UTC

SkiFire13 wrote: post #33

troad wrote: post #16

Earlier quoted context omitted.

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…

Let's be real about dependencies https://wiki.alopex.li/LetsBeRealAboutDependencies

> A medium-sized Rust project can easily tip the scales at 2-300 crates, which is still rather more dependencies than anything I’ve looked at here, but that’s explained by the simple fact that using libraries in C is such a monumental pain in the ass that it’s not worth trying for anything unless it’s bigger than… well, a base64 parser or a hash function.

It's odd that this article spends so much time arguing that Rust is no different than C or C++, only to concede at the end that Rust projects do have more dependencies.

Re: I sped up serde_json strings by 20%

#45

Post by rapsey » Sat, Aug 24, 2024, 7:04 AM UTC

INGSOCIALITE wrote: post #17

38 wrote: post #8

Earlier quoted context omitted.

this 100%. serde is a bloated monster, its sad that its the popular JSON, because all it does is make Rust look bad in my opinion. here are some smaller options: https://lib.rs/crates/humphrey_json https://lib.rs/crates/rust_json https://lib.rs/crates/sj

can rust use the json-c library?

People use rust for its memory safety.

Re: I sped up serde_json strings by 20%

#46

Post by devjab » Sat, Aug 24, 2024, 7:12 AM UTC

echelon wrote: post #29

troad wrote: post #16

Earlier quoted context omitted.

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…

> 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…

It’s different from Go, but then, Go is probably not the language you’re going to replace Rust with.

(I know it’s exactly different from Go’s dependency management, but you frankly rarely need any thing outside of the STL in Go.)

Re: I sped up serde_json strings by 20%

#47

Post by alexchamberlain » Sat, Aug 24, 2024, 7:17 AM UTC

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…

I think the GP's point was that all modern languages (and some of the older ones) have this problem - in fact, JS is infamous for it. Therefore, I don't think it's really a pro or a con on its own - only in the context of your business and problem.

Re: I sped up serde_json strings by 20%

#48

Post by wiseowise » Sat, Aug 24, 2024, 7:32 AM UTC

echelon wrote: post #29

troad wrote: post #16

Earlier quoted context omitted.

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…

> 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.

Re: I sped up serde_json strings by 20%

#49

Post by wiseowise » Sat, Aug 24, 2024, 7:34 AM UTC

purplesyringa wrote: post #12

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…

> 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.

Re: I sped up serde_json strings by 20%

#50

Post by wiseowise » Sat, Aug 24, 2024, 7:38 AM UTC

throwup238 wrote: post #19

jwells89 wrote: post #15

Earlier quoted context omitted.

Built in JSON encoding/decoding is one of the things I’ve enjoyed about Swift. It’s nice when it’s not necessary to shop around for libraries for common needs like that.

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.