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.

That's a really good explanation. I would just add that I find easier to search for orphans with git log --graph --reflog than using `git reflog directly, especially if it's one of the top entries in the reflog.

I’m not familiar with C tooling, but I have done multiple projects in C++ (in a professionnel environnement) and AFAIK the tooling is the same. Tooling to C++ is a nightmare, and that’s and understatement. Most of the difficulty is self inflicted like not using cmake/meson but a custom build system, relying on system library instead of using Conan or vcpkg, not using smart-pointers,… but adding basically anything (LSP, code coverage, a new dependency, clang-format, clang-tidy, …) is horrible in those environments. And if you compare the quality of those tools to the one of other language, they are not even close. For exemple the lint given by clang-tidy to the one of Rust clippy.

If it took no more than an hour to add any of those tools to a legacy C project, then yes it would be disingenuous to not compare C + tooling with Rust, but unfortunately it’s not.

As a rough estimation, if you include everything (apperance, discussion, functionality, interaction with other controls, …) I would say that every single input field or button is about a day of work. And then you start to realise how many buttons there is in any GUI and how much it will cost.

Usually when people say “I suck at maths”, it means that they are bad at doing manual calculus. Maths is extremely useful in programming, but it’s absolutely not the same kind of math. I don’t think that the grade you had in math at school will influence in any if you will be good or bad in programming.

There take on what they call capabitilites is very interesting. Basically anything that would make a function non-pure seems to be declared explicitely.

A computational effect or an "effectful" computation is one which relies on or changes elements that are outside of its immediate environment. Some examples of effectful actions that a function might take are:

• writing to a database
• throwing an exception
• making a network call
• getting a random number
• altering a global variable

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

That's an interesting idea, but as someone else pointed using a voice modulator would be much better. Technical skills are importants, but human behaviors too. I would not trade a nice average coworker for someone who is better technically but doesn't know how to communicate. And typing is complementary, not a replacement for voice communication since the amont of information you can share in a minute is 3-5 times higher by voice.

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.

You seems to have a severe issue so I'm not sure what I'm going to say may help.

Learning something and then forgeting it is absolutely normal. Repetition over and exponentially long time and sleep in between helps a lot. Some people use flashcards to helps with memorisation. The idea is simple, when you learn something you write question + answers on a piece on paper (usually bristol for easy manipulation) and put it in a box. This box has multiple compartment: every day, every second day, once a week, once every second week, once every second month for example. When you add a card you add it to the “every day” compartment. Then each day you open all the compartment of the current day and ask yourself all the questions. If you correctly remember the answer you put it in the next compartment, and if you don't you put it back to the “every day” one.

Another way to helps you understand and rembembering things is to explain them to others. If you don't have someone to explain what you just learn you can create youtube video (even if noone will watch them but you do as if you had an audience). As bonus you now have a video that explains using your language something you just learn if you ever forget it!

It's especially true when you want to parse some json/xml/whatever. Just describe your datastuctures with regular struct and enum, add serde and done! It's like magic!

I need to re-try it. I really like like lsp/dsp are first class cityzen, including the keybindings, and that there is better text objects than in vanilla neovim. Last time I tried it there was a few things that where not that easy to set-up (I forget what), but I should definitively take the time to learn it.

I just wish that neovim/kakoune/helix had a marketplace just like vscode. It make the discovery and installation so much easier when everyone use the same tools.

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.

I do understant why old unicode versions re-used “i” and “I” for turkish lowercase dotted i and turkish uppercase dotless I, but I don't understand why more recent version have not introduce two new characters that looks exactly the same but who don't require locale-dependant knowlege to do something as basic as “to lowercase”.

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.