I think we're mixing 2 things here: language backward-compatibility, vs. standard practices about what semver means for Rust libraries. The former is way stronger than the latter.
> language backward-compatibility, vs. standard practices about what semver means
I've read and re-read this several times now and for the life of me I can't understand the hair you're trying to split here. The only reason to do semantic versioning is compatibility...
I assume that they mean that you can use Rust as a language without its standard library. This matters here since the Kernel does not use Rust's standard library as far as I know (only the core module).
I'm not aware of semver breakage in the language.
Another important aspect is that Semver is a social contract, not a mechanical guarantee. The Semver spec dedicates a lot of place to clarify that it's about documented APIs and behaviors, not all visible behavior. Rust has a page where it documents its guarantees for libraries [0].
The failure mentioned above wasnt a case of the language changing behaviour, but rather the addition of a trait impl in the standard library conflicting with a trait impl in a third party crate, causing the build breakage.
The Rust compiler/language has no notion of semver. Saying "Rust is unstable b/c semver blah blah" is a tad imprecise. Semver only matters in the context of judging API changes of a certain library (crate).
> The only reason to do semantic versioning is compatibility
Sure. But "compatibility" needs to be defined precisely. The definition used by the Rust crate ecosystem might be slightly looser than others, but I think it's disingenuous to pretend that other ecosystems don't have footnotes on what "breaking change" means.
> But "compatibility" needs to be defined precisely.
Compatibility is defined precisely! You're definition requires scare quotes. You want to define it "Precisely" so that you can permit incompatible behavior. No one who cares about compatibility does that, it's just an excuse.
Look, other languages do this differently. Those of use using C99 booleans know we need to include a separate header to avoid colliding with the use of "bool" in pre-existing code, etc... And it sort of sucks, but it's a solved problem. I can build K&R code from 1979 on clang. Rust ignored the issue, steamrollered legacy code, and tried to sweep it under the rug with nonsense like this.
I think you are trying very hard to disagree on basic stuff that works very similarly across different language ecosystems, and (looking at other responses) that you're very angry. Disengaging.
I'll point out again that C, the poster child for ancient language technology, has been able to evolve its syntax and feature set with attention to not breaking legacy code. Excusing the lack of such attention via linguistic trickery about "defining compatibility precisely" does indeed kinda irk me. And disengaging doesn't win the argument.
The fundamental issue here is that any kind of inference can have issues on the edges. If you write code using fully qualified paths all the time, then this semver footgun can never occur.
I think the precise pre-condition is that the theory should be recursive, which means either a finite list of axioms _or_ a computable check to determine whether a given formula is an axiom.
Ah that Switchto thing looks really interesting. From my brief skimming it sounds like the actual biggest cost of context switching is not saving and restoring all the state, but deciding which thread to switch to.
The Switchto patch allows you to just tell Linux which thread to switch to, so it doesn't need to figure it out. Looks like they reduced the costs by ~20x. I wonder why it was never merged.
I guess my intuition was right then. I mean, async is still useful for WASM and microcontrollers, but for "I need to support 10000000 concurrent connections" (which is the usual motivation), it's a hack around poor OS APIs.
> Firefox has added support for some webdriver APIs[1] that this proprietary "WebContainers" product depends on
Hi, WebContainers does not depend on WebDriver BiDi. We did mention our interest in this new standard getting more momentum in other blog post (which might be the source of your statement?).
> We did mention our interest in this new standard getting more momentum
You keep calling it a standard.
The "working group" is some people on Discord. Your blog post calls it "our in-browser operating system" which is a far cry from a standard. You "team up with browser vendors directly", yet not through web standards bodies, but through some "bytecode alliance" that aims to build outside the browser. Also, unsurpisingly, zero links anywhere to an actual standards text or even to a specification of these web containers.
Fair enough, we should correct our mention of WebDriver BiDi to "tentative standard". BTW, not sure if you hold some grudge against WebDriver BiDi in particular, we were merely saying "gee, I sure hope something better than WebDriver comes along, b/c E2E testing kinda sucks".
> Your blog post calls it "our in-browser operating system" which is a far cry from a standard. You "team up with browser vendors directly", yet not through web standards bodies, but through some "bytecode alliance" that aims to build outside the browser. Also, unsurpisingly, zero links anywhere to an actual standards text or even to a specification of these web containers.
I am not sure what your objection is. We have a product, we're describing our efforts to port it to a new browser engine.
The underlying technologies and the tooling that you've been building on top of it are great. I was merely pointing out the confusing or perhaps misleading writing style of this announcement.
We're building the fastest, most secure IDE on the planet! We recently announced WebContainer (https://blog.stackblitz.com/posts/introducing-webcontainers/), an in-browser Node.js runtime that allows front-end developers to _use_ the web to _build_ the web. We have a very ambitious roadmap and we'll be aggressively hiring in the upcoming months.
We're building the fastest, most secure IDE on the planet! We recently announced WebContainer (https://blog.stackblitz.com/posts/introducing-webcontainers/), an in-browser Node.js runtime that allows front-end developers to use the web to build the web. We have a very ambitious roadmap and we're looking to hire multiple positions.
We're building the fastest, most secure IDE on the planet! We recently announced WebContainer (https://blog.stackblitz.com/posts/introducing-webcontainers/), an in-browser Node.js runtime that allows front-end developers to use the web to build the web. We have a very ambitious roadmap and we're looking to hire multiple positions.
We're building the fastest, most secure IDE on the planet! We recently announced WebContainers (https://blog.stackblitz.com/posts/introducing-webcontainers/), an in-browser Node.js runtime that allows front-end developers to use the web to build the web. We have a very ambitious roadmap and we're looking to hire multiple positions.
We're (obviously!) also looking for front-end engineers. We have an unconventional mixture of needs here: we're building a world-class IDE that needs strong UX chops, but we're also neck-deep in "low level" code (think JS runtimes, POSIX shenanigans, WebAssembly ports of native libs, etc.).[*] If that sounds right up your alley, hit us at recruiting@stackblitz.com.
We hire in the US and EU timezones.
[*] Usual disclaimer: you don't need to be an expert in all those domains!
