The quote (and the associated discussion) is such an important part of Rust and why I love this language so much. Anything that can be automated should at one point be automated reliably, and the sooner the better.

I wasn’t clear enough. But in a contry where the sun rise at 20:00, the weekday looks like:

• day 1: Monday morning to Tuesday evening
• day 2: Tuesday morning to Wednesday evening
• day 3: Wednesday morning to Thurday,
• …

And phares like "let’s meet on Tuesday“ without hour indication could either mean end of day 1 or start of day 2. Likewise "let’s meet the 20th” (assuming the 20th is a Tuesday) could either mean end of day 1 or beggining of day 2.

–

And alternative be to have

• day 1 == Monday == “end of the 19th” to “the start of the 20th”
• day 2 == Tuesday == “end of the 20th” to “the start of the 21st”
• day 3 == Monday == “end of the 21st” to “the start of the 22nd”
• …

Which solve the issue of "let’s meet on Tuesday”, but not “let’s meet the 20th”.

The issue is that the notion of “tomorrow” becomes quite hard to express. If it’s 20:00 when the sun rose, when does tomorrow starts? In 5 hours ?

Interesting idea indeed. I’ve never used async yet, but I’m always surprised at how the problem space seems to be much more complicated than what it initially looks like.

You shouldn’t, it’s short and interesting

Yeah, this make sence

It’s also what I understood from what I read but I assume it was just a poor choice of word. Debug symbols are way too important for debugging to be stripped by default.

vim can have IDE-like capabilities thanks to lsp and tree-sitter. That’s a real game changer and is quite easy to set-up with something like kickstart.nvim.

That’s a very, very good read on how to make a very complex C project safer in practice. To sum-up: make it possible to introduce new module in a memory safe language (Rust in this case), make it harder to write bugs in C since the C part is not going to disappear overnight, and use as much tooling as you can to find any existing or newly introduced bugs (both memory bugs a logique error).

That’s really a nice addition

I don’t agree with the sentiment that debuggers are sub-optimal for Rust and that’s why they are not used. In C++, I hop in gdb all the time, and I’m very fluent with it. But I never had the need for it in Rust. So they may be sub-optimals, IDK, I never had an issue in Rust where the best tool would have been a debugger.

I would never do printf debugging in C++ because it’s too complicated to do. In Rust with Display/Debug it’s a breeze. And my best debugger for Rust is the compiler itself. But most importantly, most of my bugs are caught at compile time. The few remaining one are logic error and best analyzed with logging, aka printf debugging, and not a debugger that can pause the execution.

It seems extremely interesting.

Would encoding images in oklch before compressing them using jppeg or whatever is used for video compression helps to have much better dark while still keeping current compression ratio?

This new OKLCH color space looks really nice to use. It’s surprising that it’s really human readable, I wouldn’t have guessed that you could do it for random colors.

I’m a bit surprised. Why does OKLAB gradiant looks better than OKLCH?

I can totally understand the iterating speed due to higher cognitive load of a statically typed language, and non instant compilation.

However I am very surprised about your refactoring experience. For me Rust is at least in a league of its own. In python/js I am terrified that I could break some unknown parts of my code whenever I touch anything. In C++ I fear that I just broke an invariants and made something UB. In all those languages, I expect regressions when I’m refactoring. But in Rust, even for large scale architecture changes if it compiles I’m quite certain that it’s going to be easy to validate and often works the first try. What point points do you enconter that make your experience sub-optimal ?

I didn’t know about CACHEDIR.TAG, that’s good to know. And yes, Rust tooling is stellar.

I definitively love llogic comments when he(she?) has no submitions for the quote of the week!

That was a fantastic read. I’m both impressed by the stellar performance of C, and the stellar safety of Rust while keeping nealy best in class performances.

Yes exacly. And I assume that the test suite of all of those project are long enough to average the usual jitter of wall time mesurement.

What I’m hoping to see is if rust+llvm vs rustc+gcc binary speed are within a few percents or if there is a real difference between the two (I’m expected that we eventually reach the former once thinLTO and other optimisations are implemented).

And while doing so it could also be possible to measure the difference in max RSS.

Now that you can compile and run tests, how performant are they compared to rustc+llvm? I know that thinLTO is not yet enable, and I guess a few other important optimisation, but I’m interested to know what we can already get.