351–360 of 593 posts
"A little copying is better than a little dependency." - grab the parts that you need and then include the library only in a test to ensure alignment down the line, an idea I liked a lot.
Earlier quoted context omitted.
There should be a second stdlib with relaxed stability guarantees. Don't fill the normal stdlib full of cruft that can never be changed again.
So we reinvent Java's bloated SDK again, with all of the "javax" packages. What's old is new?
Perhaps because it's a good idea.
Earlier quoted context omitted.
>A great std lib is obviously the solution. Some Rust defenders are talking it down by giving Python as counter example. Python's standard library is big . I wouldn't call it great, because Python is over 30 years old and it's hard to add things to a standard library and even harder to remove them.
There are things added from tine to time, but yeah, some stuff in there just feels dated at this point. I’m still hoping we can get a decently typed argparse with a modern API though (so much better for tiny scripts without deps!)
Argument parsing, in partucular, is a great place to start realizing that you can implement what you need without adding a dozen dependencies
> I can't rewrite the world, an async runtime and web server are just too difficult and take to long for me to justify writing for a project like this (although I should eventually just for a better understanding). I did this and it only solved half of the bloat: https://crates.io/crates/safina - Safe async runtime, 6k lines https://crates.io/crates/servlin - Modular HTTP server library, threaded handlers and async p…
Why the need for going back to threaded development ?
Earlier quoted context omitted.
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…
And from Internals discussion ( https://internals.rust-lang.org/t/add-some-form-of-precompil... ) it seems this causes more problems than it solves. It requires huge storage, for each combination of targets, and even if it is was solved some members of Rust community would see it as a step back. Me included. They are hard to audit and are step back to OSS nature of Rust.
A true enough statement, but "Rust" is unnecessarily specific. Dependencies are getting scary in general. Supply chain attacks are no longer hypothetical, they're here and have been for a while. If I were designing a new language I think I'd be very interested in putting some sort of capability system in so I can confine entire library trees safely, and libraries can volunteer somehow what capabilities they need/offe…
Java and the .NET Framework had partial trust/capabilities mechanisms decades ago. No one really used them and they were deprecated/removed.
Earlier quoted context omitted.
I have a lot of sympathy for this viewpoint, but I also ask that we try to remind ourselves. We are asking for professionalism from hobby projects. If you want a mature protobuf implementation you should probably buy one. Expecting some guy/gal on the internet to maintain one for your for free seems ill advised.
> I have a lot of sympathy for this viewpoint, but I also ask that we try to remind ourselves. We are asking for professionalism from hobby projects. Nobody is asking for professional quality standards from hobby projects. At best, they are asking for hobby projects to advertise themselves as such, and not as "this is a library for [x] that you can use in your stuff with the expectations of [maintenance/performance/c…
I suspect this is in no small part because figuring out a licensing (edit: pricing!) model that is both appealing to consumers and sustainable for authors is damn near impossible.
Earlier quoted context omitted.
Kind of true, when not using vcpkg/conan.
Don’t forget cmake. (It makes adding dependencies easy, and everything else basically impossible)
Earlier quoted context omitted.
yes, it's not a issue of code size but a issue of supply chain security/reviewability it's also not always a fair comparison, if you include tokio in LOC counting then you surely would also include V8 LOC when counting for node, or JRE for Java projects (but not JDK) etc.
And, reductio ad absurdum, you perhaps also need to count those 27 million LOC in Linux too. (Or however many LOC there are in Windows or macOS or whatever other OS is a fundamental "dependency" for your program.)
I think that https://blessed.rs does a pretty good job of providing recommendations for things that probably can't be crammed into the standard library, but which you'll almost certainly end up needing at one point or another. I honestly like that system a lot, it makes it so that the only packages you need to worry much about are usually doing something rather specific.
It lets you track what packages you "trust". Then you can choose to transitively trust the packages trusted by entities you trust.
This lets you have a policy like "importing a new 3rd party package requires a signoff from our dependency tzar. But, packages that Google claim to have carefully reviewed are fine".
You can also export varying definitions of "trust". E.g. Google exports statements like:
- "this package has unsafe code, one of our unsafe experts audited it and thinks it looks OK"
- "this package doesn't do any crypto"
- "this is a crypto library, one of our crypto experts audited it and thinks it looks ok"
https://github.com/google/rust-crate-audits/blob/main/auditi...
Basically it's a slightly more formal and detailed version of blessed.rs where you can easily identify all the "it's not stdlib, but, it's kinda stdlib" stuff and make it easily available to your team without going full YOLO mode.
It can also give you a "semi-YOLO" approach, it supports rationales like "this package is owned by a tokio maintainer, those folks know what they're doing, it's probably fine". I think this is a nice balance for personal projects.