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.
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.
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!
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?
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.
This is very disingenuous: we don't know how much spare time Sascha spent, and much of that time was likely spent learning, experimenting, and reporting issues to Slang.
Once upon a time, Flash, Java, Silverlight, ActiveX, etc. ruled the web.
I think the world is _much_ better off today, with a common language and platform. I don't think those big third party runtimes could survive in the browser in today's threat environment.
You might be getting “sampled textures in a single call” with “total textures loaded” mixed up. Sampled texture limits affect complexity of your shader and have nothing to do with loading content from elsewhere.
The CPU-specific intrinsic stabilized a little while ago for cases where you need SIMD on a specific platform at least. A lot of crates like glam seem to only support SIMD on x86/x86-64 for that reason.
I know that `wide`, `faster`, and `simdeez` are options for crates to do cross-platform SIMD in safe Rust. Eventually we'll have `std::simd`, but I don't know what the timeline is or what the blockers are.
This has nothing to do with scrolling. They're fixed CSS rules. They remind me of the tricks we used to have to use for vertically centering things.
It seems like these rules are from the site's page load animation. You can see it if you refresh the page part way down. It's not a great way to achieve that effect.
There's nothing on this site using calc as part of scrolling the content. It looks like the background image is fixed in place with some JS, which is probably the source of the performance issues.
The questionable stuff is definitely that everything is a table and that the links on the bottom of the page are divs with onclick handlers... and that selection is turned off?
You can combine the approaches! KTX2, for example, supports "supercompressing" GPU block compressed formats with LZ4 or Zstandard. The project I have been working on ships BCn textures compressed with zstd and it has been pretty dang good.
There are lots of places, including many national forests, where you can cut your own firewood for free.
If you live near the Flathead National Forest in Montana in the US, for example, you can cut firewood for a campsite without a permit. You can also get a free permit that allows you to cut 4 to 12 cords of wood per adult per year.
I don't know anything about firewood laws in Sweden or the rest of Europe. From first glance they look quite a bit more restrictive.