Comment by jedisct1 | Hacker News Reader

Comment by jedisct1 | Hacker News Reader

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.

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

rust-analyzer is remarkably good.

I am curious as to how Zig comptime is going to interact with IDE features.

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.

> [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 ?

Zig does it (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.

Yes, that's a very clear and concise way of putting it, thanks.

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/

Reply on news.ycombinator.com