"Because though we’re not doing too bad, we’re no Ada/SPARK yet" ... props to the king. A worthy aspiration. Classy.
My “grand vision” for Rust
211–220 of 323 posts
Re: My “grand vision” for Rust
#212Earlier quoted context omitted.
> You can do basically the same thing with stackfull coroutines. ...Minus the various tradeoffs that made stackful coroutines a nonstarter for Rust's priorities. For example, Rust wanted: - Tight control over memory use (no required heap allocation, so segmented stacks are out) - No runtime (so no stack copying and/or pointer rewriting) - Transparent/zero-cost interop over C FFI (i.e., no need to copy a coroutine sta…
"Tight control over memory use" sounds wrong considering every single allocation in rust is done through the global allocator. And pretty much everything in rust async is put into an Arc. I don't understand what kind of use case they were optimizing for when they designed this system. Don't think they were optimizing only for embedded or similar applications where they don't use a runtime at all. Using stackfull coro…
> "Tight control over memory use" sounds wrong considering every single allocation in rust is done through the global allocator.
In the case of Rust's async design, the answer is that that simply isn't a problem when your design was intentionally chosen to not require allocation in the first place.
> And pretty much everything in rust async is put into an Arc.
IIRC that's more a tokio thing than a Rust async thing in general. Parts of the ecosystem that use a different runtime (e.g., IIRC embassy in embedded) don't face the same requirements.
I think it would be nice if there were less reliance on specific executors in general, though.
> Don't think they were optimizing only for embedded or similar applications where they don't use a runtime at all.
I would say less that the Rust devs were optimizing for such a use case and more that they didn't want to preclude such a use case.
> having a trait in std for runtimes and passing that trait around into async functions
Yes, the lack of some way to abstract over/otherwise avoid locking oneself into specific runtimes is a known pain point that seems to be progressing at a frustratingly slow rate.
I could have sworn that that was supposed to be one of the improvements to be worked on after the initial MVP landed in the 2018 edition, but I can't seem to find a supporting blog post so I'm not sure I'm getting this confused with the myriad other sharp edges Rust's sync design has.
Re: My “grand vision” for Rust
#213Earlier quoted context omitted.
I feel you, but hear me out. OP is right. I've wanted pretty much everything he's talking about here for years, I just never thought of all of this in as quite a formal way as he has. We need the ability to say "this piece of code can't panic". It's super important in the domains I work in. We also need the ability to say "this piece of code can't be non-deterministic". It's also super important in the domains I work…
IMO rust started at this from the wrong direction. Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the panic, cannot allocate unless the developer wrote the allocation, etc. Rust instead has all these implicit things that just happen, and now needs ways to specify that in particular cases, it doesn't.
The problem isn't implicit things happening.
He's talking about this problem. Can this code panic?
foo();
Re: My “grand vision” for Rust
#214Earlier quoted context omitted.
Could you clarify what's going on in the Zig docs[0], then? My reading of them is that Zig definitely allows you to try to divide by 0 in a way the compiler doesn't catch, and this results in a panic at runtime. I'd be interested if this weren't true, since the only feasible compiler solutions to preventing division-by-0 errors are either: defining the behaviour, which always ends up surprising people later on, or; i…
More specifically, Zig will return an error type from the division and if this isn't handled THEN it will panic, kind of like an exception except it can be handled with proper pattern matching.
I can't find anything related to division returning an error type. Looking at std.math.divExact, rem, mod, add, sub, etc. it looks to me like you're expected to use these if you don't want to panic.
Re: My “grand vision” for Rust
#215Earlier quoted context omitted.
IMO rust started at this from the wrong direction. Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the panic, cannot allocate unless the developer wrote the allocation, etc. Rust instead has all these implicit things that just happen, and now needs ways to specify that in particular cases, it doesn't.
The problem isn't implicit things happening. He's talking about this problem. Can this code panic? foo(); You can't easily answer that in Rust or Zig. In both cases you have to walk the entire call graph of the function (which could be arbitrarily large) and check for panics. It's not feasible to do by hand. The compiler could do it though.
What about doing something that Java does with the throws keyword? Would that make the checking easier?
Re: My “grand vision” for Rust
#216I'm surprised by the backlash in the comment section here, all of these things seems like the obvious next step for Rust. It seem people are scared of big words?
Re: My “grand vision” for Rust
#217I just want to be able to call Default::default() from within const {}
Re: My “grand vision” for Rust
#218I couldn’t disagree more. Most of my company’s backend code is written in Scala, and most of our engineers dislike it because the language is difficult to understand, has way too many features, and has many ways to solve the same problem. I don’t want Rust to continue down this path, and I already worry with some of the syntactic sugar and type system additions being discussed that it already has. A language’s type s…
> A language’s type system doesn’t need to model every possible type of guarantee
Actually this is the exact point of a type system. Why would you want to write unit tests for stuff the compiler can guarantee for you at the type system level?
Re: My “grand vision” for Rust
#219Earlier quoted context omitted.
More specifically, Zig will return an error type from the division and if this isn't handled THEN it will panic, kind of like an exception except it can be handled with proper pattern matching.
I can't find anything related to division returning an error type. Looking at std.math.divExact, rem, mod, add, sub, etc. it looks to me like you're expected to use these if you don't want to panic.
Actually you're right, I was going by the source code which was in the link of the comment you replied to, but I missed that that was specifically for divExact and not just primitive division.
Re: My “grand vision” for Rust
#220Earlier quoted context omitted.
The problem isn't implicit things happening. He's talking about this problem. Can this code panic? foo(); You can't easily answer that in Rust or Zig. In both cases you have to walk the entire call graph of the function (which could be arbitrarily large) and check for panics. It's not feasible to do by hand. The compiler could do it though.
What about doing something that Java does with the throws keyword? Would that make the checking easier?
I think that's exactly what's being asked for here (via the "panic effect" that the article refers to)
although, I think i'd prefer a "doesn't panic" effect just to keep backwards compatibility (allowing functions to panic by default)