3 ms·

I once wanted to contribute to the popular swc project (https://github.com/swc-project/swc https://github.com/swc-project/swc). I cloned the repo, ran build, an

by rs186 1y ago

I once wanted to contribute to the popular swc project (https://github.com/swc-project/swc https://github.com/swc-project/swc). I cloned the repo, ran build, and a whooping 20GB was gone from my disk. The parser itself (https://github.com/swc-project/swc/blob/main/crates/swc_ecma_parser/Cargo.toml https://github.com/swc-project/swc/blob/main/crates/swc_ecma...) has over a dozen dependencies, including serde. Meanwhile, the heaviest JavaScript parser implemented in JavaScript is more lightweight. I decided that I should leave this project alone and spend my time elsewhere.

MeetingsBrowser 1y ago
I agree that relying on unknown dependencies is a risk, but this misses the point IMO. Number of dependencies and disk space are kind of arbitrary. > Meanwhile, the heaviest JavaScript parser implemented in JavaScript is more lightweight. The lightest weight javascript program relies on V8 to run, which has multiple orders of magnitude more dependencies. Most of which you have never heard of. At least cargo makes it easier to get a clearer picture of what the dependencies are for a program.
- munificent 1y ago
  > relies on V8 to run, which has multiple orders of magnitude more dependencies. Actually, this isn't true. (Or at least wasn't a while back.) I used to work with a bunch of ex-V8 folks and they really despised third-party dependencies and didn't trust any code they didn't write. They used a few third-party libs but for them most part, they tried to own everything themselves.
  - dathinab 1y ago
    they are also Google .. as in they can afford to rewrite everything .. can afford to suffer from not invented here syndrome .. and are under _massive_ threat of people doing supply chain attacks compared to most other projects (as they end up running on nearly any desktop computer and half the phones out there) this just isn't viable for most projects, not just resource/time investment wise, but also reinventing/writing everything isn't exactly good to reduce bugs if you haven't to reliably access to both resources _and_ expertise. Most companies have to live with having many very average developers, and very tight resource limits.
    - munificent 1y ago
      I think the folks who wrote V8 have always been this way, even before their company got acquired by Google and they switched to writing V8.
- pixl97 1y ago
  Number of dependencies isn't exactly arbitrary... If you have one huge dep it's easier to keep track you're on the latest update, also it's much less likely you'll fat finger it and import something typosquatting. Also if you're in enterprise you'll have less 100 page SBOM reports.
  - MeetingsBrowser 1y ago
    What is more likely to be vulnerable, a 100k LoC project developed by ten people, or ten 10k LoC single maintainer projects. Keeping track of the latest version is trivial with cargo.
    - pixl97 1y ago
      I work in SCA/SBOM. >What is more likely to be vulnerable, At the end of the day you are at much higher risks of one of those 10 packages getting owned by some external party and suddenly the next version is pulling a bitcoin miner, or something that steals everything it can from your CI/CD, or does a take over on your customers. And it's never 10 (well at least for JS), it's hundreds, or if you're team is insane, thousands.
    - shwouchk 1y ago
      Unlike my sibling commment, i don’t work in SBOM, but if you consider social dynamics and what trust means, it should be pretty obvious that trusting in a group of 10 strangers is much less risky than trusting in 10 separate strangers. consider the probabilities
- rs186 1y ago
  No, it has very little to do with v8 or any runtime. Those parsers run on any decent and recent enough runtime, including browsers and Node.js. If you look at the actual code, they use basic APIs in the JavaScript language that you can find in almost any other language.
constantcrying 1y ago
I am counting 13 dependencies, the rest are internal ones. Are any of these superfluous or only needed for small edge cases? Serde seems exactly a case where you absolutely should use an external dependency. Also, repository size seems an extremely irrelevant metric.
- rs186 1y ago
  13 > 12 so over a dozen dependencies. If you look at acorn or babel/parser, they barely have any dependency. Repository size is directly related to how long it takes to run a build, which is extremely important if I were to contribute to the project. > Serde seems exactly a case where you absolutely should use an external dependency. I can't see any reason a parser has a hard dependency on a serialization library.
  - constantcrying 1y ago
    >13 > 12 so over a dozen dependencies. If you look at acorn or babel/parser, they barely have any dependency. Which ones are superfluous? There are good reasons to use dependencies. If someone has solved a problem you need to solve as well it is pointless to duplicate the effort. >Repository size is directly related to how long it takes to run a build, which is extremely important if I were to contribute to the project. Totally false. There is zero inherent relation. >I can't see any reason a parser has a hard dependency on a serialization library. And because you can't see a reason there is none? It is totally meaningless to talk about any of this if you can not point out why this is superfluous.
    - rs186 1y ago
      I don't think there is any point in debating this, because apparently you are in the camp of "dependencies are ok", with or without a good reason, when a different camp is "avoid dependencies unless you really have to". You just provided an example of why dependencies explode like this. > And because you can't see a reason there is none? Somehow every other JS based parser doesn't do fancy serialization, as far as I can tell. You can come up with reasons of why one might need it, but as a user of the parser, I want the footprint to be small, and that's a requirement. In fact, that's one of the reasons I never used swc parser in my serious projects.
EasyMark 1y ago
I just built it with "git clone --depth 1 ..." and the build from cargo build --release is 2.9GB (2.3GB in the target folder)?
- eviks 1y ago
  You should also add the dev build
- pornel 1y ago
  Rust generates absurd amounts of debug info, so the default debug builds are much much larger. Zero-cost abstractions don't have zero-cost debug info. In fact, all of the optimized-away stuff is intentionally preserved with full fidelity in the debug info.

by rs186 1y ago

MeetingsBrowser 1y ago

I agree that relying on unknown dependencies is a risk, but this misses the point IMO. Number of dependencies and disk space are kind of arbitrary. > Meanwhile, the heaviest JavaScript parser implemented in JavaScript is more lightweight. The lightest weight javascript program relies on V8 to run, which has multiple orders of magnitude more dependencies. Most of which you have never heard of. At least cargo makes it easier to get a clearer picture of what the dependencies are for a program.

munificent 1y ago
> relies on V8 to run, which has multiple orders of magnitude more dependencies. Actually, this isn't true. (Or at least wasn't a while back.) I used to work with a bunch of ex-V8 folks and they really despised third-party dependencies and didn't trust any code they didn't write. They used a few third-party libs but for them most part, they tried to own everything themselves.
- dathinab 1y ago
  they are also Google .. as in they can afford to rewrite everything .. can afford to suffer from not invented here syndrome .. and are under _massive_ threat of people doing supply chain attacks compared to most other projects (as they end up running on nearly any desktop computer and half the phones out there) this just isn't viable for most projects, not just resource/time investment wise, but also reinventing/writing everything isn't exactly good to reduce bugs if you haven't to reliably access to both resources _and_ expertise. Most companies have to live with having many very average developers, and very tight resource limits.
  - munificent 1y ago
    I think the folks who wrote V8 have always been this way, even before their company got acquired by Google and they switched to writing V8.
pixl97 1y ago
Number of dependencies isn't exactly arbitrary... If you have one huge dep it's easier to keep track you're on the latest update, also it's much less likely you'll fat finger it and import something typosquatting. Also if you're in enterprise you'll have less 100 page SBOM reports.
- MeetingsBrowser 1y ago
  What is more likely to be vulnerable, a 100k LoC project developed by ten people, or ten 10k LoC single maintainer projects. Keeping track of the latest version is trivial with cargo.
  - pixl97 1y ago
    I work in SCA/SBOM. >What is more likely to be vulnerable, At the end of the day you are at much higher risks of one of those 10 packages getting owned by some external party and suddenly the next version is pulling a bitcoin miner, or something that steals everything it can from your CI/CD, or does a take over on your customers. And it's never 10 (well at least for JS), it's hundreds, or if you're team is insane, thousands.
  - shwouchk 1y ago
    Unlike my sibling commment, i don’t work in SBOM, but if you consider social dynamics and what trust means, it should be pretty obvious that trusting in a group of 10 strangers is much less risky than trusting in 10 separate strangers. consider the probabilities
rs186 1y ago
No, it has very little to do with v8 or any runtime. Those parsers run on any decent and recent enough runtime, including browsers and Node.js. If you look at the actual code, they use basic APIs in the JavaScript language that you can find in almost any other language.

constantcrying 1y ago

I am counting 13 dependencies, the rest are internal ones. Are any of these superfluous or only needed for small edge cases? Serde seems exactly a case where you absolutely should use an external dependency. Also, repository size seems an extremely irrelevant metric.

rs186 1y ago
13 > 12 so over a dozen dependencies. If you look at acorn or babel/parser, they barely have any dependency. Repository size is directly related to how long it takes to run a build, which is extremely important if I were to contribute to the project. > Serde seems exactly a case where you absolutely should use an external dependency. I can't see any reason a parser has a hard dependency on a serialization library.
- constantcrying 1y ago
  >13 > 12 so over a dozen dependencies. If you look at acorn or babel/parser, they barely have any dependency. Which ones are superfluous? There are good reasons to use dependencies. If someone has solved a problem you need to solve as well it is pointless to duplicate the effort. >Repository size is directly related to how long it takes to run a build, which is extremely important if I were to contribute to the project. Totally false. There is zero inherent relation. >I can't see any reason a parser has a hard dependency on a serialization library. And because you can't see a reason there is none? It is totally meaningless to talk about any of this if you can not point out why this is superfluous.
  - rs186 1y ago
    I don't think there is any point in debating this, because apparently you are in the camp of "dependencies are ok", with or without a good reason, when a different camp is "avoid dependencies unless you really have to". You just provided an example of why dependencies explode like this. > And because you can't see a reason there is none? Somehow every other JS based parser doesn't do fancy serialization, as far as I can tell. You can come up with reasons of why one might need it, but as a user of the parser, I want the footprint to be small, and that's a requirement. In fact, that's one of the reasons I never used swc parser in my serious projects.

EasyMark 1y ago

I just built it with "git clone --depth 1 ..." and the build from cargo build --release is 2.9GB (2.3GB in the target folder)?

eviks 1y ago
You should also add the dev build
pornel 1y ago
Rust generates absurd amounts of debug info, so the default debug builds are much much larger. Zero-cost abstractions don't have zero-cost debug info. In fact, all of the optimized-away stuff is intentionally preserved with full fidelity in the debug info.