Surprised with the push back of the comments, getting effects on Rust would be a dream.
Could even enable some stuff like passing loggers around not by parameters but by effect.
My “grand vision” for Rust
191–200 of 323 posts
Re: My “grand vision” for Rust
#192Earlier quoted context omitted.
Yes rust async isn’t good imo. You can do basically the same thing with stackfull coroutines. Also the ecosystem is setup so you have to use tokio and everything has to be an Arc.
> 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 coroutines, having a trait in std for runtimes and passing that trait around into async functions would be much better in my opinion instead of having the compiler transform entire functions and having more and more and more complexity layered on top of it solve the complexities that this decision created.
Re: My “grand vision” for Rust
#193Earlier quoted context omitted.
[flagged]
> and they force [] libraries to support multiple modes at once, I'm not entirely sure I agree? I don't think any library except for the standard library needs to "support multiple modes at once"; everything else just sets its own edition and can remain blissfully unaware of whatever edition its downstream consumer(s) are using. > which is a different kind of maintenance tax than evolving C++ compilers and feature te…
[flagged]
Re: My “grand vision” for Rust
#194Earlier quoted context omitted.
Apparently you missed Swift. Linux kernel adoption of Rust hasn't been a smooth ride, exactly because of its type system among C folks. It is only happening because the likes of Google and Microsoft want to see it through.
Swift is not really for systems level programming like Rust and interestingly some projects like Ladybird have moved away from Swift towards Rust.
> Swift is not really for systems level programming
Apple seems to think differently.
> and interestingly some projects like Ladybird have moved away from Swift towards Rust.
Not really interesting after you spent some time tracking lifecycle of FOSS projects. I don't think it is a last "moving away" announcement we get from Ladybird.
Re: My “grand vision” for Rust
#195I would love to have a use case to learn and write rust today. But i am deep in node and go services for my employer. Previously wrote java and c#. What are people writing in rust today?
> What are people writing in rust today?
Rewriting existing code for karma points and GitHub stars. Plus some minority actually trying to build something new.
Re: My “grand vision” for Rust
#196Earlier quoted context omitted.
Huh? It seems to me that in these respects the two languages are almost identical. If I tell the program to panic, it panics, and if I divide an integer by zero it... panics and either those are both "the developer wrote the thing" or neither is.
In Zig, dividing by 0 does not panic unless you decide that it should or go out of your way to use unsafe primitives [1]. Same for trying to allocate more memory than is available. The general difference is as follows (IMO): Rust tries to prevent developers from doing bad things, then has to include ways to avoid these checks for cases where it cannot prove that bad things are actually OK. Zig (and many others such a…
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; incredibly cumbersome or underperformant type systems/analyses which ensure that denominators are never 0.
It doesn't look like Zig does either of these.
[0]: https://ziglang.org/documentation/master/#Division-by-Zero
Re: My “grand vision” for Rust
#197Earlier quoted context omitted.
In .NET 11 C# async management moved to the runtime, mostly eliminating heap allocations and also bringing clean stack traces. You really only need to think about ConfigureAwait(false) when building shared libraries or dealing with UI frameworks (even there you mostly don't need it).
You speak in the past tense, but .NET 11 is not released yet at time of writing. Runtime-async is not the current reality.
True, it's in preview currently, but actually .NET is already very efficient with async today also - https://hez2010.github.io/async-runtimes-benchmarks-2024/ (.NET9 tested here).
Re: My “grand vision” for Rust
#198Earlier quoted context omitted.
Try golang, where they did the only sane thing: everything is async from the very beginning, no function colouring
I think practical experience with Go reveals that this choice being “the only sane thing” is highly debatable. It comes with huge drawbacks.
Of course it has drawbacks, everything does, but my practical experience has been hugely in favor of what golang is doing, at least, in terms of cognitive load and code simplicity. It is very much worth it in many, many cases
Re: My “grand vision” for Rust
#199I write production Rust code that becomes critical infra for our customers. I got tired of nil checks in Go and became a squeaky wheel in incident retros, where I finally got the chance to rewrite parts of our system in Rust during a refactor. I admit the skill issue on my part, but I genuinely struggled to follow the concepts in this article. Working alongside peers who push Rust's bleeding edge, I dread reviewing t…
I don't think this is an old man rant, I think you made a reasonable argument. Rust is certainly at risk of becoming just as complex as c++.
I would love to introduce more rust at work, but I dread that someone is going to ask about for, use, differences between impl X vs Box, or Pin/Unpin, and I don't have proper answers either.
Re: My “grand vision” for Rust
#200Earlier quoted context omitted.
I really think that golang makes it easy to read code, rust makes it easy to write code. If Golang had sum types it would be a much nicer language to write complex applications with
I find Go code mind numbing to read. There's just _so much of it_ that the parts of the code that should jump out at me for requiring greater attention get lost in the noise. Interfaces also make reading Go more difficult than it could be without LSP - there's no `impl Xyz for` to grep for.
It's the complete opposite for me. Rust code, especially async Rust code is just full of noise the only purpose of which is to make the borrow checker shut up