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.
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.
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.
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.
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.
> 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'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 [email protected].
We hire in the US and EU timezones.
[*] Usual disclaimer: you don't need to be an expert in all those domains!
As I said, I'd like that to happen, but I don't see MS being bothered by diverging priorities enough to fork after _throwing away_ a whole engine to avoid duplicating work. At least not in the medium term.
> The goal of every top-tier collider is new physics
I would argue that the goal of a top-tier collider is to go to new energy ranges, plain and simple. Absence of new phenomena is gained knowledge, albeit a bit boring, but still.