As I understand it if everything goes well it should land in Rust 1.75 (along with impl-trait-in-traits syntax) - this version comes out on 2023-12-28. Note that it will have some limitations for the time being, but it is good enough for people working in embedded environments or using tokio in executor-per-thread configuration which is not a default. People working with generic code (libraries) that should support both Send and non-Send features will hit this limitation more often. See more on the stabilization PR #115822
Why does the colored output for cargo mentioned at 11:15 not work for me both in Linux Ubuntu and Windows terminals (for which I also enabled colored output in said terminals)? Am I missing something? running cargo with '--color always' also doesn't do anything for me
Well, I guess that's on me. I think I got the color portion of the reporting wrong. The PR for the big help output overhaul was listed in the 1.73, and neither the release notes for 1.73 or 1.74 explicitly mentioned color. I put this all together before 1.73 was released, so I was using the Beta version of Rust, which I thought would become 1.73. Apparently, at the time I was using the beta, it was what was going to become 1.74. So between my testing of a version of cargo too far ahead and the release notes not explicitly saying when the color portion was introduced, I messed up. Sorry about that, folks! If you want to check it out right now, you can do: rustup install beta cargo +beta help cargo +beta run --help
I think it’s actually kind of cool that someone cared enough to contribute that. When so much of a project is driven by volunteer contributions, you get all sorts of cool stuff. Remember that the alternative in projects without full-time paid employees behind it is typically just *less* contributions, not different contributions. It would be cool if I could indicate on the videos which features were pure open source vs paid for but free choice vs paid for and wanted by a company. I’ll keep my eyes open for a way to do that, but so far my understanding is that the vast majority of contributions are due to someone simply volunteering to work on something they were interested in, even when a company happens to be paying them for their time.
It's a nice feature to have. It improves code quality. The person who contributed it might not have the required skills to work on the compiler at all, it's not like time is being "wasted".
I figured the time would have been better spent fixing things like iter vs into_iter vs iter_mut(or that any of these are needed). Or that we have a borrow checker and type inferencing, but we choose not to have inferences typed parameters, return types or mut/ref variables. At what point did the language stop doing extra things for us? It makes it difficult to see a clear intent for the languages future...
This is actually an honest question I get from a lot of people new to Rust. I answer it _extensively_ in my Ultimate Rust Crash Course: agileperception.com/ultimate_rust_crash_course The short answer is: Anyone who needs high performance, high efficiency (think low battery usage in mobile or embedded), high safety (think space shuttle), a good experience interoperating with C, a good experience collaborating with others on a large codebase, or a high quality of life while coding.
