Zykino

I'm with the others: fd default syntax is easier to remember.

And for the interactive search I'm using skim. With it I cd to the dir I want and Alt t to trigger fuzzy finding. There are also bindings to search for dir or in the history. The neat part is that results are inserted as is in the command line, no need to xargs or copy them. It also make the history look like I always know where the files I want are when in reality they are just fuzzy-found

First time I hear about checked exceptions. How do you use them ? Are you forced to handle them explicitly ? Is the handling checked at compile time ?

3. Is a modern language with a good build system (It's like night and day compared to CMake)

Meson exists ... as do others.

But they are not the default option. And your new job may not use them.

4. And I just like how the language works (errors as values etc.)

Fair enough; though why? What's wrong with exceptions?

Exceptions is a non standard exit point. And by "non standard" I'm not talking about the language but about its surprise appearance not specified in the prototype. Calling double foo(); you don't know if you should try/catch it, against which exceptions, is it an internal function that may throw 10 level deep ?

By contrast fn foo() -> Result<f64, Error> in rRst tell you the function may fail. You can inspect the error type if you want to handle it. But the true power of Result in Rust (and Option) is that you have a lot of ergonomic ways to handle the bad case and you are forced to plan for it so you cannot use a bad value thinking it's good:

• foo().unwrap() panic in case of error (see also expect)
• foo().unwrap_or_default() to ignore the error and continue the happy path with 0.0
• foo().unwrap_or(13.37) to use your default
• foo()? to return with the error and let the parent handle it, maybe

From the article's own summary.

False Load Output Prediction and Speculative Load Address Prediction allow for data leaks without malware infection

But I guess "IA summary" did its best ¯\_(ツ)_/¯

I'm on Linux and a prebuit PC would be a nice change. But at the same price or lower than Windaube, since I don't want a licence for them.

I will prefer to build myself rather than paying an extra k…

Apparently stow -t exist too.

1. You need a license
2. usage should just be help (avoid extra step)
3. connect does not exist (see add and cmd list)
4. You can git clone <REPO> <DEST FOLDER>, no need to cd
5. maybeCreateDir is not used each time, there are some mkdir
6. "changes" is not a helpfull commit message. Accept an optional argument string and {MESSAGE:=change}
7. Accept a different repo path
8. set -euxo pipefail at the start of the script if you want to exit at any error. Some sort of bash strict mode
9. shellcheck does not like iterating over ls's output

I'm too lazy to open issues/PR for all that, and I still need to learn stow. Hopfully this might help me ? (I don't really need help with git that this sçript look to abstract too much for me.)

Thanks. I think your message is not very clear at first (since I did not know about "nav mesh"). But reading Wikipedia is clear now. It also helped me find the official page (added the link in the post).

La faute à qui ? Qui aurait pu prévoir que le groupe présidentiel ne retrouverait pas la majorité au lendemain des européenes ?

Sadly I can't recommand pop-os. In 2 years, the updates broke twice on me.

The resolutions where simple enough if you can use the command line to run sudo apt update, sudo apt upgrade. But the GUI shop updater just crashed on me without the apt error message visible.

It is a nice distro overall with which you can even try tiled windows without commiting to it.

-> pop-os is nice but it may break from times to times. So if (like me or most dev) you are ok with the CLI and just a bit of fixes from times to times then go for it. But if you are affraid of the CLI or never want to fix anything, then some other distro may be a better choice.

Just use this one... or any of this 4 others.

This is the issue for us, python outsiders. Each time we try we get a different answer with new tools. We are outside of the comtunity, we don't know the trend, old and new, pro and cons.

Your first recommandation is hatch... first time I've heard of it. Uv seems trendy in this thread, but before that it was unknown to me too.

As I understands it, it should be pip's job. When it detect I'm in a project it install packages in it and python use them. It can use any tool under the hood, but the default package manager shoud be able to do it on its own.

On that note, I'm hesitant between writing my scripts in perl or python right now. Bash prevent sharing with Windows peoples... I just want to provide easy wrappers tools that are usually aroud 10 lines of shell, but testers ain't on linux so they cannot use them.

I don't know perl, but each time I interract with pyton's projects I have a different venv/poetry/... to setup. Forget adout it the next time and nothing is kept easy to reuse.