Yeah, I also have to say that I’ll often not even bother trying to work out what’s good and what is not, because there’s a voice in the back of my head that says, well, it should all be equally viable, because of balancing.

That’s a big part of the reason why I like random map generation, because it isn’t possible to make all options equally viable. Sometimes, you level up your axe skill and never find a good axe, and just have to deal with that.

I doubt the details make for a particularly riveting story, but just to say it: I do think it is more complex than her just not being a good person.

Yeah, or their parents argued a lot and they don’t want to end up in a relationship where this is the case. This can also mean they’re quick to exit a relationship as soon as the first conflicts need to be resolved, because it feels like a sour relationship to them.

Many years ago, I was working together with a girl my age for about 3 months and I had decided pretty early on that I didn’t want to impress her, but that I would use the time to work on smalltalk and such. It was a factory job with lots of boring tasks, so there were lots of opportunities to entertain each other.

After 2½ months, I felt like I was doing better than I’ve ever done in my life. Then she hit me with the sentence: “I don’t think any girl would want to go out with you, because you don’t talk enough.”

So, basically worst case: That’s genuinely what she thought.
‘Best’ case: She was trying to hurt me, but well, she still knew which wound to poke into, so I guess, I wasn’t doing that great either way.

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…

Not sure about video playback, but I feel like the PeerTube website is much more efficient. The YouTube website is amazingly badly coded…

Dried lentils don’t need to be pre-soaked, but I prefer to cook them separately and drain the water they boil in.

Pre-soaking lentils (and pouring the water away) makes them easier to digest, in particular it makes them bloat you less.

https://farmhouseguide.com/benefits-of-soaking-lentils/

An exception are dehulled lentils, like red lentils. They don’t need pre-soaking and are quicker to cook, too. I often throw red lentils into the cooking water with my noodles or rice, just to add some protein into the meal.