7 ms·

Is it me, or does rust suffer badly from important functionality being contributed rather than baked in by design, leading to, e.g., multiple incompatible ways

by psd1 3y ago

Is it me, or does rust suffer badly from important functionality being contributed rather than baked in by design, leading to, e.g., multiple incompatible ways to do async? Or am I spoiled by .net, which has an excellent bcl?

xpe 3y ago
By BCL you mean "Base Class Library"? From where I sit (having worked with many languages in many sectors), BCL isn't an acronym in common circulation.
- coldtea 3y ago
  No, but it's an acronym in common circulation in .NET land.
prmph 3y ago
I though rust was supposed to have a vast standard library?
- gbear605 3y ago
  It has a large standard library compared to something like C or C++, but it’s small compared to a lot of more recent languages. Intentionally so, since they wanted to be able to create smaller binaries.
  - dymk 3y ago
    That doesn’t make sense, you don’t link against the entire rust stdlib, you compile directly against its source. You don’t get more than what you call.
    - steveklabnik 3y ago
      You don’t compile the Rust standard library from source, you link against a pre-built one. There is an unstable option to compile the standard library from source. That said, you’re right that “to keep binary size down” isn’t why the standard library is small. Heck, that you don’t compile from source means sometimes binaries are larger than they have to be, even with LTO! It is largely because anything that’s there has to be supported exactly as is forever, interface wise, and for many things, we did not have the confidence on what the right interface would be. Furthermore, it’s harder to maintain the standard library than it is a package out of tree for a variety of reasons.
      - dymk 3y ago
        Thank you for the correction. My confusion comes from being able to command-click on standard library types and methods, and being taken to their implementation, not just a declaration. I realize these aren't really concepts in Rust the same way they are in e.g. C/C++, but I figured if the source is present, the compiler is smart enough to not be over-compiling unused symbols.
        steveklabnik 3y ago
        Yeah, it's all good. Rustup will also distribute the source: ~> rustup component list | rg src rust-src (installed) But this is so that that workflow works well, not because the compiler actually uses it during the build. > the compiler is smart enough to not be over-compiling unused symbols. This is true even without the source, mind you, but the devil is just in the details. Stuff like the panic and/or formatting machinery is known to creep in even if you don't think you're using it, because some edge case might. This only truly matters for embedded and similar, but it's still a thing.
    - zozbot234 3y ago
      Actually, this is not correct at present. Compiling the stdlib as part of building a project is only supported as a special option in nightly rust.
  - hobofan 3y ago
    Small binaries has nothing to do with the reason for that. Build tools will only include what's needed either way, so e.g. your Hello World program will have parts of std::io and std::fmt, and not really anything beyond that. So you "pay for what you use", regardless of whether it's part of the standard library or an external library. I think in Rust the choice is more one that originally prioritized viability of long-term maintenance of the project by keeping the volume and surface of the standard library small. For all more recent inclusion the inclusion criteria seem to be either "small ecosystem functionality that everybody is using and has proven to be valuable" (e.g. once_cell) or "what is close-to-optimal solution for critical parts of the ecosystem that we have to include to minimize ecosystem splintering" (e.g. the work around std::future). I wouldn't be surprised if there are actual written down criteria for std inclusion somewhere.
    - steveklabnik 3y ago
      > I wouldn't be surprised if there are actual written down criteria for std inclusion somewhere. I’m not aware of the current state, but in the old days, it was roughly: 1. Is this useful in virtually every Rust program? 2. Is this something (data structures, mostly) that requires a lot of unsafe to implement? 3. Is this a vocabulary type? Any of these is a slam dunk, anything else is more subjective.
      - coldtea 3y ago
        >1. Is this useful in virtually every Rust program? That's too strict a criterion for a standard library!
        steveklabnik 3y ago
        Sure, different people can have different opinions. But it’s also not literally true, in the sense that it’s only one of three criteria, but also because it’s more of a conceptual framing than something to be taken exactly. There’s just a high bar of usefulness required. You can tell that this isn’t literally true just by looking at the contents of the standard library.
frizlab 3y ago
Coming from Swift, I think the same. It’s good to have the liberty to be able to do anything, but a good way to do most of the things is primordial too.
maxfurman 3y ago
The Rust team prioritized keeping the standard library small, and allowing important but inessential functionality to live outside the stdlib and keep their own release schedule. MS has massive resources and can align the many many modules of .NET into major releases. The Rust project does not.
- noisy_boy 3y ago
  I wonder if there is a scope for a "opt" / "extras" type level where libraries for stuff super commonly used, like JSON/YAML/ssl etc can be placed. It doesn't have to cover everything the defacto third party libraries do (that will be too much and not practical), just including happy paths should be enough for most people to just include the meta package and get the most generally used features instead of including a ton of third-party libraries. My knowledge about Rust's library system isn't great so there are probably several gaps in my argument.
  - steveklabnik 3y ago
    Several people have tried to create such a thing over the years, but the ecosystem never uses them. People objectively prefer to pick their own set of packages.
- thesuperbigfrog 3y ago
  >> The Rust team prioritized keeping the standard library small, and allowing important but inessential functionality to live outside the stdlib and keep their own release schedule. There are crate "recommendation lists" like this: https://blessed.rs/crates https://blessed.rs/crates While these help, Rust's small standard library has slowed Rust adoption where I work because our IT security team must approve all third-party packages before we can use them. (Who blindly downloads code from the Internet and incorporates it in their software?) This means that unless there is a compelling need to use Rust, most teams will use C# because .NET is approved and has almost everything. I prefer Rust to C#, but we are not using it that widely yet. It's not a fair comparison, but it is how things currently are.
  - 3y ago
pjmlp 3y ago
You're spoiled by .NET, however if you look beyond BCL, we now have: - WinForms, WPF, UWP, WinUI 3.0/WinAppSDK, MAUI - WebForms, MVC Framework style, MVC Core style, Razor Pages, Blazor, Hybrid Blazor (tryig to fit everywhere there is a Webwidget from the previous line) - Latest design decisions being driven by Azure and ASP.NET requirements
- neonsunset 3y ago
  What kind of decisions driven by Azure do you have in mind? What kind of impact does ASP.NET Core (or EF Core for that matter) have on CoreCLR and NativeAOT?
  - pjmlp 3y ago
    The whole .NET 9 roadmap being driven by Aspire (works best on Azure) and Blazor. Stuff like minimal APIs driving C# features, e.g. lambda improvements required for replacing controllers with minimal APIs. There are hardly any desktop or COM improvements that are taken as seriously as the way the ASP.NET is. EF Core works best with Microsoft offerings, SQL Server, CosmoDB,.... The whole aspect oriented framework now in preview to enable AOT for ASP.NET workloads.
    - neonsunset 3y ago
      None of this is a part of .NET itself, rather a part of ecosystem of its libraries, like ASP.NET Core, EF Core, etc. Again: it is not a part of the language or runtime. If you do, however, have links to code changes that prove otherwise - please do post them. Meanwhile, COM interests only a limited part of community, and there also exists actively maintained https://github.com/microsoft/CsWin32 https://github.com/microsoft/CsWin32 A popular (if not the most, depending on location) choice to use EF Core with is PostgreSQL. Meanwhile, ASP.NET Core simply continues to evolve just like other libraries, whether they are a part of dotnet/* or not. GUI continues to get better with development of AvaloniaUI, Uno and MAUI. .NET as a whole is way bigger than some of it's "first-party" solutions that you don't even have to use, that have little impact on language, runtime and compiler themselves aside from "this is a good demonstration where we can improve the general case". There also exists Unity, many companies using completely non-standard stacks on top of the language, etc. But you deliberately choose to ignore this information for unknown reasons. It is genuinely bewildering to see this kind of flawed and strange impression of the ecosystem not rooted in reality. I suppose addressing this involves reading documentation and source material, which perhaps proves too challenging.
mattgreenrocks 3y ago
Yeah. The transitive dependency graph for small projects can hit 100 pretty quickly, which instinctively worries me. Unlike node, however, library quality is pretty good in quality and how they respect SemVer, and static type checking helps as a first line check.
- cmrdporcupine 3y ago
  The library quality is mostly fine -- however crates.io is basically unmoderated and it will get worse and worse overtime as things bitrot and collect dust or the namespace gets abused (already happening). The biggest problem is the exploding transitive dependency graph, including multiple versions of the same basic utilities. Even small projects can suffer from this. It's too easy to reach into the grab-bag at crates.io and pull a little utility out and use it. I've personally built very small things only to find multiple versions or implementations of e.g. sha256 or rand or whatever in my own dep graph, and it gets really hard to prune them out. At work we're fairly diligent about this but still it's exploding. And when you consider the matrix of minimum-supported toolchain versions for different projects, and if you're stuck on an older Rust toolchain, it's even more pain. Rust projects starting from scratch could consider vendoring their dependencies rather than pulling from crates.io. But support for vendored dependency in Cargo is weak/bad. You run into all sorts of nightmares especially when using workspaces. It's heresy and I'll get downvoted for it, but: More and more I lean towards using bazel or gn/ninja for fresh Rust projects, and walk away from cargo & crates entirely. Cargo (+ Crates.io) was delicious to me at first, but it's a meal that tastes worse the more I have of it. EDIT: it strikes me that I didn't say why exploding dependencies bugs me so much. There are logistical reasons for sure (competing APIs, compile fails, binary bloat, etc.) but the primary reason is: exploding complexity. Every additional dependency is now a potential problem for future me/future team.
  - meindnoch 3y ago
    >Cargo (+ Crates.io) was delicious to me at first, but it's a meal that tastes worse the more I have of it. This is the first step of your journey. Next step is realizing the same about the language itself.
dralley 3y ago
This is a feature, not a bug - although the situation could probably still be improved. "multiple incompatible ways to do async" is another way of saying "you can use async on a tiny microcontroller without any OS at all, or in userspace on a 128-core Epyc CPU, or in the Linux kernel" That's a unique feature of Rust compared to any of the languages with a single executor baked into the language like C# or Javascript. It does however come with costs, and one of those costs is that people who just want to write a web app are exposed to details they would much rather not have to see.
- neonsunset 3y ago
  Technically speaking C# allows custom scheduler implementations, and internally ThreadPool is an abstraction too - e.g. AOT will use kernel-provided threadpool on Windows for size savings by default. Practically speaking, however, you are right.
JonChesterfield 3y ago
For the opposing view, "the standard library is where code goes to die".
- gedjurdcv 3y ago
  .NET really is something special. I guess that’s what billions of dollars buys you? But even still the saying is true about many other standard libraries.
  - hu3 3y ago
    Same for Go standard library. It is excellent and curated by "billions of dollars".
  - neonsunset 3y ago
    If only you knew comp level for DevDiv in EU or occasional layoffs ;( There is no magic trick, just people (both hired and community contributors) who invest their experience, skill and ambition to make great technology.
- thesuperbigfrog 3y ago
  >> "the standard library is where code goes to die" I disagree. It's more like the code has ascended (https://nethackwiki.com/wiki/Ascension https://nethackwiki.com/wiki/Ascension). It has won because it is useful enough and mature enough to accompany the language and serve everywhere. Depending on what it does, standard library code may be used everywhere. For example, would you say that the Rust's Vec (https://doc.rust-lang.org/std/vec/struct.Vec.html https://doc.rust-lang.org/std/vec/struct.Vec.html) is "dead"? It can still get new features added. It will still get bug fixes. But its primary APIs are engraved in stone, never to change because it would break all the code that depends on it. Granted, some code that goes into standard libraries will eventually fall out of use, or will be replaced by something better. In such cases, the code should be marked deprecated and eventually removed in a future edition of the language. In that case, it is like the code retires or could even be forked into a community-supported library in case it does still need to be used.

by psd1 3y ago

xpe 3y ago

By BCL you mean "Base Class Library"? From where I sit (having worked with many languages in many sectors), BCL isn't an acronym in common circulation.

coldtea 3y ago
No, but it's an acronym in common circulation in .NET land.

prmph 3y ago

I though rust was supposed to have a vast standard library?

gbear605 3y ago
It has a large standard library compared to something like C or C++, but it’s small compared to a lot of more recent languages. Intentionally so, since they wanted to be able to create smaller binaries.
- dymk 3y ago
  That doesn’t make sense, you don’t link against the entire rust stdlib, you compile directly against its source. You don’t get more than what you call.
  - steveklabnik 3y ago
    You don’t compile the Rust standard library from source, you link against a pre-built one. There is an unstable option to compile the standard library from source. That said, you’re right that “to keep binary size down” isn’t why the standard library is small. Heck, that you don’t compile from source means sometimes binaries are larger than they have to be, even with LTO! It is largely because anything that’s there has to be supported exactly as is forever, interface wise, and for many things, we did not have the confidence on what the right interface would be. Furthermore, it’s harder to maintain the standard library than it is a package out of tree for a variety of reasons.
    - dymk 3y ago
      Thank you for the correction. My confusion comes from being able to command-click on standard library types and methods, and being taken to their implementation, not just a declaration. I realize these aren't really concepts in Rust the same way they are in e.g. C/C++, but I figured if the source is present, the compiler is smart enough to not be over-compiling unused symbols.
      - steveklabnik 3y ago
        Yeah, it's all good. Rustup will also distribute the source: ~> rustup component list | rg src rust-src (installed) But this is so that that workflow works well, not because the compiler actually uses it during the build. > the compiler is smart enough to not be over-compiling unused symbols. This is true even without the source, mind you, but the devil is just in the details. Stuff like the panic and/or formatting machinery is known to creep in even if you don't think you're using it, because some edge case might. This only truly matters for embedded and similar, but it's still a thing.
  - zozbot234 3y ago
    Actually, this is not correct at present. Compiling the stdlib as part of building a project is only supported as a special option in nightly rust.
- hobofan 3y ago
  Small binaries has nothing to do with the reason for that. Build tools will only include what's needed either way, so e.g. your Hello World program will have parts of std::io and std::fmt, and not really anything beyond that. So you "pay for what you use", regardless of whether it's part of the standard library or an external library. I think in Rust the choice is more one that originally prioritized viability of long-term maintenance of the project by keeping the volume and surface of the standard library small. For all more recent inclusion the inclusion criteria seem to be either "small ecosystem functionality that everybody is using and has proven to be valuable" (e.g. once_cell) or "what is close-to-optimal solution for critical parts of the ecosystem that we have to include to minimize ecosystem splintering" (e.g. the work around std::future). I wouldn't be surprised if there are actual written down criteria for std inclusion somewhere.
  - steveklabnik 3y ago
    > I wouldn't be surprised if there are actual written down criteria for std inclusion somewhere. I’m not aware of the current state, but in the old days, it was roughly: 1. Is this useful in virtually every Rust program? 2. Is this something (data structures, mostly) that requires a lot of unsafe to implement? 3. Is this a vocabulary type? Any of these is a slam dunk, anything else is more subjective.
    - coldtea 3y ago
      >1. Is this useful in virtually every Rust program? That's too strict a criterion for a standard library!
      - steveklabnik 3y ago
        Sure, different people can have different opinions. But it’s also not literally true, in the sense that it’s only one of three criteria, but also because it’s more of a conceptual framing than something to be taken exactly. There’s just a high bar of usefulness required. You can tell that this isn’t literally true just by looking at the contents of the standard library.

frizlab 3y ago

Coming from Swift, I think the same. It’s good to have the liberty to be able to do anything, but a good way to do most of the things is primordial too.

maxfurman 3y ago

The Rust team prioritized keeping the standard library small, and allowing important but inessential functionality to live outside the stdlib and keep their own release schedule. MS has massive resources and can align the many many modules of .NET into major releases. The Rust project does not.

noisy_boy 3y ago
I wonder if there is a scope for a "opt" / "extras" type level where libraries for stuff super commonly used, like JSON/YAML/ssl etc can be placed. It doesn't have to cover everything the defacto third party libraries do (that will be too much and not practical), just including happy paths should be enough for most people to just include the meta package and get the most generally used features instead of including a ton of third-party libraries. My knowledge about Rust's library system isn't great so there are probably several gaps in my argument.
- steveklabnik 3y ago
  Several people have tried to create such a thing over the years, but the ecosystem never uses them. People objectively prefer to pick their own set of packages.
thesuperbigfrog 3y ago
>> The Rust team prioritized keeping the standard library small, and allowing important but inessential functionality to live outside the stdlib and keep their own release schedule. There are crate "recommendation lists" like this: https://blessed.rs/crates https://blessed.rs/crates While these help, Rust's small standard library has slowed Rust adoption where I work because our IT security team must approve all third-party packages before we can use them. (Who blindly downloads code from the Internet and incorporates it in their software?) This means that unless there is a compelling need to use Rust, most teams will use C# because .NET is approved and has almost everything. I prefer Rust to C#, but we are not using it that widely yet. It's not a fair comparison, but it is how things currently are.
- 3y ago

pjmlp 3y ago

You're spoiled by .NET, however if you look beyond BCL, we now have: - WinForms, WPF, UWP, WinUI 3.0/WinAppSDK, MAUI - WebForms, MVC Framework style, MVC Core style, Razor Pages, Blazor, Hybrid Blazor (tryig to fit everywhere there is a Webwidget from the previous line) - Latest design decisions being driven by Azure and ASP.NET requirements

neonsunset 3y ago
What kind of decisions driven by Azure do you have in mind? What kind of impact does ASP.NET Core (or EF Core for that matter) have on CoreCLR and NativeAOT?
- pjmlp 3y ago
  The whole .NET 9 roadmap being driven by Aspire (works best on Azure) and Blazor. Stuff like minimal APIs driving C# features, e.g. lambda improvements required for replacing controllers with minimal APIs. There are hardly any desktop or COM improvements that are taken as seriously as the way the ASP.NET is. EF Core works best with Microsoft offerings, SQL Server, CosmoDB,.... The whole aspect oriented framework now in preview to enable AOT for ASP.NET workloads.
  - neonsunset 3y ago
    None of this is a part of .NET itself, rather a part of ecosystem of its libraries, like ASP.NET Core, EF Core, etc. Again: it is not a part of the language or runtime. If you do, however, have links to code changes that prove otherwise - please do post them. Meanwhile, COM interests only a limited part of community, and there also exists actively maintained https://github.com/microsoft/CsWin32 https://github.com/microsoft/CsWin32 A popular (if not the most, depending on location) choice to use EF Core with is PostgreSQL. Meanwhile, ASP.NET Core simply continues to evolve just like other libraries, whether they are a part of dotnet/* or not. GUI continues to get better with development of AvaloniaUI, Uno and MAUI. .NET as a whole is way bigger than some of it's "first-party" solutions that you don't even have to use, that have little impact on language, runtime and compiler themselves aside from "this is a good demonstration where we can improve the general case". There also exists Unity, many companies using completely non-standard stacks on top of the language, etc. But you deliberately choose to ignore this information for unknown reasons. It is genuinely bewildering to see this kind of flawed and strange impression of the ecosystem not rooted in reality. I suppose addressing this involves reading documentation and source material, which perhaps proves too challenging.

mattgreenrocks 3y ago

Yeah. The transitive dependency graph for small projects can hit 100 pretty quickly, which instinctively worries me. Unlike node, however, library quality is pretty good in quality and how they respect SemVer, and static type checking helps as a first line check.

cmrdporcupine 3y ago
The library quality is mostly fine -- however crates.io is basically unmoderated and it will get worse and worse overtime as things bitrot and collect dust or the namespace gets abused (already happening). The biggest problem is the exploding transitive dependency graph, including multiple versions of the same basic utilities. Even small projects can suffer from this. It's too easy to reach into the grab-bag at crates.io and pull a little utility out and use it. I've personally built very small things only to find multiple versions or implementations of e.g. sha256 or rand or whatever in my own dep graph, and it gets really hard to prune them out. At work we're fairly diligent about this but still it's exploding. And when you consider the matrix of minimum-supported toolchain versions for different projects, and if you're stuck on an older Rust toolchain, it's even more pain. Rust projects starting from scratch could consider vendoring their dependencies rather than pulling from crates.io. But support for vendored dependency in Cargo is weak/bad. You run into all sorts of nightmares especially when using workspaces. It's heresy and I'll get downvoted for it, but: More and more I lean towards using bazel or gn/ninja for fresh Rust projects, and walk away from cargo & crates entirely. Cargo (+ Crates.io) was delicious to me at first, but it's a meal that tastes worse the more I have of it. EDIT: it strikes me that I didn't say why exploding dependencies bugs me so much. There are logistical reasons for sure (competing APIs, compile fails, binary bloat, etc.) but the primary reason is: exploding complexity. Every additional dependency is now a potential problem for future me/future team.
- meindnoch 3y ago
  >Cargo (+ Crates.io) was delicious to me at first, but it's a meal that tastes worse the more I have of it. This is the first step of your journey. Next step is realizing the same about the language itself.

dralley 3y ago

This is a feature, not a bug - although the situation could probably still be improved. "multiple incompatible ways to do async" is another way of saying "you can use async on a tiny microcontroller without any OS at all, or in userspace on a 128-core Epyc CPU, or in the Linux kernel" That's a unique feature of Rust compared to any of the languages with a single executor baked into the language like C# or Javascript. It does however come with costs, and one of those costs is that people who just want to write a web app are exposed to details they would much rather not have to see.

neonsunset 3y ago
Technically speaking C# allows custom scheduler implementations, and internally ThreadPool is an abstraction too - e.g. AOT will use kernel-provided threadpool on Windows for size savings by default. Practically speaking, however, you are right.

JonChesterfield 3y ago

For the opposing view, "the standard library is where code goes to die".

gedjurdcv 3y ago
.NET really is something special. I guess that’s what billions of dollars buys you? But even still the saying is true about many other standard libraries.
- hu3 3y ago
  Same for Go standard library. It is excellent and curated by "billions of dollars".
- neonsunset 3y ago
  If only you knew comp level for DevDiv in EU or occasional layoffs ;( There is no magic trick, just people (both hired and community contributors) who invest their experience, skill and ambition to make great technology.
thesuperbigfrog 3y ago
>> "the standard library is where code goes to die" I disagree. It's more like the code has ascended (https://nethackwiki.com/wiki/Ascension https://nethackwiki.com/wiki/Ascension). It has won because it is useful enough and mature enough to accompany the language and serve everywhere. Depending on what it does, standard library code may be used everywhere. For example, would you say that the Rust's Vec (https://doc.rust-lang.org/std/vec/struct.Vec.html https://doc.rust-lang.org/std/vec/struct.Vec.html) is "dead"? It can still get new features added. It will still get bug fixes. But its primary APIs are engraved in stone, never to change because it would break all the code that depends on it. Granted, some code that goes into standard libraries will eventually fall out of use, or will be replaced by something better. In such cases, the code should be marked deprecated and eventually removed in a future edition of the language. In that case, it is like the code retires or could even be forked into a community-supported library in case it does still need to be used.