4 ms·

Great post and I really like the focus on sticking to the core mission: make things safe and do so without compromising on critical features like async. I see

Great post and I really like the focus on sticking to the core mission: make things safe and do so without compromising on critical features like async. I see the complaints about things like stdlib and I don’t get it - the core team is doing an excellent job of keeping rust doing what it should do best, and the crate system and community fills that gap. If you want a big stdlib then use Python.

thesuperbigfrog 4y ago
It is a delicate balance--having a smaller high quality standard library versus the "everything you could possibly need", "kitchen sink" approach found in the Python standard library. It is great that there is an active Rust community with tons of useful crates, but it can be daunting as a newcomer or when introducing Rust into an organization to discover and adopt the "right" crate(s) for common tasks that the standard library has no answer for. An example common task is asynchronous programming. For my current project, I am better off using thread::spawn, async / await, async-std, tokio, smol-rs, or something else? I had tentatively selected async-std, but then I came across this thread: https://github.com/async-rs/async-std/issues/992#issuecomment-1035223559 https://github.com/async-rs/async-std/issues/992#issuecommen... If I select a given crate today for a given common task, will the crate still be around and maintained in three years? Will I need to rewrite my project to use the latest crate du jour? I wonder if it would be possible for the Rust community to design / define a common library of traits for common tasks that could be used as "interfaces" (sorry, Java background) that library crates could be implemented against. This would provide better stability for crate users and help to avoid analysis paralysis and uncertainty when selecting crates for common tasks that the standard library has no answers for. There could even be multiple libraries of traits grouped by the type of task. This would allow for more natural groupings based on usage (instead of one huge library of traits) and permit independent changes from other defined libraries of traits. The Ada programming language has a similar idea called "Standard Library Annexes". See the bottom half of http://www.ada-auth.org/standards/22rm/html/RM-TOC.html http://www.ada-auth.org/standards/22rm/html/RM-TOC.html where the sections start with alphabet letters instead of numbers. There are standard annexes for: "B. Interface to Other Languages", "C. Systems Programming", "D. Real-Time Systems", "E. Distributed Systems", "F. Information Systems", "G. Numerics", and "H. High-Integrity Systems". Ada toolchains do not have to implement all of these annexes to be a standards-compliant Ada toolchain, but it gives those that do a standard interface so that they are more interchangeable, and code written against them does not have to be rewritten. Rust is wonderful and I want to see it improve. Is an idea like this feasible? If not, why not?
- tialaramex 4y ago
  I think the big problem is that any such thing you'd design an interface for might change in such a way that it doesn't make any sense to preserve this hypothetical interface over time. Rust's standard library promises to keep maintaining all the pieces long after they're obsolete, and the bigger it gets the harder that will be. In 1983 if I design a Video interface I guess we need PAL vs NTSC to handle colour standards, and also we need Interlacing, that's a thing. Should we have a fixed list of resolutions? Nah, let's splash out, user defined, that's future proof. Oops, here we are in 2023 and while nobody cares about Interlacing, and the arbitrary user defined resolutions allow me to express 4K display, there's nowhere to pick 120fps, or to specify 12-bit colour.
  - thesuperbigfrog 4y ago
    >> I think the big problem is that any such thing you'd design an interface for might change in such a way that it doesn't make any sense to preserve this hypothetical interface over time. Rust's standard library promises to keep maintaining all the pieces long after they're obsolete, and the bigger it gets the harder that will be. True. However, without more standardized components the Rust ecosystem could end up like the Common Lisp library problem: lots of libraries in various states of maturity and maintenance with no obvious choice of what to use to solve your problem. Big standard libraries help to drive corporate and enterprise adoption. It is part of the reason why Java and Python are so widely used in corporate / enterprise environments. It brings a lot of standardized functionality and longer-term support that those kinds of environments want. We rely on the Rust standard library because it will be maintained for a very long time and has mostly stable APIs. Without a bigger standard library or some other kind of standardization, we would build our own libraries that might re-invent the wheel, but at least we know that our libraries will be maintained.
  - pjmlp 4y ago
    On the other hand, developers, including the Rust team appreciate the 1970's UNIX model to be available in 2023. Originally all the UNIX libc that didn't land in ANSI/ISO C89 and became POSIX instead.

thesuperbigfrog 4y ago

It is a delicate balance--having a smaller high quality standard library versus the "everything you could possibly need", "kitchen sink" approach found in the Python standard library. It is great that there is an active Rust community with tons of useful crates, but it can be daunting as a newcomer or when introducing Rust into an organization to discover and adopt the "right" crate(s) for common tasks that the standard library has no answer for. An example common task is asynchronous programming. For my current project, I am better off using thread::spawn, async / await, async-std, tokio, smol-rs, or something else? I had tentatively selected async-std, but then I came across this thread: https://github.com/async-rs/async-std/issues/992#issuecomment-1035223559 https://github.com/async-rs/async-std/issues/992#issuecommen... If I select a given crate today for a given common task, will the crate still be around and maintained in three years? Will I need to rewrite my project to use the latest crate du jour? I wonder if it would be possible for the Rust community to design / define a common library of traits for common tasks that could be used as "interfaces" (sorry, Java background) that library crates could be implemented against. This would provide better stability for crate users and help to avoid analysis paralysis and uncertainty when selecting crates for common tasks that the standard library has no answers for. There could even be multiple libraries of traits grouped by the type of task. This would allow for more natural groupings based on usage (instead of one huge library of traits) and permit independent changes from other defined libraries of traits. The Ada programming language has a similar idea called "Standard Library Annexes". See the bottom half of http://www.ada-auth.org/standards/22rm/html/RM-TOC.html http://www.ada-auth.org/standards/22rm/html/RM-TOC.html where the sections start with alphabet letters instead of numbers. There are standard annexes for: "B. Interface to Other Languages", "C. Systems Programming", "D. Real-Time Systems", "E. Distributed Systems", "F. Information Systems", "G. Numerics", and "H. High-Integrity Systems". Ada toolchains do not have to implement all of these annexes to be a standards-compliant Ada toolchain, but it gives those that do a standard interface so that they are more interchangeable, and code written against them does not have to be rewritten. Rust is wonderful and I want to see it improve. Is an idea like this feasible? If not, why not?

tialaramex 4y ago
I think the big problem is that any such thing you'd design an interface for might change in such a way that it doesn't make any sense to preserve this hypothetical interface over time. Rust's standard library promises to keep maintaining all the pieces long after they're obsolete, and the bigger it gets the harder that will be. In 1983 if I design a Video interface I guess we need PAL vs NTSC to handle colour standards, and also we need Interlacing, that's a thing. Should we have a fixed list of resolutions? Nah, let's splash out, user defined, that's future proof. Oops, here we are in 2023 and while nobody cares about Interlacing, and the arbitrary user defined resolutions allow me to express 4K display, there's nowhere to pick 120fps, or to specify 12-bit colour.
- thesuperbigfrog 4y ago
  >> I think the big problem is that any such thing you'd design an interface for might change in such a way that it doesn't make any sense to preserve this hypothetical interface over time. Rust's standard library promises to keep maintaining all the pieces long after they're obsolete, and the bigger it gets the harder that will be. True. However, without more standardized components the Rust ecosystem could end up like the Common Lisp library problem: lots of libraries in various states of maturity and maintenance with no obvious choice of what to use to solve your problem. Big standard libraries help to drive corporate and enterprise adoption. It is part of the reason why Java and Python are so widely used in corporate / enterprise environments. It brings a lot of standardized functionality and longer-term support that those kinds of environments want. We rely on the Rust standard library because it will be maintained for a very long time and has mostly stable APIs. Without a bigger standard library or some other kind of standardization, we would build our own libraries that might re-invent the wheel, but at least we know that our libraries will be maintained.
- pjmlp 4y ago
  On the other hand, developers, including the Rust team appreciate the 1970's UNIX model to be available in 2023. Originally all the UNIX libc that didn't land in ANSI/ISO C89 and became POSIX instead.