There have been so many catastrophic accidents along human history despite all its advancements, I don't find this particularly implausible. Also across sci-fi, the stranded in space or on a distant world is a common trope without your criticism broadly applied either.
I mean, I don't know. All I'm saying is that if someone can solve interstellar travel then they can probably land without crashing.
On Earth, (this is pulled up from Gemini) The global all-accident rate is 1.32 accidents per million flights. This equates to roughly a 1 in 759,646 chance of a flight experiencing any kind of accident (both major and minor).
We have a super low probability of crashing and yet we haven't solved interstellar travel.
Nobody is perfect, sure. But I'd wager that figuring out how to traverse light years only to crash is most likely bullshit.
If I understand you correctly, your assumptions are far more wild. Are you assuming an alien civilization has perfected interstellar travel to the point it is just a convenience comparable to modern human aviation? Millions of tourist flights across the galaxies with regular stops on earth?
I like browser-based UI, as they offer similar advantages to TUIs: You can use the UI on a different machine than the application itself is running. Arguably, modern Web standards also lend themselves to some elegant code design for UI. However, the "waste" is a valid point, but then again your TUI (and many GUIs) will fail on those things that cause the "bloat" of a browser: support for the weirdest encodings, dealing with the most absurd edge cases, supporting the largest amount of devices in a uniform manner. Shipping a whole electron for your crappy app is not what I mean. This should stop, as it trades all advantages for almost only disadvantages.
Can you compare with what used to be, to the best of my knowlege, by far the fastest implementation, https://www.cs.cmu.edu/~quake/triangle.html ? It's not int specific though, but I would still be curious
The article only mentioned he asked for a different problem, not that he was quickly explaining the solution and then asked for a different one. So this were exactly my thoughts, it's a bit like getting asked to find the roots of a polynom and replying "oh I already know how to do it, can you ask me something different?"
A post-apocalyptic desert landscape. The hero descends into the ruins, now a temple. Crude drawings of times before, people riding dinosaurs and mobile phones with arms and legs swinging a whip at the oppressed. He reaches the altar, a old MacBook, bottlecaps and fidgit spinners glued as a mosaic onto it. In the corner three starved men, riding on power generating bicycles providing some artificial light and supplying the machine with divine electricity. He proceeds and types: "we are starving. How can we get food?". Everybody waits in silence. Hours pass. Days. Slowly, letters emerge on the cracked screen: "you are absolutely right —" the screen flickers and fades. Panic. The link to God severed cynically. The hero has to seek out a new device, into distant lands. Maybe this time it will save them
OpenGL is limited to 4.1 on Apple platforms if I am not mistaken, and will not get updated ever. So you will run into missing features eventually on some platforms, e.g. SSBOs are really nice but you can't them use on Apple devices.
For me, a much stronger argument against OpenGL is that is requires a global state. This often leads to bad design, is miserable to multi-thread, and is rather tedious to port to Vulkan. I have spent several years fighting with multi-threading applications doing all sort of things in OpenGL and it is not great. Yes, Vulkan is extremely painful to set-up and you have to think about a million things you might not really care about directly, but honestly, I would also recommend against starting anything serious in OpenGL. To get your hands wet maybe, as with a couple lines you can get something running..
I think if you're trapped in the Apple ecosystem then Metal is your only production-quality option. But beginner-level learning material for it is quite sparse, so it's better to transition from OpenGL to Metal rather than learning Metal from scratch. (If you're an experienced graphics dev, you should be able to follow up on Metal by just reading their example source code)
Nope, the limitations are just too huge for actual usage. Heard Godot Engine tried to use MoltenVK for macOS but experienced too many issues so they just developed a Metal backend.
The fundamental problem is Metal 3 is just too high-level to be able to emulate all of Vulkan's behavior. The new Metal 4 API (which is more low level and similar to Vulkan in many ways) might have improved things recently, but sadly MoltenVK hasn't been rewritten to this new API yet.
Worse than OpenGL though? Haven't had the time to really look into it, probably native Metal is better, yes, but either way it might be easier to port/adapt from Vulkan than from OpenGL (due to similar concepts, no global state, etc)
I also do not like the Rust culture. I think the core problem is that it is so centered around identity, and this leaks into how the arguments are presented and how "outsiders" are judged. Which your example illustrates.
I don’t really understand what you mean. How can you have a community without identity? Isn’t that just a category? i.e. “a person who uses rust” vs “a member of the rust community”. There’s nothing wrong with either one, but the latter tends to define the culture.
