The artifacts from some of the AI-generated images are a pretty significant detraction. For a site with so many pictures of hands, so many of them being malformed or having the wrong number of fingers (hithhiker's thumb, palmaris longus) is really off-putting.
If you use more than one operating system, you can't use the operating system browser if you want sync or the same experience. For example, I use a Windows desktop and a MacBook.
Having those things come up in conversation with a friend, who we can probably trust to deliver good information to us, is _way_ different than a platform that is going to potentially profit if they can sway you another direction.
If my friend is involved in an MLM scheme, I'm not going to trust them that I should buy NutriProteinShakeMax! I probably don't want them to tell me about it, ever!
99% of applications on Windows will just include all their dependencies in a folder with the exe. It’s great — it works, it’s compatible, it’s simple!
Getting dependencies to build your app is definitely harder on Windows but the fact that you can just throw things in a folder for a binary distribution is unbeat!
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.
I don’t think it’s about being a spectrum. It’s about having different paths to the same goal. GC is one well-proven path. Rust / Borrow checker is another path, with other benefits and limitations. Zig is well on its way to a third path with potentially the same level of safety and different benefits and limitations.
Zig will depend on having tests with good coverage, and you should probably use fuzzing. But if you care about safety and stability, why would you not write tests? Memory bugs are not the only class of safety and stability issues we should care about. So I don’t think we should be dismissive of an approach that takes a more holistic approach to those, while also providing really solid memory safety.
I am sure we will see solid static analysis tools for Zig which can weed out a lot of stuff before runtime as well. The developers of the language seem very interested in that approach but need to focus on other things first.
> Zig is well on its way to a third path with potentially the same level of safety
No. Zig says it wants to get to where Fil-C is, for a specific release mode that most people won't use, and it doesn't have even an outline of how that would work.
That's nowhere close to the "same level of safety" as (safe) Rust or Java has. We're going to see all the same bugs and all the same excuses as before.
The logic is the same as arguing that people still die while wearing seatbelts, or cut their hands while having protective gloves, thus they are worthless.
It's a false economy. Mediocre isn't good enough. The fact that mediocre is better than nothing isn't relevant when so very much better was easy.
We're talking about thermionic valves versus transistors in terms of how dramatically worse this option is than actually doing the Right Thing™.
The valve computers weren't relegated to a few specialist tasks, or seen as a particular trade-off that's no longer applicable for some applications, they were just swept aside, because they were obsolete. The memory unsafe languages, likewise, should just go away.
Yes, unfortunately just like those valve computers, progress only comes at the expense of a complete change of generation, where there aren't enough people propagating outdated concepts.
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!
That was my impression too. I used to think I'd use nothing but MX Blues forever. The 'copycat' switches haven't just caught up, they've been innovating and Cherry seems to have given up.
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?
I also think the author is understating how bad the original framework was. I've seen some of these and the "itchy points" are real true problems. The team supporting the framework decides that fixing the pain won't get them promo because it doesn't show up in any metrics, and certainly they won't accept your submitted improvements. Your only choice is to wrap it.
Of course, since their thing is a framework, your wrapper must be a framework too. (Is it possible to wrap a framework into a library?)
The end of the story is even sadder. You work on your replacement and wrapper, and oh no, the framework you are wrapping has problems or slowness because of the framework it depends upon!
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.
Note that this works because Rust doesn't have inheritance, so variance only comes up with respect to lifetimes, which don't directly affect behavior/codegen. In an object-oriented language with inheritance, the only type-safe way to do generics is with variance annotations.
reply