MoltenVK is also a thing. Whatever small translation overhead it incurs is probably not that important for a text editor. And then you get a cross-platform API: not just Linux, but Windows as well. Maybe also other more niche OSes as well.
Molten VK is amazing. When I started working with it, I was expecting a lot of caveats and compromises, but it's shockingly similar to just using Vulkan that you can easily forget that there's a compatibility tool in play.
Probably you can squeeze a bit of optimization out of using Metal directly, but I think it's a more than viable approach to start with Vulkan/MoltenVK as a target, and add a Metal branch to the renderer when capacity allows (although you might never feel the need)
When they do "realize" that, B2B companies end up building products that are evaluated by procurement managers but not end users. Lots of examples in the industry.
So I'd really rather most didn't come to that realization. And, well, we as developers do have some influence.
To be fair, sometimes meticulous users investigate the bugs and write down logical chains explaining the causes and even offer a solution at the end (which they can't apply for the lack of commit access, for instance).
The proposed solution isn't always right, of course, but it would be incorrect to say that no bug reports come with a diagnosed cause. But that's exactly where a conscious reviewer is most needed, I believe.
I sometimes write a detailed bug reports but not a PR when there are different ways to address the problem (and all look bad to me) or the fix can introduce new problems. But I would expect LLM to ignore tradeoffs and choose an option which not necessarily the best for the same reason I hesitate - luck of understanding of this specific project.
Speaking of text editors and tools like that, you can often avoid having tests (or postpone adding them for a long time), if the logic is on the main execution path, meaning you'll execute it every time you run the program, and whatever failures that can happen, are reasonably easy to pinpoint (i.e. the program shows error backtraces or somehow traces problems otherwise).
This is from my experience hacking on Emacs, naturally.
At the same time, projects that you might ship for an employer or a client, are more critical to check for correctness before deploying, and are often more complex to run and check manually on the regular than writing at least one "happy path" integration test at least for the main scenario (or several).
Probably safer to hug them than another human. Most diseases don't even cross species boundaries, seems unlikely they'd do well trying to infect a completely alien being.
The reason that diseases from the old world were so deadly, when they crossed the pond, is that they'd evolved to spread quite well even in humans with an evolved or acquired resistance and were suddenly in a completely unprepared population.
The danger would be organisms that simply eat our biochemistry but are entirely immune to any of our defenses. Think flesh eating bacteria from space, only it also basically eats our entire biosphere.
Aliens from different biospheres will never be able to have physical contact.
If they are close in biochemistry the dangers are extreme to catastrophic. If we actually found a crashed UFO with bodies we should drop a thermonuclear bomb on it immediately. Just ask the Native Americans.
If they are not biochemically close chances are we and our environment would be horribly toxic, freezing, or boiling hot to them and vice versa.
reply