Unix sockets
Unix sockets
Posted Jan 1, 2025 12:09 UTC (Wed) by mathstuf (subscriber, #69389)In reply to: Unix sockets by kleptog
Parent article: Systemd improves image features and adds varlink API
I don't think Go does shared-nothing and, while there are actor frameworks for Rust, they are by no means typical. The borrow checker is Rust's no-race solution, not shared-nothing.
Posted Jan 1, 2025 12:31 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
Borrow-checker works quite poorly with I'm not blaming Rust developers for that design: it's hard to imagine how could they made something better. But if not for the need to pile that work on top of many layers of kludges then they could have either removed That wasn't done and for obvious reason: adding yet another layer of kludges on top of kludges is just simply easier than changing the foundations.
Posted Jan 1, 2025 15:19 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Note that I claimed nothing of the sort related borrow checker and async. I was pointing out that Rust does not use anything resembling Erlang's actor model.
> Borrow-checker works quite poorly with async because you, very often, couldn't pass borrows throw await point (and righfully so) thus you end up with bunch of Arc's and correctness is no longer checked by the compiler.
I believe there are efforts in the works so that variables which do *not* live across an `.await` point do not affect things like `impl Send` for `async fn` synthesized types.
> That wasn't done and for obvious reason: adding yet another layer of kludges on top of kludges is just simply easier than changing the foundations.
Note that Rust *is* tackling "changing the foundations" problems, but "require all new kernel functionality" isn't one of them (Rust also aims for practical use with existing platforms after all).
Posted Jan 1, 2025 17:40 UTC (Wed)
by khim (subscriber, #9252)
[Link]
And that's exactly what we are talking about here. Remember where the whole discussion started: For me the problem is not how the things were done initially, but rather why they stayed that way even after the original reasoning were no longer relevant. Only in a sense that it's one of the [very few] modern languages that are not sitting on top of massive runtime written in C pr C++. And yes, Rust is very good at what it does, only scope of what it does is still limited by the fact that it have to deal with all the accumulated piles of kludges everywhere. In particular an attempt to embrace “modern green threads” (that are called Technically Google Fibers are much smaller and simpler thing than Rust, but because it changes the foundations people reject it. Often that rejection is even happening on the spiritual level that's fig-leafed by the reasoning that kernel thread have to use 16KiB which means we shouldn't even try to improve 1-to-1 model but have to go with green threads (that are called
> The borrow checker is Rust's no-race solution, not shared-nothing.
Unix sockets
async because you, very often, couldn't pass borrows throw await point (and righfully so) thus you end up with bunch of Arc's and correctness is no longer checked by the compiler.sync entirely (but then you need to do syscalls differently) or, alternatively, could have adopted “millions of threads” Google Fibers model (and the borrow checker would have been much more usable).Unix sockets
> Rust also aims for practical use with existing platforms after all
Unix sockets
async/await today) makes Rust's safety story weaker…async/await today). I wonder why it, suddenly, these 16KiB have became so critical today… they weren't critical 20 years ago, so what have changed not?