5 ms·

At first, I was a little put off by how "batteries not included" the standard library was in rust, but I ended up preferring it. The quality of the rust communi

by matxip 4y ago

At first, I was a little put off by how "batteries not included" the standard library was in rust, but I ended up preferring it. The quality of the rust community has generally made library selection pretty easy. There's usually a tacit first choice and often one or more optimized alternative for a particular situation or preference. When there is community disagreement and library churn, I think it ends up evolving better, more liked solutions; I truly believe this wouldn't happen as easily if it was enshrined in the std. Case and point, I've seen standard library implementations in C++ and python that just rot away. The case sensitive visibility/privacy sound terrible to me. I dislike having to type pub as much as I do, but that seems worse for readability and clarity on top of throwing a wrench into the established rustfmt naming system. About "Memory management", they already made some progress with non-lexical lifetimes in the past which did indeed improve the end user experience. I think "Polonius" aims to reduce the friction further, but I haven't looked into the specific improvements it might bring in user experience.

oxff 4y ago
I think it has plenty enough of batteries for building things that can be used to build things. Very good abstractions for the most part, with mostly good implementations (ie. cases like parking_lot mutex show where it fails, and the `async` stuff is bit sketch). Don't understand and don't support initiatives that want to stuff it full of actual applications and stuff (like http server, async runtime) etc. Just use I don't know, something else at that point.
tayo42 4y ago
> When there is community disagreement and library churn, I think it ends up evolving better, more liked solutions; That's an optimistic way of thinking about. I feel hesitant to pull in libraries because you don't know when or why the community is going decide to change. Then your that fool using that old code, stuck with sudden tech debt. It also makes stuff like stackoverflow weird to use where you get different answers depending on the year. I think the biggest problem is with libraries that try to make things more ergnomic. Learning about pin and how to use it is weird, everyone keeps recommending some higher level library.
- lostdog 4y ago
  Unfortunately a standard library doesn't really reduce churn. It just means to you chunks of the standard library being deprecated, which can be confusing. For example, what's the common way to download a file from the web in Python? Instead, I think every language should have a list of batteries-suggested libraries, with a roughly 2 year turnover period. This way you get a community suggested group of the common functionality needed to be productive. It won't change so frequently that you're constantly looking up function names, but it also won't get sclerotic, and can move from old grungy libraries to new libraries when necessary. Of course, you can always just stick with an old "edition" of the community libs if you've got a legacy app that you don't want to migrate.
guitarbill 4y ago
The author mentions "Serialization / Deserialization: JSON" as something the standard library needs. Would Rust have gotten `serde` in this case? I guess we'll never know, but serde is seriously impressive on many levels.
- TheDong 4y ago
  Go included json in the standard library, so it can't ever change it. It's wildly inefficient (mostly due to reflection), not type safe, and somewhat surprising. Guess the output https://go.dev/play/p/lSyiaN3IYOR https://go.dev/play/p/lSyiaN3IYOR The author also mentioned "Images manipulation" as a thing that should exist in the standard library. We actually know how that one went from go too: There's the stdlib image/draw (https://pkg.go.dev/image/draw https://pkg.go.dev/image/draw). But generally, it's recommended to use the non-stdlib golang.org/x/image/draw package instead these days (https://pkg.go.dev/golang.org/x/image/draw https://pkg.go.dev/golang.org/x/image/draw) For backwards compatibility reasons, the stdlib couldn't change, and it's actually far more confusing as a result. I take a much different lesson than the author of this post about what lessons to take from Go's "large stdlib" experiment.
  - KronisLV 4y ago
    > I take a much different lesson than the author of this post about what lessons to take from Go's "large stdlib" experiment. Personally, i think that this is simply a problem of not being able to throw the entire thing away, learn from the mistakes and make a better iteration. I'm all for "batteries included" anything - be it a standard library for a programming language, an IDE with its own component libraries like Lazarus, a web development framework like Angular that's less fragmented than React or maybe even an operating system that has a lot of the software that you'll want to use preinstalled (or available on a DVD or a similar medium directly). It's just that making sure that those batteries are good is impossible without iteration. Having to do backwards compatibility essentially makes that sort of iteration impossible. So what's the solution here? Have a clearly defined end of life for the current version and a new major version in the future. Python 2 might have had a lot of warts, but Python 3 would clearly be better! One could say the same for Python 4, Python 5 and so on. The same goes for Go, Rust and any other high level language - just look at Java 8 and the newer iterations. You just need to learn to throw old things away instead of keeping them around in some half-alive state. I say that as someone who's currently maintaining a Java 8 monolith that cannot be updated to anything more recent. If your software gets so large to the point where it cannot be migrated/rewritten in a manageable way, you've made a mistake. If you cannot feasibly migrate it over, then consider whether you even need it in the first place (e.g. build systems that you do less). There are sub-optimal cases where that simply isn't possible: the Linux kernel comes to mind, as does a lot of other large legacy software that's slowly trudging along on the backs of tens of thousands of developer years. But somehow you don't see many new/existing systems using FORTRAN or COBOL and that's all for the better.
carlmr 4y ago
>At first, I was a little put off by how "batteries not included" the standard library was in rust, but I ended up preferring it. The quality of the rust community has generally made library selection pretty easy. I still think it would be good to have a rust installer where you get a set of "almost standard" libraries pre-installed. So that in companies where you have to get everything approved, you could get this package approved.
LeFantome 4y ago
There is no right answer. Too much core functionality defined by the community can be confusing and lead to mixed quality. As a newbie, how do I even know what the “rust SDK” even looks like and what parts are better than others. A large official language SDK has its own downsides too though. For my money, the .NET base class library is the best “batteries included” platform out there. It has certainly had its mis-steps over the years though. How many projects that went all-in on the original ASP.NET ( now called Webforms ) are now totally stranded on a technology island that the broad .NET community is racing away from? How about the graveyard of UI frameworks for .NET? WCF? Using the “official” solutions did not help guarantee any longevity for these technologies ( though they are mostly still “supported” ). It is hard really to say that one approach is superior. The Rust tool chain at least makes the distributes solution easier. For some stuff at least. The lack of a baked in library might make things like use in the Linux kernel harder in some ways.

by matxip 4y ago

oxff 4y ago

I think it has plenty enough of batteries for building things that can be used to build things. Very good abstractions for the most part, with mostly good implementations (ie. cases like parking_lot mutex show where it fails, and the `async` stuff is bit sketch). Don't understand and don't support initiatives that want to stuff it full of actual applications and stuff (like http server, async runtime) etc. Just use I don't know, something else at that point.

tayo42 4y ago

> When there is community disagreement and library churn, I think it ends up evolving better, more liked solutions; That's an optimistic way of thinking about. I feel hesitant to pull in libraries because you don't know when or why the community is going decide to change. Then your that fool using that old code, stuck with sudden tech debt. It also makes stuff like stackoverflow weird to use where you get different answers depending on the year. I think the biggest problem is with libraries that try to make things more ergnomic. Learning about pin and how to use it is weird, everyone keeps recommending some higher level library.

lostdog 4y ago
Unfortunately a standard library doesn't really reduce churn. It just means to you chunks of the standard library being deprecated, which can be confusing. For example, what's the common way to download a file from the web in Python? Instead, I think every language should have a list of batteries-suggested libraries, with a roughly 2 year turnover period. This way you get a community suggested group of the common functionality needed to be productive. It won't change so frequently that you're constantly looking up function names, but it also won't get sclerotic, and can move from old grungy libraries to new libraries when necessary. Of course, you can always just stick with an old "edition" of the community libs if you've got a legacy app that you don't want to migrate.

guitarbill 4y ago

The author mentions "Serialization / Deserialization: JSON" as something the standard library needs. Would Rust have gotten `serde` in this case? I guess we'll never know, but serde is seriously impressive on many levels.

TheDong 4y ago
Go included json in the standard library, so it can't ever change it. It's wildly inefficient (mostly due to reflection), not type safe, and somewhat surprising. Guess the output https://go.dev/play/p/lSyiaN3IYOR https://go.dev/play/p/lSyiaN3IYOR The author also mentioned "Images manipulation" as a thing that should exist in the standard library. We actually know how that one went from go too: There's the stdlib image/draw (https://pkg.go.dev/image/draw https://pkg.go.dev/image/draw). But generally, it's recommended to use the non-stdlib golang.org/x/image/draw package instead these days (https://pkg.go.dev/golang.org/x/image/draw https://pkg.go.dev/golang.org/x/image/draw) For backwards compatibility reasons, the stdlib couldn't change, and it's actually far more confusing as a result. I take a much different lesson than the author of this post about what lessons to take from Go's "large stdlib" experiment.
- KronisLV 4y ago
  > I take a much different lesson than the author of this post about what lessons to take from Go's "large stdlib" experiment. Personally, i think that this is simply a problem of not being able to throw the entire thing away, learn from the mistakes and make a better iteration. I'm all for "batteries included" anything - be it a standard library for a programming language, an IDE with its own component libraries like Lazarus, a web development framework like Angular that's less fragmented than React or maybe even an operating system that has a lot of the software that you'll want to use preinstalled (or available on a DVD or a similar medium directly). It's just that making sure that those batteries are good is impossible without iteration. Having to do backwards compatibility essentially makes that sort of iteration impossible. So what's the solution here? Have a clearly defined end of life for the current version and a new major version in the future. Python 2 might have had a lot of warts, but Python 3 would clearly be better! One could say the same for Python 4, Python 5 and so on. The same goes for Go, Rust and any other high level language - just look at Java 8 and the newer iterations. You just need to learn to throw old things away instead of keeping them around in some half-alive state. I say that as someone who's currently maintaining a Java 8 monolith that cannot be updated to anything more recent. If your software gets so large to the point where it cannot be migrated/rewritten in a manageable way, you've made a mistake. If you cannot feasibly migrate it over, then consider whether you even need it in the first place (e.g. build systems that you do less). There are sub-optimal cases where that simply isn't possible: the Linux kernel comes to mind, as does a lot of other large legacy software that's slowly trudging along on the backs of tens of thousands of developer years. But somehow you don't see many new/existing systems using FORTRAN or COBOL and that's all for the better.

carlmr 4y ago

>At first, I was a little put off by how "batteries not included" the standard library was in rust, but I ended up preferring it. The quality of the rust community has generally made library selection pretty easy. I still think it would be good to have a rust installer where you get a set of "almost standard" libraries pre-installed. So that in companies where you have to get everything approved, you could get this package approved.

LeFantome 4y ago

There is no right answer. Too much core functionality defined by the community can be confusing and lead to mixed quality. As a newbie, how do I even know what the “rust SDK” even looks like and what parts are better than others. A large official language SDK has its own downsides too though. For my money, the .NET base class library is the best “batteries included” platform out there. It has certainly had its mis-steps over the years though. How many projects that went all-in on the original ASP.NET ( now called Webforms ) are now totally stranded on a technology island that the broad .NET community is racing away from? How about the graveyard of UI frameworks for .NET? WCF? Using the “official” solutions did not help guarantee any longevity for these technologies ( though they are mostly still “supported” ). It is hard really to say that one approach is superior. The Rust tool chain at least makes the distributes solution easier. For some stuff at least. The lack of a baked in library might make things like use in the Linux kernel harder in some ways.