> you can both look as native as the other, doesn't the actual UX matter more than how the implementation was made?
An Electron app that draws all its components mostly like the native controls will still not be native and have the same integrations etc. that native apps usually get.
You could get close but some things like for example "ctrl+f" search have native widgets that work different/look different that an electron app realistically won't have. Or for example you will never get the same liquid glass materials that macOS uses in an electron app.
So yea, native in my books means using the platform native (UI) apis. On Ubuntu for examples thats GTK, on Windows its.... idk at this point, WinUI? and on KDE it would be Qt.
You can get all those things in a Rust application drawing with Cairo on macOS, but that isn't "native" according to you regardless, because it's using Cairo instead of AppKit/SwiftUI?
Again I don't understand the obsession with caring so deeply about the implementation, as long as the end results are the same, why it matters so much?
My point is practically you don't get the same results unless you use the native APIs the the platform provides.
Take my Liquid Glass for example, you simply won't be able to match the look in an electron app in practice.
Ofc if the result is the same it doesn't matter how, but in reality it's almost impossible to imitate the look and capabilities since it would require a Herculean effort to keep feature parity.
Right, but you could call native APIs from JavaScript or Java say, then in your world that's a "native" application because it uses the APIs the platform provides, regardless of how it actually was implemented? Meanwhile, an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application because it doesn't look like one? Like games written with Vulkan/OpenGL aren't "as native" as one using Metal I'd presume?
you could call native APIs from JavaScript or Java say, then in your world that's a "native" application because it uses the APIs the platform provides
Yes, this is what we want.
an application could be implemented with Objective-C and/or Swift but not use Cacoa/AppKit/SwiftUI APIs, then that's not an native application
Correct. The toolkit matters, not the language. Native toolkits have very rich and subtle behavior that cannot be properly emulated. They also have a lot of features (someone mentioned input methods and accessibility) that wrappers or wannabe toolkits often lack. To get somewhat back on topic I notice and appreciate that Xilem mentions accessibility.
games written with Vulkan/OpenGL aren't "as native"...
Games are usually fullscreen and look nothing like desktop apps anyway so it doesn't matter what API they use.
You can technically get those platform native things by integrating with the native APIs. There's basically a full spectrum from "native" to "custom" rather than it being either-or.
> They're going to try to gradually push laws to make it so that you'll need a government issued signature to do anything. That's when they'll have total power over you because they can simply refuse to issue.
The more this signature is necessary the harder it becomes to deny issueing it to somebody.
I don't see how this changes much compared to nowadays. You can already require an ID for all kinds of these and the government already has total control over those. So what changes? China manages to ruin the lives of the people illegally born under the 1-child-policy for decades already, all without systems like eIDAS.
You can't protect yourself from authoritarian regimes with tech or good policy since those will just get ignored. Look at Trumps war with Iran, where did Congress agree to it?
I'm not a fan of these systems either, I also think software should be open and no vendor lock-in should exist. But I don't think this will change much to be honest.
It will matter a lot in the long run. I will outline one concrete way it will matter, which I think is the most critical, but there are other ways it will do damage besides this:
Right now, physical ID is only required for government services, for the most part. But digital signatures can be extended later to gate all services and purchases, both online and physical, including non-government ones. For example, you can't host a website without a gov approved signature for each website.
Under a system like that, you would rarely find out when the gov refuses to issue a signature, or when any kind of injustice happens, really. Websites where people can talk about bad things happening to them will simply be denied a signature to legally operate, so they're given the ultimatum to "voluntarily" censor posts, or be shut down. It becomes impossible to have this very conversation on a public platform with any kind of meaningful reach. And they already have this kind of system in China, since you brought it up. In fact, they have domestic surveillance systems that make the Snowden disclosures look cute.
The quote of Bjarne is a bit out of context. It was made after an hour long talk about the pitfalls and problems of contracts in c++26: https://youtu.be/tzXu5KZGMJk
The title is misleading. It says in one of the first sentences:
> The comments within do not represent “the Rust project’s view” but rather the views of the individuals who made them. The Rust project does not, at present, have a coherent view or position around the usage of AI tools; this document is one step towards hopefully forming one.
So calling this "Rust Project Perspectives on AI" is not quite right.
I very much agree with that, I had the same thought a few days ago.
I feel/am way more productive using chatgpt codex and it especially helps me getting stuff done I didn't want to get started with before. But the amount of literal slop where people post about their new vim plugin that's entirely vibecoded without any in-depth thinking about the problem domain etc. is a horrible trend.
All he is saying: We currently have products in a similar product category (arm based desktop computers) that are widely used and have known benchmark scores (and general reviews) and it would make sense if I publish a new cpu for the same product category ("Reaching Desktop Performance" implies that) that I'd compare it to the known alternatives.
In the end you can just run Asahi on your macbook, the OS is not that relevant here. A comparison to macbooks running Asahi Linux would be fine.
> But why would an article address _their_ specific usecase?
amelius, if anyone had specific requirements, it was you with your "systems for in-flight entertainment".
OP asked a very reasonable question for a very generic comparison to the 800-pound gorilla in the consumer CPU world in general, and ARM CPU world in particular.
If the article can reference AMD's Zen 5 cores and Intel's Lion/Sunny Cove, they could have made at least a brief reference to M-series CPUs. As a reader and potential buyer of any of them, I find it would have been a very useful comparison.
Talk about specifics, eh? Didn't you just argue against an article addressing "_their_" specific usecase?
In a store people will ask "is this better than an Apple?".
And I'll tell you one more thing, when I was in the industry and taking computing parts to build products with them I did not form an opinion by reading internet reviews. I haven't met anyone who did.
An Electron app that draws all its components mostly like the native controls will still not be native and have the same integrations etc. that native apps usually get.
You could get close but some things like for example "ctrl+f" search have native widgets that work different/look different that an electron app realistically won't have. Or for example you will never get the same liquid glass materials that macOS uses in an electron app.
So yea, native in my books means using the platform native (UI) apis. On Ubuntu for examples thats GTK, on Windows its.... idk at this point, WinUI? and on KDE it would be Qt.
reply