Rust dependency bloat may be an issue, but with good static analysis maybe not (the compiler can effectively remove dead code unlike JavaScript, and the IDE may be able to effectively filter it).
> So now I pose the question to you what do we do?
1. Port your application to the language/tool that fits your needs like Go.
2. Hope that a language like Zig decides to feature a standard library as good as Go.
Go's is very nice however if I remember they ran into an issue with crypto that was hard to fix due to it being so bundled to the std library.
Folks on Bluesky just pointed me in the same direction. Looks like it has potential.
I’m not as positive on it, but at least if you are, you know where to lodge support.
What about the crypto library affects how you would use Go to solve your problem?
1. https://deadmoney.gg/news/articles/migrating-away-from-rust
It seems most of Rust developers adopt the pov of web front-end developers since a few years: depend on a lot of libraries for small things, never update your project to 1.0, and abandon "quickly" to build something new... and redo it again.
I really hope that alternatives like Zig or Jai will not let the community do like what they did with Rust.
Most people prefer to build off of the work of others, rather than reinvent the world for every project. That trade off is a trade off though, and nothing prevents you from taking the other side of it.
We don’t hyper stress about it. We do take care, in some projects (like embedded ones) we need to care a lot about binary size and so pay very close attention, and we keep abreast of security issues, etc.
Dropshot wasn’t written because it was critical to the business, it was because nothing had the OpenAPI support at the time we write it. It Axum or something else did, we’d have used it. We only write our own stuff when things in the ecosystem aren’t fit for purpose. We do sometimes find that our needs are different than others and so write our own, but this isn’t borne out of concern for dependency count.
Exactly. Why this is even a point of discussion is, to me, an indictment of everyone raising it as an issue.
Honestly, when I want to compile a Rust project and see all these dependencies getting pulled in to get compiled along with the project, it gives me goosebumps, because I don't know whether these crates are safe and secured or not...
The concept of `features` when using a crate is kinda cool as "you only download / compile what you use" *but* most of the crates are very badly designed, and also developers do not tend to reinvent a very tiny wheel when they can, but heavily depend of possibly dangerous crates to just serialize or deserialize a very simple data structure...
It's very annoying, as this increases the compilation time and introduces possible unsafe behavior in larger crates.
You’re making the criticism, why not own it?
What you’re saying is the equivalent of Donald Trump’s “many people are saying”. It’s the recourse of the intellectually stunted who can’t muster a convincing argument.
turtleyacht•11mo ago
Like having mini contracts with every package, even if it's just to reproduce bugs, maintain a personal test suite, or to steer newcomers to resources.
Otherwise, we will always be in the dark about our dependencies, building our flying castles. (They float, but where's the foundation?)
Alternatively, there are open-source code scanners and bill-of-material security tools. Those could be added as triggered workflows in your projects, to run on each pull request.
As well, the author did rewrite dotenv's core features to replace it.
vsgherzi•11mo ago
turtleyacht•11mo ago
Sonar is free for open-source projects, but less package version security and more "use --ignore-scripts in npm," "don't be root in Docker container," and such.
vsgherzi•11mo ago