Rfcs Alternatives

rfcs reviews and mentions

• What's the Benefit/Allure of Async/Await vs. CSP/Green Threads (and Other Concurrency Models)?
  5 projects | /r/rust | 9 Dec 2023
• On inheritance and why it's good Rust doesn't have it
  4 projects | /r/rust | 8 Dec 2023

  There's also an open issue: https://github.com/rust-lang/rfcs/issues/349

• Hey Rustaceans! Got a question? Ask here (49/2023)!
  6 projects | /r/rust | 5 Dec 2023

  The only ways to convert float to int right now are using "as", or the unsafe "to_int_unchecked" methods defined for the floating point types. There's an open feature request for "to_int_checked" methods, but it looks like it was posted and only had a couple days of comments without any agreement on what the final semantics would look like: https://github.com/rust-lang/rfcs/issues/3304

• Was Rust Worth It?
  18 projects | news.ycombinator.com | 25 Oct 2023

  > It also looks like (soon) you’ll finally be able to configure global lints for a project. Until now, you had to hack your solution to keep lints consistent for projects. In Wick, we use a script to automatically update inline lint configurations for a few dozen crates. It took years for the Rust community to land on a solution for this, which brings us to…

  Wow, as the author of that feature, I'm surprised to see someone was so passionate about it. I've found that many times I've been having to tell people why they should care about it.

  > I don’t know why. Maybe the pressure to maintain stable APIs, along with Rust’s granular type system, makes it difficult for library owners to iterate. It’s hard to accept a minor change if it would result in a major version bump.

  There is a tension between people wanting features and people not wanting to deal with version bumps. I've seen this a lot in maintaining clap, especially when it went from unmaintained for years to having active releases.

  As for cargo, the compatibility guarantees are tough. Take the lints table. We can't throw in a first try, knowing we can fix in in a cargo 2.0. We are tied into the rust project itself which means we have the same compatibility guarantees. This is one reason we generally encourage trying ideas out in third-party plugins before we integrate them in directly since they can break compatibility.

  > You can’t even publish a crate that has local dev dependencies

  You can; cargo automatically strips them. However, if you tell cargo that there is a version of it in the registry (by setting the version), then it must be published. This is why when I redesigned `cargo add` for being merged into cargo, I made it so `cargo add --path ../foo --dev` will not add the `version` field. We do need to find ways to clarify that the purpose of the version field is for looking it up in the registry.

  Allowing the dev dependencies to be stripped also helps with issues of circular dev-dependencies.

  > However, many developers break large projects down into smaller modules naturally, and you can’t publish a parent crate that has sub-crates that only exist within itself.

  We do have an RFC for this: https://github.com/rust-lang/rfcs/pull/3452

  The most complex part is the Index, figuring out how to represent it in the metadata tables we maintain so we avoid having to download every `.crate` file.

  I also worry there might be tech debt around assumptions of there being a single version of a package when nested packages will easily break that.

  > You can see the problem manifest in the sheer number of utility crates designed to simplify publishing workspaces. Each works with a subset of configurations, and the “one true way” of setting workspaces up still eludes me. When I publish Wick, it’s frequently an hour+ of effort combining manual, repetitive tasks with tools that only partially work.

  I'm a bit confused on this point. While there are things to improve around publishing workspaces, I'm not sure how this relates to setting workspaces up or what problems they've had with that. I'd also be curious what problems they had with releasing packages. I don't think I've seen issues from them in cargo-release's Issues.

• Making Rust supply chain attacks harder with Cackle
  3 projects | news.ycombinator.com | 13 Oct 2023

  This is a really overwrought alternative to just breaking up `std` and listing which new libraries one wants in the regular [depenencies] section.

  https://github.com/rust-lang/rfcs/pull/1133 Yeah definitely I haven't been wanting this for years...

• Divan: Fast and Simple Benchmarking for Rust
  4 projects | news.ycombinator.com | 4 Oct 2023

  https://github.com/rust-lang/rfcs/issues/816 redirected to https://github.com/rust-lang/rfcs/pull/2318

  https://github.com/rust-lang/rfcs/pull/2318 says merged but links to tracking issue https://github.com/rust-lang/rust/issues/50297 which was closed out without ever being implemented.

  So 5 years with no progress & a restarted effort. Don't get me wrong. I appreciate all the people devoting energy to this & other issues, & it's certainly easy to provide criticism from the sidelines, especially since actually solving the problem I'm sure can be hard & I'm not putting my cycles toward this. All I'm trying to communicate is that I'm personally not going to get my hopes up but I really wish the team luck and hope progress can be made here finally!

  4 projects | news.ycombinator.com | 4 Oct 2023

  The recently-formed testing subteam is looking to solve your exact complaint: https://github.com/rust-lang/rfcs/pull/3455

• AdaCore Announces Gnat Pro for Rust
  2 projects | news.ycombinator.com | 30 Sep 2023
• Async Rust Is A Bad Language
  11 projects | news.ycombinator.com | 8 Sep 2023

  See for example https://github.com/rust-lang/rust/issues/63818 and https://github.com/rust-lang/rfcs/pull/3467

  Basically the problem is that async blocks/fns/generators need to create a struct that holds all the local variables within them at any suspension/await/yield point. But local variables can contain references to other local variables, so there are parts of this struct that reference other parts of this struct. This creates two problems:

  - once you create such self-references you can no longer move this struct. But moving a struct is safe, so you need some unsafe code that "promises" you this won't happen. `Pin` is a witness of such promise.

  - in the memory model having an `&mut` reference to this struct means that it is the only way to access it. But this is no longer true for self referential structs, since there are other ways to access its contents, namely the fields corresponding to those local variables that reference other local variables. This is the problem that's still open.

• Storing Data in Control Flow
  4 projects | news.ycombinator.com | 11 Jul 2023

  What's really unfortunate is that compilers already perform this "control flow -> state machine" transformation, but almost none of them expose it to the user for direct manipulation - instead, they tightly couple it to a bunch of unrelated abstractions like event loop runtimes, async executors, managed stacks, etc. I'd kill for a compiler that can properly:

  * Parse a coroutine that produces and consumes values

  * Perform all the normal function-level optimizations to minimize frame space (stack slot reuse via liveness analysis of local variables, re-computing temporaries across yield points, etc.)

  * Expose that coroutine as a fixed-size struct that I can explicitly resume and query

  Zig is almost there, but suspend/resume cannot return values/take arguments, which requires some unergonomic workarounds. Rust has unified coroutines (https://github.com/rust-lang/rfcs/pull/2781), but the generator types are opaque so you can't encapsulate them in a struct or allocate an array of them. Not to mention that it's still extra-unstable, and last I checked, there were issues with generator size optimizations (https://github.com/rust-lang/rust/issues/59087). C++20 coroutines are similarly opaque and cannot be allocated as a contiguous array.

• A note from our sponsor - Onboard AI
  getonboard.dev | 9 Dec 2023

  Onboard AI learns any GitHub repo in minutes and lets you chat with it to locate functionality, understand different parts, and generate new code. Use it for free at www.getonboard.dev. Learn more →