Maybe a good idea for a post. But the amount of reaches required makes this icky.
Pretending people write:
rust
let Ok(x) = read_input() else { return Err(Error) };
instead of
rust
let x = read_input().map_err(|_| ...)?;
Pretending people write:
rust
const x: &str = "...";
instead of
rust
const X: &str = "...";
Pretending there exist people who have such knowledge of rust macros hygiene, ident namespaces, etc, but somehow don't know about how macro code expands (the "shock" about the compile error).
Maybe there is a reason after all why almost no one (maybe no one, period) was ever in that situation.
Bringing vimperator/pentadactyl back! That would be the dream.
Anyway, last time I tested it (~3 weeks ago), servo was not very usable still with the few websites I tried. Hopefully it gets, at least partway, there in a few months.
The best "support" you can get is support from upstreams directly (I'm involved in both sides of that equation). But upstreams will often only "support" you when you 1. run the latest stable version 2. the upstream source code wasn't patched willy-nilly by the packager (your distro).
So the best desktop linux experience comes with using rolling distro that gives you such packages, with Arch being the most prominent example.
The acquired knowledge that argues stability and tells you otherwise is a meme.
a better solution would be to add a method called something like ulock that does a combined lock and unwrap.
That's exactly what's done above using an extension trait! You can mutex_val.ulock() with it!
Now that I think about it, I don’t like how unwrap can signal either “I know this can’t fail”, “the possible error states are too rare to care about” or “I can’t be bothered with real error handing right now”.
That's why you're told (clippy does that i think) to use expect instead, so you can signal "whatever string" you want to signal precisely.
The most interesting part here is the polling only has to take place on the scope itself. That was actually what I wanted to check, but got distracted because all spawns are awaited in the scope in moro's README example.
f1 and f2 are run concurrently, f3 is run after f2 finishes, but doesn't have to wait for f1 to finish, which is maybe obvious, but... (see below).
So two things here:
Re-using the spawn terminology here irks me for some reason. I don't know what would be better though. Would defer_to_scope() be confusing if the job is awaited in the scope?
Even if assumed obvious, a note about execution order when there is a mix of awaited and non-awaited jobs is worth adding to the documentation IMHO.
I skimmed the latter parts of this post since I felt like I read it all before, but I think moro is new to me. I was intrigued to find out how scoped span exactly behaves.
rust
async fn slp() {
tokio::time::sleep(std::time::Duration::from_millis(1)).await
}
async fn _main() {
let value = 22;
let result_fut = moro::async_scope!(|scope| {
dbg!(); // line 8
let future1 = scope.spawn(async {
slp().await;
dbg!(); // line 11
let future2 = scope.spawn(async {
slp().await;
dbg!(); // line 14
value // access stack values that outlive scope
});
slp().await;
dbg!(); // line 18
let v = future2.await * 2;
v
});
slp().await;
dbg!(); // line 25
let v = future1.await * 2;
slp().await;
dbg!(); // line 28
v
});
slp().await;
dbg!(); // line 32
let result = result_fut.await;
eprintln!("{result}"); // prints 88
}
fn main() {
// same output with `new_current_thread()` of course
let rt = tokio::runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap();
rt.block_on(_main())
}
The term open-standard does not cut it. People should start using "publicly available and sharable" instead (maybe there is a better name for it).
ISO standards for example are technically "open". But how relevant is that to a curious individual developer when anything you need to implement would require access to multiple "open" standards, each coming with a (monetary) price, with some extra shenanigans[archived] on top.
IETF standards however are actually truly open, as in publicly available and sharable.
I don't do C++ as a life choice, and thus not 100% sure what the author means here. But I have the feeling that he is wrong, on multiple levels even 😉