Yes, offloading complexity to a separate project which has already invested more time into code quality than I could possibly justify.
As for your second point, I don’t care who solved the problem. If you care, I hope you’re smelting your own sand to build your own CPU and assembly language. But I’m obviously also not solving the exact same problem as the library already solved.
My problem was with the first line of your comment:
Yeah, I’ve given up trying to know all the libraries in my projects.
This leads me to assume that you don’t actually know that those dependencies are as well maintained as you claim.
Obviously dependencies are important and make sense to use in many cases, but using trivial dependencies to speed up development isn’t good.
As for your second point, I don’t care who solved the problem. If you care, I hope you’re smelting your own sand to build your own CPU and assembly language. But I’m obviously also not solving the exact same problem as the library already solved.
I was just saying it isn’t you who solved the problem in that case, really, as the hard work was done for you. Honestly though, it was pointless and rude so I apologise.
This leads me to assume that you don’t actually know that those dependencies are as well maintained as you claim.
Well, I can’t guarantee that none of them are buggy, unmaintained etc… But that’s why I prefixed that sentence with “I feel”.
On average, it seems to me like the code quality is a good bit higher than I’m able to produce under money/time constraints.
In particular, even the worst libraries tend to be not as bad as they may be in many other languages, because Rust’s strict type system + compiler enforces quite a bit of correctness on its own.
Well, and the good libraries are just obsessed with correctness and performance, so they drag code quality upwards, even if they introduce a mild risk of a transitive dependency being a dud…
Yes, offloading complexity to a separate project which has already invested more time into code quality than I could possibly justify.
As for your second point, I don’t care who solved the problem. If you care, I hope you’re smelting your own sand to build your own CPU and assembly language. But I’m obviously also not solving the exact same problem as the library already solved.
Why are you looking for conflict?
If you want to build something from scratch, you first have to invent the universe :) (paraphrased from Carl Sagan)
My problem was with the first line of your comment:
This leads me to assume that you don’t actually know that those dependencies are as well maintained as you claim.
Obviously dependencies are important and make sense to use in many cases, but using trivial dependencies to speed up development isn’t good.
I was just saying it isn’t you who solved the problem in that case, really, as the hard work was done for you. Honestly though, it was pointless and rude so I apologise.
Apology taken.
Well, I can’t guarantee that none of them are buggy, unmaintained etc… But that’s why I prefixed that sentence with “I feel”.
On average, it seems to me like the code quality is a good bit higher than I’m able to produce under money/time constraints.
In particular, even the worst libraries tend to be not as bad as they may be in many other languages, because Rust’s strict type system + compiler enforces quite a bit of correctness on its own.
Well, and the good libraries are just obsessed with correctness and performance, so they drag code quality upwards, even if they introduce a mild risk of a transitive dependency being a dud…