←back to thread

302 points Bogdanp | 1 comments | | HN request time: 1.783s | source
Show context
dminik ◴[] No.44396855[source]
One aspect that I find interesting is that Rust projects often seem deceivingly small.

First, dependencies don't translate easily to the perceived size. In C++ dependencies on large projects are often vendored (or even not used at all). And so it is easy to look at your ~400000 line codebase and go "it's slow, but there's a lot of code here after all".

Second (and a much worse problem) are macros. They actually hit the same issue. A macro that expands to 10s or 100s of lines can very quickly take your 10000 line project and turn it into a million line behemoth.

Third are generics. They also suffer the same problem. Every generic instantiation is eating your CPU.

But I do want to offer a bit of an excuse for rust. Because these are great features. They turn what would have taken 100000 lines of C or 25000 lines of C++ to a few 1000s lines of Rust.

However, there is definitely an overuse here making the ecosystem seem slow. For instance, at work we use async-graphql. The library itself is great, but it's an absolute proc-macro hog. There's issues in the repository open for years about the performance. You can literally feel the compiler getting slower for each type you add.

replies(3): >>44397321 #>>44399662 #>>44400438 #
jvanderbot ◴[] No.44397321[source]
You can literally feel the compiler getting slower for each type you add.

YSK: The compiler performance is IIRC exponential in the "depth" of types. And oh boy does GraphQL love their nested types.

replies(3): >>44398452 #>>44401240 #>>44402875 #
1. tukantje ◴[] No.44401240[source]
Unironically why typescript is a perfect fit for graphql