101–110 of 133 posts
Now that there's been 5 years since v1.0, is there any consensus on design mistakes that Rust made? Any mistakes that people wish they could turn back time and do differently but can't because it would break compatibility with too much existing code out there? That's the more interesting list to me.
Three chars limit for keywords and some std types, e.g. `Vec`, `len`, `str`.
I hope Rust adds the major anticipated features (GATs, const generics, specialization) soon, or alternatively decides to not implement them altogether. I'm a rather new Rust developer, but still I very quickly ran into the issue of needing a nightly version of rustc because one of my dependencies (PyO3) relied on one of these features. It would be awesome to have some periodic updates from the compiler team on the pr…
https://github.com/rust-lang/wg-traits/tree/master/minutes
https://github.com/rust-lang/lang-team/tree/master/minutes
https://rust-lang.github.io/compiler-team/
There's a youtube channel too. (Also start here: https://blog.rust-lang.org/inside-rust/2020/03/28/traits-spr... )
The important thing is the `chalk` work. And basically the rust-analyzer approach drives that.
Hah, this branch PR got merged 6 days ago into rust master: https://github.com/rust-lang/rust/pull/69406
Earlier quoted context omitted.
If you use something that's deprecated, you get a warning, yes. > could be eventually removed. It can not be used according to our stability policy. There's a lot of closed source Rust out there.
There has been talk on the internals forum of "gating" deprecated parts of the std on a new edition. So the deprecated feature will be hidden for crates that declare `edition = '2030'` but will be available for crates using an older edition. Essentially turning the warning into an error. But this is just talk at the moment. Currently there is no mechanism to implement this. It would also be a challenge for documentat…
Earlier quoted context omitted.
I think more interesting would be something we're truly stuck with (at least until Rust 2.0, which may never come).
(Stuff that’s deprecated in the standard library is stuff we’re stuck with; they cannot be removed in editions.)
Why couldn't a new Rust edition create a new std2021 (for instance), and automagically use it when importing a std submodule in a project using the new edition (and in the prelude)? The old implementation would still be imported using std in crates using prior edition, and could still be imported in the new edition, but named std2018.
If all the implementation (except the now deleted stuff) is put in the std2021 module and the old std2018 () simply re-export it (and re-implement the old stuff), you wouldn't break anything would you?
I'm probably missing something, but so far I don't know what and I'd be really happy if somebody enlightened me.
Earlier quoted context omitted.
(Stuff that’s deprecated in the standard library is stuff we’re stuck with; they cannot be removed in editions.)
I've seen this said many times, but I don't really understand why. Why couldn't a new Rust edition create a new std2021 (for instance), and automagically use it when importing a std submodule in a project using the new edition (and in the prelude)? The old implementation would still be imported using std in crates using prior edition, and could still be imported in the new edition, but named std2018 . If all the impl…
There may be possible ways of doing this, but you're approaching this from the wrong angle. Right now, this is not possible, due to policy. This policy is informed by the technical restrictions right now. There may be possible ways in the future to handle this, but as of right now, there are not.
The reason this is true right now is that there is one copy of the standard library for every program. So it needs to support all editions, because code from multiple editions may call standard library functions.
If we had multiple copies of the standard library, you may end up with issues where two different programs can't interoperate because they'd be using different versions of the same crate, and given that one of the most important features of the standard library is interoperation, this is a huge drawback for the stdlib specifically.
(There may be other technical issues, I am not an expert here, but that's the biggest hurdle as far as I know.)
Is now the time to start learning rust? In your estimation, are there going to be lots of job opportunities for people who have 15 years experience with rust? I primarily live in the .Net world, but rust seems extremely close to f# in terms of compiler safety, and I'm trying to decide what programming language to learn next.
My job is about 50% Rust, 40% Typescript, 10% Python with regards to language. I would say Rust is the best day to day experience out of these 3 except for glitchy editor tooling and the long compile times. We have 1000 line services that take close to 10 minutes for a release build which is not ideal. I would not necessarily suggest learning Rust to get a job though. We mostly stopped mentioning it in our job ads be…
That is not to say it will certainly become industrially important. It depends entirely on the numbers. Today, the total number of working Rust coders may be less than the number who start coding C++ in any given week. (This is a simple consequence of the difference between a base of thousands vs. millions.) But if it can sustain exponential growth long enough, and nothing else comes up in the meantime to take the wind from its sails, it should get there.
Is now the time to start learning rust? In your estimation, are there going to be lots of job opportunities for people who have 15 years experience with rust? I primarily live in the .Net world, but rust seems extremely close to f# in terms of compiler safety, and I'm trying to decide what programming language to learn next.
Our core tech is in pure Rust and I have to admit that coming from Javaland it's refreshing to deeply trust your code. It's hard to convey this idea of 'if it compiles it works' but I no longer worry about showing off prototypes to people. If they compile they work.
There is a learning curve as you are introduced to new ideas and design patterns but it's worth it! Rust has made me a better programmer.
Earlier quoted context omitted.
I've seen this said many times, but I don't really understand why. Why couldn't a new Rust edition create a new std2021 (for instance), and automagically use it when importing a std submodule in a project using the new edition (and in the prelude)? The old implementation would still be imported using std in crates using prior edition, and could still be imported in the new edition, but named std2018 . If all the impl…
> Why couldn't There may be possible ways of doing this, but you're approaching this from the wrong angle. Right now , this is not possible, due to policy. This policy is informed by the technical restrictions right now. There may be possible ways in the future to handle this, but as of right now, there are not. The reason this is true right now is that there is one copy of the standard library for every program. So…
Earlier quoted context omitted.
>it seems to be easier to accidentally write extremely slow code in rust than it is in go Never felt about it this way.
likely depends on your background; if you come from GC languages and are used to everything-is-a-reference, you might end up surprised that Copy types are a thing. right after that you might want to box everything so .clone() works everywhere when you find that some types aren't Copy.