lpghatguy · HackerTrans

I find it frustrating when people talk about memory safety as “a spectrum.” Yes, there are safer patterns in unsafe languages, but at the end of the day, not having memory safety as a category of bug _period_ is such a nice baseline level to work from!

If you hit a weird state in your program and it can _never_ be caused by memory corruption, you rule out a big bug space and no longer need to check the entire scope of your program. It’s similar to Rust’s unsafe blocks — it doesn’t really matter if they’re “more unsafe” than Zig because in Zig the scope of the unsafe is your entire program! Local reasoning is a huge part of what you buy into and I could never give that up if I didn’t have to.

lpghatguy

last monthdiscuss

Take care here though, because shaders are almost always working in linear sRGB colors, while color codes are almost always defined in gamma-encoded sRGB.

This property makes it mildly annoying to copy color constants between different contexts.

lpghatguy

2 months agodiscuss

It's the StackExchange model! This has bootstrapping issues, is hard to break into the community, and risks creating moderator cliques.

lpghatguy

3 months agodiscuss

I bought the same keyboard when I was a teenager as my first "real" keyboard!

These days I have a ZSA Moonlander. I adore it! I love how easy it is to program it without any software installed and it's been phenomenal to customize it to fit me perfectly.

I just changed all the switches out (in order to be quieter than my stock Cherry MX Brown switches) and replaced them with a set of Gazzew U4 switches. I'm _shocked_ at how far mechanical switches have come along since the days of Cherry dominance. They're super quiet and still have an awesome tactile feel!

lpghatguy

7 months agodiscuss

In my career, I've found that this problem crops up the most when a team is unable to make impactful changes to a system that they depend on. It's so much easier (and requires less collaboration and fewer approvals!) to build an abstraction over some core system than to actually fix the core system, even if fixing the core system is always the better choice.

I was very guilty of this as a young go-getter engineer! Why try to convince another team that something should be fixed if I can just paper over it?

lpghatguy

9 months agodiscuss

Years ago, I introduced Flow gradual typing (JS) to a team. It has explicit annotations for type variance which came up when building bindings to JS libraries, especially in the early days.

I had a loose grasp on variance then, didn't teach it well, and the team didn't understand it either. Among other things, it made even very early and unsound TypeScript pretty attractive just because we didn't have to annotate type variance!

I'm happy with Rust's solution here! Lifetimes and Fn types (especially together) seem to be the main place where variance comes up as a concept that you have to explicitly think about.

comments