Yeah, I also recommend this. Particularly with laptops, it’s good to have a full-fledged desktop environment, since you’re more likely to need WiFi, power management, easy display configuration etc…

Oh yeah, I do think setTimeout executes in parallel, so only the largest element determines the execution time. It was difficult enough to make that sentence make sense, so I didn’t want to cram that detail in as well. 🙃

I mean, it does scale with the size of the input. Just not with the count of inputs, but rather the size of each input element.

I agree in general, that a crash is much better than silently failing, but well, to give you some of the nuance I’ve already mostly figured out:

• In a script or CLI, you may never need to move beyond just crashing.
• In a GUI application or app, a crash may be good (so long as unsaved data can be recovered), but you likely need to collect additional information for what the program was doing when the crash happened.
• In a backend service, a crash can be problematic when it isn’t actually necessary, since it can be abused for Denial-of-Service attacks. Still infinitely better than failing silently, but yeah, you gotta invest into logging, monitoring and alerting, so you don’t need to crash to make it visible.
• In a library, you generally don’t want to trigger a crash, unless an irrecoverable error happens, because you don’t know where it’ll be used.

Currently implementing error handling for a library I’m building and the process is basically to just throw all of the information I can find into there. It makes the error handling code quite verbose, but there’s no easy way for me to know whether the underlying errors expose that information already, so this is actually easier to deal with. 🫠

However there are things when the Ai is helpful, especially for writing tests in a restrictive language such as Rust.

For generating the boilerplate surrounding it, sure.
But the contents of the tests are your specification. They’re the one part of the code, where you should be thinking what needs to happen and they should be readable.

A colleague at work generated unit tests and it’s the stupidest code I’ve seen in a long while, with all imports repeated in each test case, as well as tons of random assertions also repeated in each test case, like some shotgun-approach to regression testing.
It makes it impossible to know which parts of the asserted behaviour are actually intended and which parts just got caught in the crossfire.

Yes, catastrophic software bugs…

That is a good tip. Unfortunately, I am too fish to understand it. 🙃

I just type ps and in 9 out of 10 cases, my shell suggests ps -ef | grep <process-name>. So, it’s actually less for me to type than “pgrep”…

Ah, that was a brainfart. I do use pkill primarily. I just use the other command, when I’m not sure what the process is called…

Yeah, I especially don’t understand it here, because it’s a graphical tool. You don’t have to keep backwards compatibility.

Even if you’re worried about people depending on the format that’s being piped, you could keep only the piped format stable. We have the technology.

Yeah, I would often just grab htop because I had no idea how to read the CPU usage out of top.
For example, for me it says:

%Cpu(s):  0,4 us,  0,4 sy,  0,0 ni, 98,8 id,  0,0 wa,  0,3 hi,  0,0 si,  0,0 st

Now that I look at it, I can guess that us and sy are supposed to be user and system time. And I guess id is supposed to be idle.
I have no guess what the other numbers might be, though. And well, I would often like to see the CPU usage per core.
Now I know that I can just press 1t and get effectively the same view as in htop.

I might learn top’s filtering workflow, too. But so far, I always killed processes with ps -ef | grep <process-name> and then kill <pid>, which isn’t particularly more cumbersome, so will see…

Damn, even when I don’t mention it, it’s apparently obvious that I’m gushing about Rust. 😅

I had the Rust CLI Book in mind: https://rust-cli.github.io/book/index.html
Especially, if you have experience in another language already, the first chapter shows you how to develop and ship a useful Rust application in a short amount of time. And then the second chapter contains all the detail information, which you might need, after you’ve run off and started building your own thing.

But yes, Rust By Example is also really great. It happens a lot that you search “xyz in Rust” and it’s one of the first results, and always worth clicking on.

I see the value in reading documentation front-to-back for picking up all the little tidbits of information (or at least knowing where they’re documented), but yeah, ultimately I need to be building something to really process the information.

Kind of my sweetspot is documentation that makes you build along, but doesn’t overstay its welcome. As in, don’t cram all the details along the way, but rather just dish out important information on rapidfire.
I will run off building my own thing in the middle of the tutorial, if that isn’t the case, whether I want to or not. As soon as it’s quicker to learn by dicking around with the code, I will do that and then I’ve spoiled future chapters, so likely won’t return.

What terminal emulator are you using where ctrl-c copies instead of sending SIGINT when text is selected?

I know that the terminal emulator built into the JetBrains IDEs works that way…

You generally have to fork to create a PR…

Last year, money was running out in our project and the guy who had trained me decided he’d take the L and move to another project, so we could continue in the project. And yeah, suddenly I was in the role of the lead developer.

Like, don’t get me wrong, I would’ve been the one to be moved to another project, if I wasn’t up for the task. It’s not like I was a complete dumbass.
But it did still feel more like “I guess, we doin’ lead development now” rather than something I had intentionally worked towards.

I mean, depends on the country. Labor laws here in Germany mean that it’s worth investing into workers and when you have invested, it costs you significantly more when they quit than if you just paid them reasonably.

I can’t really sell this as a solution, as it requires quite a lot more involvement than a simple configuration file should, but I use Nix Home Manager with Plasma Manager for this.

This is part of the tooling you’d use on NixOS, but you can use it on other distros, too, and it generally works fine (although I’m not sure, if the current version of Plasma Manager still supports Plasma 5, in case you’re still on a distro with that).

Basically, it allows you to define e.g. keyboard shortcuts like this:

    shortcuts = {
      ksmserver = {
        "Lock Session" = [
          "Screensaver"
          "Meta+Ctrl+Alt+L"
        ];
      };

      kwin = {
        "Expose" = "Meta+,";
        "Switch Window Down" = "Meta+J";
        "Switch Window Left" = "Meta+H";
        "Switch Window Right" = "Meta+L";
        "Switch Window Up" = "Meta+K";
      };
    };

It then fucks up the formatting, so that it looks like KDE expects, and throws it into ~/.config/kglobalshortcutsrc.
(KDE does actually have a text-based config, it’s just borderline unusable.)

Well, and you can do this with lots of other Plasma options, too. Here’s their official example: https://github.com/nix-community/plasma-manager/blob/trunk/examples/home.nix

Yeah, that’s so ridiculous. They could’ve just turned off the heating and made it lay flat, and it would’ve been fine. But evidently, they did not even think about handling an outage.

I find that if your command is complex enough that editing it on the terminal becomes annoying, then there’s a very high chance you want it in a file anyways, just to document what you did and to allow easily re-running it.

Having said that, you can also have your shell open the command in your editor of choice: https://www.stefanjudis.com/today-i-learned/edit-long-shell-commands-in-your-usdeditor/