withoutboats3

12 ms·

31.
by withoutboats3 2y ago
I don't consider Yosh Wuyts's concept of "halt safety" coherent, meaningful or worth engaging with. It's true that linear types would enable the encoding of additional liveness guarantees that Rust's type syste
32.
by withoutboats3 2y ago
This is nothing to do with async Rust; monoio (and possibly other io-uring libraries) are just exposing a flawed API. My ringbahn library written in 2019 correctly handled this case by having a dropped accept future register a cancellation
33.
by withoutboats3 2y ago
My blog is located at https://without.boats Here are some relevant posts: https://without.boats/blog/a-four-year-plan/ https://without.boats/blog/poll-next/ https:/&#x2
34.
by withoutboats3 2y ago
I did work at Mozilla; I stopped contributing to Rust after Mozilla stopped funding the project.
35.
by withoutboats3 2y ago
I agree with that assessment of Pin. That's why the second post I linked to presents a set of features that would make it as easy to use as mutability (pinning is really the dual of immutability: an immutable place cannot be assigned
36.
by withoutboats3 2y ago
I don't deny that Pin is complicated to use as it stands (in fact that is the entire thrust of my blog posts!), just that there is some magical easier solution involving Move and changes to the borrow checker. You wrote something on th
37.
by withoutboats3 2y ago
If you actually read my posts you would see that I acknowledge and analyze the difficulty with using Pin and propose a solution which makes it much easier to deal with. My understanding is that the Rust project is now pursuing a solution al
38.
by withoutboats3 2y ago
These features are slow to be accepted for good reasons, not just out of some sort of pique. For example, the design space around combining `if let` pattern matching with boolean expressions has a lot of fraught issues around the scoping of
39.
by withoutboats3 2y ago
Rust's async model can support io-uring fine, it just has to be a different API based on ownership instead of references. (That's the conclusion of my posts you link to.)
40.
by withoutboats3 2y ago
Yes, this is the actual reason. In Java you're restricted to one implementation of an interface for a type by syntactic construction (classes list their interfaces in their header and each interface can only appear once). In Rust there
41.
by withoutboats3 2y ago
This comment contains a link to a detailed technical explanation of why the person I was replying to was wrong. Does your browser not support websites others than Hacker News? What is this peculiar delusion you have in which content not wri
42.
by withoutboats3 2y ago
I created new accounts because I didn't register with an email and lost the login. What a nasty person you are! Why don't you go create something?
43.
by withoutboats3 2y ago
I didn't ask for this to be posted on Hacker News, genius. My engagement with this community is a generous use of my free time, but I do not suffer trolls and cranks like simon-o.
44.
by withoutboats3 2y ago
This is literally a thread about a post on my blog. If you can’t find my body of work, I cannot help you.
45.
by withoutboats3 2y ago
I agree that this definition of Unpin should be improved, but I'm confused about the scenario you're describing. When does a user encounter an error because of Unpin? Is it just that they use an API which requires Unpin? If so, wh
46.
by withoutboats3 2y ago
The behavior and performance of asynchronous function depend on the behavior and performance of concurrent processes, making them more complex to reason about, test and be confident in their correctness and well-suitedness.
47.
by withoutboats3 2y ago
In my next post, one of the major features I write about is pinned projection, and its true: for any type that supports pinned projection, it needs to decide for each field if pinning is transitive or not. This is different from how mutabil
48.
by withoutboats3 2y ago
I've written thousands of words on my blog about the design of async Rust, in which I carefully explain every decision and discuss the strong and weak points. This person regularly post rude low-effort comments like this one. My body o
49.
by withoutboats3 2y ago
[flagged]
50.
by withoutboats3 2y ago
Marking the difference between a function that synchronizes with a concurrent process and a function that does not is good, actually.
51.
by withoutboats3 2y ago
Thanks for your write up. This sounds like a perfect use case for async generators (which yield many times and compile to Stream instead of Future), a feature I hope Rust will gain in the next year or two. To receive messages from other par
52.
by withoutboats3 2y ago
I'm curious why you needed to deal with `Pin` instead of using async functions. What led you to a path in which you needed to implement poll methods yourself? For what it's worth, all of the practical problems you encountered with
53.
by withoutboats3 2y ago
Could you link to a source for this in Mojo's documentation? This would be a logical interpretation, but it would mean Mojo is planning to adopt a much worse implementation of async than Rust and the post is claiming that Mojo is both
54.
by withoutboats3 2y ago
There are a couple of ways to interpret this code: 1. If this were public, or if you ever move out of the reference you get from that function, you would be violating the pin contract so this code would then be invalid. 2. Since its impossi
55.
by withoutboats3 2y ago
I think this is good feedback and it would be good for the docs to be clearer about this. Of course for the types that you're going to deal with pinned (futures and streams), they're a lot more likely to be those niche objects. I
56.
by withoutboats3 2y ago
It's clear that Mojo is in some sense inheriting Swift's notion of "value semantics," but Rust also has "value semantics" in the same sense. Rust just also has references as first class types, whereas Swift (an
57.
by withoutboats3 2y ago
Pin does have meaning: it means you cannot move the target of this pointer ever again (or invalidate its without running its destructor, which is what moving does that's the problem), unless the type of the target implements Unpin. Thi
58.
by withoutboats3 2y ago
This is true. When were working on the problem, the way Aaron Turon put it was that &mut is "too powerful." If &mut didn't give the power to move out of it, the whole design would be a lot simpler. I'll discuss t
59.
by withoutboats3 2y ago
You don't need move constructors if every future is heap allocated. But then every call to an async function is a separate allocation, which is terrible for memory locality. Some kind of virtual stack would be much better than that (bu
60.
by withoutboats3 2y ago
This isn't why development is slow. In my opinion, if I were still employed to work on Rust improvements to async would have shipped a lot faster. My blogging about it in my free time is my effort, in light of my circumstances, to get

More ›