3 ms·

If Rust had to be rewritten from scratch today, it would probably be done differently, learning from experience since it was invented. Cargo, macros, const gen

If Rust had to be rewritten from scratch today, it would probably be done differently, learning from experience since it was invented. Cargo, macros, const generics and `#[cfg]` wouldn’t exist any more, replaced with comptime evaluation. The standard library would be half its current size (considering its redundant functions, deprecated functions, or constructions that Clippy wants to be replaced with other constructions). IDE integration would be considered immediately. Per-function allocators wouldn’t be an afterthought (the current proposal is really bad, but it’s too late to do something better). And async would be part of the language and the standard library, “colorless” and completion-based. The problem is that it’s too late. The Rust language itself is mature, and cannot afford major breaking changes any more. So, improvements can only be made on top of what’s already there, limiting their integration, and making the whole thing more and more bloated and complicated.

navaati 6y ago
> [async] “colorless” I’m super interested that you think that’s something that can exist, how would it work, what would it look like in your mind ?
- robinei 6y ago
  Zig does it (https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/). Basically using "await" just means you are declaring opportunity for concurrency at the call site, but it is still valid to await a synchronous function. And it is valid to call a function synchronously, even if it internally supports concurrency via await.
  - kristoff_it 6y ago
    Yes, that's a very clear and concise way of putting it, thanks.
- littlestymaar 6y ago
  I think the GP refers to Zig's approach[1], which is just “do mark functions as sync or async in there signature, just switch between two modes at compile-time using a global flag”, which I don't think fits well into Rust's values of being explicit about what is happening. [1]: https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/
littlestymaar 6y ago
I see you're a fan of Zig's design, but I don't really think Rust would be as you describe even if it was made today, for several reasons: - comptime evaluation aren't something Rust designers are interested in, as it doesn't fit their functional programming mindset[1], (and it's not a new concept to Zig, D has had something similar for long). - An IDE-first compiler is a good idea (and a must have for a production language today) but I'm not sure how feasible it is to start with something like that. If it's going to slow down early development, then it's definitely not a good move to go there first, but I don't know. - per function allocation is a pain in the ass from a usability perspective. In fact it recreates the same “function color” problem you'd like to avoid. Just think of your non-allocating functions as blue and allocating ones as red functions, you can't call a red function from a blue one. - Zig's “colorblind” asynchronous function rely on automagically switching between async and sync functionn at compile-time, and I really don't see that fitting with Rust's thrive for explicitness. [1]: https://twitter.com/pcwalton/status/1369114008045772804 https://twitter.com/pcwalton/status/1369114008045772804
- roca 6y ago
  rust-analyzer is remarkably good. I am curious as to how Zig comptime is going to interact with IDE features.
pcwalton 6y ago
None of this is true. Zig generics are dynamically typed; Rust generics are statically typed. Everyone in Rust was absolutely aware of dynamically-typed generics and they were actively rejected. Explicit allocators were likewise rejected. They were deemed to add too much noise in the 99% case in which you just want to use the system malloc. You might disagree with that decision, but none of Rust's designers consider it a mistake. I'm also very skeptical that the ability to automatically switch between async and sync would be the right decision for Rust. It may be the right decision for Zig. But in Rust we have to, for example, work properly with OS TLS and any sort of automatic async/sync switching would be a footgun.

navaati 6y ago

> [async] “colorless” I’m super interested that you think that’s something that can exist, how would it work, what would it look like in your mind ?

robinei 6y ago
Zig does it (https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/). Basically using "await" just means you are declaring opportunity for concurrency at the call site, but it is still valid to await a synchronous function. And it is valid to call a function synchronously, even if it internally supports concurrency via await.
- kristoff_it 6y ago
  Yes, that's a very clear and concise way of putting it, thanks.
littlestymaar 6y ago
I think the GP refers to Zig's approach[1], which is just “do mark functions as sync or async in there signature, just switch between two modes at compile-time using a global flag”, which I don't think fits well into Rust's values of being explicit about what is happening. [1]: https://kristoff.it/blog/zig-colorblind-async-await/ https://kristoff.it/blog/zig-colorblind-async-await/

littlestymaar 6y ago

I see you're a fan of Zig's design, but I don't really think Rust would be as you describe even if it was made today, for several reasons: - comptime evaluation aren't something Rust designers are interested in, as it doesn't fit their functional programming mindset[1], (and it's not a new concept to Zig, D has had something similar for long). - An IDE-first compiler is a good idea (and a must have for a production language today) but I'm not sure how feasible it is to start with something like that. If it's going to slow down early development, then it's definitely not a good move to go there first, but I don't know. - per function allocation is a pain in the ass from a usability perspective. In fact it recreates the same “function color” problem you'd like to avoid. Just think of your non-allocating functions as blue and allocating ones as red functions, you can't call a red function from a blue one. - Zig's “colorblind” asynchronous function rely on automagically switching between async and sync functionn at compile-time, and I really don't see that fitting with Rust's thrive for explicitness. [1]: https://twitter.com/pcwalton/status/1369114008045772804 https://twitter.com/pcwalton/status/1369114008045772804

roca 6y ago
rust-analyzer is remarkably good. I am curious as to how Zig comptime is going to interact with IDE features.

pcwalton 6y ago

None of this is true. Zig generics are dynamically typed; Rust generics are statically typed. Everyone in Rust was absolutely aware of dynamically-typed generics and they were actively rejected. Explicit allocators were likewise rejected. They were deemed to add too much noise in the 99% case in which you just want to use the system malloc. You might disagree with that decision, but none of Rust's designers consider it a mistake. I'm also very skeptical that the ability to automatically switch between async and sync would be the right decision for Rust. It may be the right decision for Zig. But in Rust we have to, for example, work properly with OS TLS and any sort of automatic async/sync switching would be a footgun.