Contents
That Rust doesn’t, but this Rust won’t rust, right?
«Rust has been said to be named after a particularly robust type of fungi that is “over-engineered for survival” according to Hoare.» from [1]. «Rust began as a personal project in 2006 by Mozilla Research employee Graydon Hoare.» (Wikipedia)
It’s probably the Rust fungus (here) Hoare is referring to. Why not start with an aside: the «Rust» name probably does not have any double meaning with the iron oxide type of rust (here), which for many years has had its way with this fascinating stud link chain that I found on a dock facility. It is often used for anchoring ships since this type (also) is rather over-engineered for rough usage (survival). I assume that this will be the only figure as such in the note, so why not enjoy it first as last:
Fig.1 – Rusted stud link chain
Aside: The story of when I found this chain is at Øyvind Teig [Rusted chain]. Oh, how concurrent those chains are😊. But then, since it’s not about just laying beside each other here, they don’t seem to communicate much🙃.
An aside on async/await
This note started with an attempt to explain Rob Pike‘s subtle lament over async/await in a lecture in 2023, as shown in 072:[An aside on async/await]. At first the below paragraph was there, until I decided to make a new note instead, and move it to here. After this, I have learn some and also modified it:
(1) Pike talks in general terms here. Explained it might mean something like the red points below, even he does not mention Rust with a word:
(2) Rust does have threads (native OS threads, scheduled by the OS) and channels (asynchronous channels for communication between threads)
(3) For lighter threads the Rust team has chosen the async/await paradigm (here and here, where they call it async-await) where an async_fn «task» function returns a Future when it typically waits for I/O, scheduled again with future.await. Central to this is the tokio runtime (at least suitable for backend usage)
(4) One may also use other runtimes, like Rayon, reqwest or Embassy (the latter suitable for embedded applications). These runtimes seem to be exclusive to each other
(5) I hope, once any one of us have chosen (only?) one of these, that this is still supported some years away. And that the next programmer reading my code will understand and agree. Rust probably then is not an instance of occam’s razor, saying that «Entities must not be multiplied beyond necessity». (Maybe I’m just saying this because I’m silently knocking at the door, with another type of baggage; then everything looks more complicated than «necessary»?)
(6) Why didn’t they choose CSP (072:[«Bell Labs and CSP Threads»]) with asynchronous channels and select? I just wonder, as Rob Pike did, as «it pushes some of the complexity back on the programmer«. Even if he suggest why this might be so (it «requires significant runtime complexity, and I can understand why some folks prefer not to build that into their systems«).
(7) But then, not for small embedded. I (not alone) have written two runtimes for light-weight CSP (or «CSP») tasks in C. It’s not that difficult. But this was on top of nothing, just running on the iron (ChanSched). However, the first runtime was on top of an existing SDL runtime system, with asynchronous buffered messages underneath (CHAN_CSP). But the latter was more difficult to read than the first. Of course C allows that burden, but the weight is carried by the user
(8) These points are also questions which I’d like to know the answers to myself, since I, to be honest, don’t understand all of this
(9) I think Turing postulated that the Turing Machine may simulate any other computer. Would this imply that one could make a CSP runtime for light threads, or even for parallel tasks, for Rust? Or is this only revealing that I long for my golden hammer and don’t want a difficult saw to quarrel with?
Intro
References
Wiki-refs: Rust (programming language)
- Why Rust is the most admired language among developers by Sara Verdi, 30Aug2023, see https://github.blog/2023-08-30-why-rust-is-the-most-admired-language-among-developers/
- …
- …
- …