dead code elimination is a very old shoe which get reinvented all the time, like in dotnet with "trimming" or in JS with "tree-shaking". C/C++ compiler have been doing that since before dot net was a thing, same for rust which does that since it's 1.0 release (because it's done by LLVM ;) ) The reason it gets reinvented all the time is because while it's often quite straight forward in statically compiled languages i…
> In general most code size problems in Rust aren't caused by too huge LOC of dependencies but by an overuse of monopolization *monomorphization, in case anyone got confused
And here I thought that Rust already killed unions
dead code elimination is a very old shoe which get reinvented all the time, like in dotnet with "trimming" or in JS with "tree-shaking". C/C++ compiler have been doing that since before dot net was a thing, same for rust which does that since it's 1.0 release (because it's done by LLVM ;) ) The reason it gets reinvented all the time is because while it's often quite straight forward in statically compiled languages i…
> The reason it gets reinvented all the time is because while it's often quite straight forward in statically compiled languages it isn't for dynamic languages as finding out what actually is unused is hard (for fine grained code elimination) or at lest unreliable (pruning submodules). Even worse for scripting languages. It seems to me in a strict sense the problem of eliminating dead code may be impossible for code…
Yes, even without Eval, there's a ton of reflective mechanisms in JS that are technically broken by dead code elimination (and other transforms, like minification), but most JS tools make some pretty reasonable assumptions that you don't use these features. For example, minifiers assume you don't rely on specific Function.name property being preserved. Bundlers assume you don't use eval to call dead code, too.
let uri = get_uri_from_stdin(); networking_library::make_request(uri); How is the compiler supposed to prune that?
let uri: Uri = get_uri_from_stdin().parse()?; If the library is made in a modular way this is how it would typically be done. The `HTTP` may be inferred by calls further along in the function.
No, this wouldn't work. The type of the request needs to be dynamic because the user can pass in any URI.
I'm curious if rust has this problem. The problem I notice in npm land is many developers have no taste. Example, there's a library for globbing call glob. You'd think it would just be a function that does globbing but no, the author decided it should ALSO be a standalone commandline executable and so includes a large commandline option parser. They could have easily made a separate commandline tool that include a li…
Yeah that's one huge advantage Rust has over NPM - Rust developers are a lot more skilled and crates are generally much higher quality.
Random remark: I've noticed the quality of rust libraries too. Which made me really surprised to see the overengineered mess that is the async-openai crate.
how can one take an api as simple as openai's one, and turn it to this steaming pile of manure ? in the end, i used reqwest and created my queries manually. I guess that's what everyone does...
>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 proje…
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…
You are just making stuff up. You still can not articulate why these dependencies are unnecessary.
That you in particular might have no use for the features they bring couldn't be more irrelevant. What other parsers are doing could also not be more irrelevant.
It's certainly better than in Java where LTO is simply not possible due to reflection. The more interesting question is which code effectively gets compiled so you know what has to be audited. That is, without disassembling the binary. Maybe debug information can help?
In Go, the symbol table contains enough information to figure this out. This is how https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck is able to limit vulnerabilities to those that are actually reachable in your code.
The symbol table might contain reflection metadata, but it surely can't identify what part of it will be used.
Don’t forget cmake. (It makes adding dependencies easy, and everything else basically impossible)
Sure, despite all the hate it gets, except for IDE project files, it is the best experience in C and C++ build tools since forever, including IDE integration just like those project files. I thought the whole UNIX mentality was worse is better. No build tool is without issues, my pain points with cargo, are always compiling from source, build caching requires additional work to setup, as soon as it is more than pure…
I'm curious if rust has this problem. The problem I notice in npm land is many developers have no taste. Example, there's a library for globbing call glob. You'd think it would just be a function that does globbing but no, the author decided it should ALSO be a standalone commandline executable and so includes a large commandline option parser. They could have easily made a separate commandline tool that include a li…
Historically, the borrow checker has been a good shield against developers that have no taste. Not sure how long that’ll last.
macro seems to compensate for that. there's definitely a "C++ template programming" vibe in some libraries.
That is a serious burden on the maintainers, it creates all kinds of different problems, especially if the functionality of the libraries assumes a certain execution environment. Rust doesn't just target x86 desktops.
Go doesn't just target x86 desktops either
And? Not every project had the same amount of resources.
There is a tradeoff here. Having a large, but badly maintained, standard library with varying platform support is worse than having a smaller, but well maintained, one.