I really don't see why you'd disable WebAssembly and allow JavaScript instead. Expecting developers to make a fallback for a baseline-supported feature for any reason but backwards compatibility with runtimes that do not so support WASM is extremely silly.
I also have JS disabled in Firefox on my phone. It's on by default on my laptop, as I apparently visit different sites when my butt is planted in a chair.
My wish is actually for the days of NPAPI where Webassembly would be just another plugin (like Flash) and browsers clung to mainly HTML, JS, and CSS. Then developers wouldn't be quite so keen to rely on it and the web would be much less bloated. Yes, those days are long gone... As a tradeoff, I'd settle for a simple toolbar icon that lit up when Webassembly is running, and/or a high level UI (just like Location, Camera, and Microphone) so I can enable it for just those sites that need it. I tried selling Mozilla on the idea once but they apparently weren't interested.
Baselines aren't entirely universal. I remember the days when the Mozilla (or early Firefox) browser was the only viable web client for Linux, but some sites still opted to run behind ActiveX. Today I don't think you'll find a Haiku or Amiga browser with Webassembly support, nor Firefox for Linux on IBM Power motherboards. It's easy to forget that just because most any 'nix or BSD OS has a plethora of choices, that others aren't still dealing with the "ActiveX" situation and feeling like everybody's out to get them.
1Password can't even include ARM builds of their app in their existing packages [1]. I am highly skeptical of anything DHH (David Heinemeier Hansson) is the benevolent dictator of, and for good reason [2]. Perhaps that money would be spent better elsewhere in the ecosystem.
Far from it, EU law would need to be transposed in some very specific areas covered by the agreement, and mechanisms are in place to limit what retorsions can be put in place if Switzerland refuses such transposition.
You clearly have no idea how the EU works; she is the head of the Commission, which is nominated by the Council (27 elected heads of state), and needs to be approved in by the Parliament (directly elected). So sure, yeah, she isn't directly elected, but she still needs a massive amount of multinational political support.
Even then, all the power is in the Commission; the Commission is split in areas (competition, energy, trade, etc.), and each country nominates a commissioner in each area, and the total Commission gets approved once again by democratically elected Parliament. The head of the Commission has only one single vote, and a majority vote decides if anything passes, and even the Parliament has to approve it. That said, I think we all want Parliament to have the ability to propose legislation.
So don't take this ignorant take in here and present it as some kind of dictatorship and a fundamental flaw of the EU that undermines it all; the EU has been a massive positive force for the continent, and people like you just like to shit on it.
What do you call a state with an unelected president? This role has come about with no citizens in the EU being asked to approve it or vote for it. Being selected by a handful of bureaucrats is a creepy technocracy with zero pretensions for being a functioning democracy. Foolishness to see it any other way.
It highly depends. Everything from "monarchy" to "indirect democracy".
Even the Americans don't elect their president directly, they have a special council inbetween to distribute more power to the sparsely populated states.
Russia is a direct democracy (the people do directly elect their leader) but also the example of why technicalities like that make no difference in how fair politics are.
Who, in Europe, even knew they were getting a de facto president who they could not choose? This is meant to be a rationalised organisation with lofty egalitarian ideals, and yet it has to struggle to compete against descents into chaos and corruption in USA and Russia.
The Euro is actually one of the reasons they want to join; even their prime minister stated it explicitly. It would be a more stable currency than their own.
It really should be required for manufacturers to publish full details about how the hardware works so that alternative software can be developed. I'd wholly support that.
Apple, for instance, does not provide low level device documentation sufficient for creating open source drivers - for instance - publishing documentation on the Apple GPU and coprocessor would have reduced the development effort of the Asahi GPU driver by 90%.
If Apple was compelled to release low level documentation for their Apple Silicon hardware (audio, usb, gpu, power management, etc) - Linux would have been running on Apple hardware long ago.
There is plenty of gas in the EU; we decided that it was undesirable to extract. Honestly pathetic; strategic autonomy and energy security is much more important.
Yes. Strategically Europe keeps getting things wrong while, e.g., China keeps getting thingss right: they leverage their domestic coal reserves while going all in on nuclear and renewable, and they do it comprehensively with battery tech, solar panels tech, and EVs, too, as you can't lower dependency on foreign oil if all your cars run on petrol. But in fairness they didn't have the lobby of a powerful "legacy" auto industry (another textbook case of innovator's dilemma?)
It's been annoying to me as an end user that so many basic things require nightly. I use nightly as my main toolchain, but enabling unstable features makes a project nightly-only, which is undesired for crates that don't already revolve around the unstable feature.
I most often encounter unstable features when I reach for a basic common-sense utility method and discover that it's not stable. Like just earlier today I would have reached for bool::toggle which not only is unstable, but is also newly added as of like a month ago! but some unstable methods have been sitting around for years.
And now that IntelliJ-Rust is proprietary, I can't even make a feature request anymore for the ability to exclude unstable features from the autocomplete. So they will taunt me forever, perfect little helpers just locked away.
> It's been annoying to me as an end user that so many basic things require nightly
It used to be the case a decade ago, but now I wouldn't agree that any "basic" things require nightly (I wouldn't call portable SIMD "basic" at all for instance).
> Like just earlier today I would have reached for bool::toggle which not only is unstable, but is also newly added as of like a month ago!
This is very likely not the kind of feature that will stay on nightly for a long time, but is instead one of the many convenience feature that land on stable every release. The 6-weeks release cadence with beta in between means there's always at least 6 weeks and up to 3 months between the time a feature land on nightly and the day it reaches stable, even if the feature is as consensual as this one.
> And now that IntelliJ-Rust is proprietary, I can't even make a feature request anymore for the ability to exclude unstable features from the autocomplete.
Can't you tell it to use stable as the default target, and use nightly manually in cargo?
> This is very likely not the kind of feature that will stay on nightly for a long time, but is instead one of the many convenience feature that land on stable every release.
Easy example of a basic method that has been unstable for a really long time: [T]::as_slice [0] since 2024 [1]. Apparently, stabilization was attempted earlier this year [2] but was then rolled back [3]. While clearly it was not yet ready for stabilization, it still took over a year before the first attempt.
Another one: Option::zip_with [4] since 2020 because nobody's figured out if it's worth having over .zip(...).map(...). Option::zip was actually stabilized [5] later in 2020 but Option::zip_with has since been sitting in limbo for over five years.
Another one: <*const [T]>::as_ptr also since 2020 [6]. I can't remember if there's an alternative now but dealing with slice pointers without relying on unstable methods has historically been very difficult/annoying. I ran into a bunch of this kinda stuff while working on a crate for iterating over rows/columns of image buffer subregions, because I wanted to use and support slice pointers. (Specifically I think getting the length of the slice pointer was nearly impossible without invoking UB, because constructing a reference (which was the only safe way to access a len method) could break aliasing rules. However I think the len method on slice pointers was stabilized a while ago so that particular problem is no more.) Speaking of which, <*mut [T]>::split_at_mut has been unstable since 2022 [7]...
I'm not saying there's no reason for any of this, just that as a Rust developer it's been frustrating. There are enough of these all over the place that it feels like a real occurring problem, even if it's not reasonable to expect a volunteer open-source project to pay full attention to everything ever.
> Are you saying it doesn't suggest unstable features when using a stable toolchain? That was not my experience before I started using nightly.
Oh really? I've never used any Jetbrain product so I don't know but if it's indeed the case even when you don't even use a nightly toolchain that sounds like a very bad design.
For these sort of things, I wish they would have some semi-stable beta or prerelease tracks other than just nightly so you could use the new features on a somewhat stable branch. If something is in nightly that is too crazy for a lot of projects to really try and exercise it because so much is changing constantly. Like a monthly or quarterly stabilization would be amazing, that may still have experimental features not making it into stable, but has a period of bugfixing w/o intentionally breaking changes to settle down.
Eh, it's hard to prove absence, and time is a beneficial quantity here. The longer something sits on nightly, the greater the chance that bugs are identified before it reaches stable and its usage significantly increases.
A lot of bugs with SIMD libraries are in the domain of interactions, not functionality--e.g. SIMD malfunctions on rare chips, chips with previously-unseen combinations of hardware/userspace firmware/microcode behavior, compilers run in weird harnesses that lie about hardware capabilities, and so on. I assume that's the case with Rust's portable SIMD as well.
If your QA is unpredictable individual use-cases (as with most OSS projects), then there's no way to measure "testing complete" or "coverage"; letting it bake for awhile is the best approach available.
That's what's trouble: git is reaching the end of its useful life.
It's 25 years old, and the patch files that make up the core of the decentralized collaboration system are fully 50 years old. Have the design requirements and constraints perhaps changed over the last 50 years?
1. Git breaks down if files are too large or lines within files are too large.
2. Add/Rename conflicts will always burn you because git does not protect the intent behind changes.
And really the third is that IDE's are shit because there's no document object model (like the browser has). You have to make an error recovering parser to try to deal with the fact that an IDE is editing code half the time and text half the time. You're stuck playing a game you can't possibly win. Can you imagine if the HTML DOM kept blinking into and out of existence? It'd be a nightmare...
reply