You will laugh, but Apple started to call “cross platform” things that are used or run on more than one of their product. So cross platform between iOS, macOS, Apple TV OS(?), watchOS.
But all of those run Darwin, so for something like a graphics API that has nothing to do with GUIs and whatnot, the "platform" for all of those is the same.
In this vein and previously discussed on HN[1], but there is a weird DX3D bridge in Linux that is available on WSL2. Still not "cross-platform" and seems to mostly exist to support ML workloads for Windows users.
It's overly verbose and error prone. Try adding an observable attribute. Then add another one. Then do something simple like change the name of the first one.
The Web Component APIs don't aim to be easy to use by application developers. That is simply not a goal of the spec. They're low level APIs which expose behavour and hooks on which libraries and frameworks can be built. As an application developer you are supposed to use those friendly libraries.
Aaand that's the problem with the API. The question was, how is API atrocious. Once an answer is received, it's immediately diverted to "the API is not for devs, you have to use libraries".
This doesn't make the API any less atrocious. And it would be nice if the platform didn't rely on libraries to make it usable.
Sure, from a dev perspective the API may be bad. But I'm saying that that isn't the right perspective to use when judging it.
"Nice" APIs or higher level APIs are desirable of course, but they tend to be much bigger in size and scope, much more opinionated and brittle than a smaller low level API. A portable API which browser makers can accurately implement and support for the long term, is a smarter goal even if it does expect devs to build a "nice" layer on top of it first.
In case of WebComponents it could have a small sane layer on top that wouldn't be too large. See WebComponents vs Polymer: [1]
As it stands now, it's nigh unusable by developers. Almost no frameworks even use it as their foundation. And those that do compile to them go out of their way to never ever use it anywhere except in base classes, maybe: [2]
As a result, today, 9 years (!!!) after they were first proposed, the very person who proposed them relegates them to "webcomponents will be used incidentally not totally" [3]
You can't just say "React" though, you have to show how it actually integrates with the DOM that we have. "Throw away the DOM we have" isn't a realistic option either.
Compilers are better at eliding array index checks than about eliding numeric overflow checks; an ordinary function that operates on arrays will often be able to reasonably determine both the length of the array and the scope of the indexing variable (Rust's iterators are very good at this), whereas an ordinary math function often has almost no information that usefully limits which values it might be getting called with.
I don't disagree that making more obvious errors into panics would be nice, but the performance implications are often quite unforgiving.
They aren't unforgiving, because if you need performance you can use another function that does not do the check. Same as for arrays.
It seems strange to have a cast as a safe operation and yet return results that are almost surely a bug. This means I will avoid casts altogether in my code, and I do hope they get rid of them at some point as some have suggested.
> They aren't unforgiving, because if you need performance you can use another function that does not do the check
Rust tries hard not to cause regressions in users without good cause, which includes avoiding runtime performance regressions. One of the reasons that this fix took so long was that benchmarking prospective solutions revealed unacceptable performance regressions in users, even those who were already "doing the right thing" by manually upholding the proper invariants (no NaN, and value within range). The tension is that something still needed to be done, because at the end of the day the Rust creed is still "no undefined behavior without `unsafe`".
> This means I will avoid casts altogether in my code
Indeed, this is hardly discouraged wherever possible. For converting, say, a u64 to a u8, use `foo.try_into()` in order to get a conversion that follows the usual Rust conventions around Result-based error-handling (which didn't exist back when `as` was first conceived, or when this bug was originally filed). Casting floating point types to integers is already a rather rare use case in the first place.
For consistency you would also expect `257u32 as u8` to panic (which it doesn't, and never has); the `as` operator has always been about fast-and-lossy conversions, with the standard library ideally providing methods for more principled conversions.
Well EVE is written in C++ with Stackless Python embedded so as you might expect parts like the renderer were already written in C++ but plenty of core systems have been rewritten over the years from Python to C++ although that those have been pretty herculean efforts of some very smart people.
Swift, Rust nor Go provide support for exotic targets. If you want code to work in actually "weird architectures and little known operating systems", then your only option is C (or weird dialects of "C" in some cases).
At least that was how things were around >10 years ago, not sure about the current state of things. Anyone can chime in? Do embedded vendors etc. provide proper forks of newish, modern compilers?
Even excluding extremely exotic targets, the list of platforms supported by Rust and Go is vastly larger than Swift. For instance, there's no official support on FreeBSD, and FreeBSD 1. uses LLVM for everything 2. has a userland really similar to Darwin, so there are very few excuses to not allocate even a small amount of man power to port it.
If you add third-party ports and implementations, the list of platforms supported by Go and Rust increases exponentially; see for instance Tiny Go and the ongoing port of Rust to the Xtensa-based ESP32.
> Anyone can chime in?
I work in embedded and as far as my experience goes nowadays unless you go on extremely limited environments, the embedded chips I mostly see or develop for are either ARM (v7, like stuff from Nordic or the STM), or ESP32 (Xtensa). Every once in a while I have to work on some older projects which were based on Atmel or PIC, or very very very rarely MIPS.
It's certainly not like it was before; nowadays you can buy chips like the ESP32-WROVER which have relatively lots of RAM and storage for an absurdly cheap price. They run pretty well even if you opt for using C++17 and complex libraries.
Vulkan is not hardware-specific, it is an open, cross platform standard like OpenGL.
Direct3D is not standard, but it is so well supported and used (even in Linux!) that you can consider it one.