jrvidal's comments

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.

As other top-level comment indicates, this is debatable: https://github.com/xorvoid/meson-brainfuck/issues/1

I kinda recall some comments by pcwalton about APIs that would ameliorate context-switching costs at the kernel level:

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

I see, it seems we misread each other.

> The "working group" is some people on Discord

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?).

hi HN, there's a companion technical post by yours truly which might be more appropriate/technically dense for your taste:

https://blog.stackblitz.com/posts/supporting-firefox/

(I'm also sad that Multi-Account Containers are not a thing in Firefox for Android).

Disclaimer: I (obviously) work for StackBlitz.

Stackblitz | Full-time | REMOTE, US, EU timezones | https://stackblitz.com/careers

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.

* Software Engineer (TypeScript, Node.js, WebAssembly, Rust): https://jobs.lever.co/stackblitz/7ccd2472-1416-4448-8642-e58...

We hire in the US and EU timezones.

Stackblitz | Full-time | REMOTE, US, EU timezones | https://stackblitz.com/careers

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.

* DevSecOps Engineer: https://jobs.lever.co/stackblitz/b22a0763-95cc-4c18-9c03-6a1...

* Frontend Engineer (TypeScript, React): https://jobs.lever.co/stackblitz/70ef26ea-cb9d-4184-9f2c-485...

* Software Engineer (TypeScript, Node.js, WebAssembly, Rust): https://jobs.lever.co/stackblitz/7ccd2472-1416-4448-8642-e58...

We hire in the US and EU timezones.

Stackblitz | Full-time | REMOTE, US, EU timezones | https://stackblitz.com/careers

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.

* DevSecOps Engineer: https://jobs.lever.co/stackblitz/b22a0763-95cc-4c18-9c03-6a1...

* Core Experience JavaScript Engineer: https://jobs.lever.co/stackblitz/70ef26ea-cb9d-4184-9f2c-485...

* Product Marketing: https://jobs.lever.co/stackblitz/fcdf5e06-51fb-43cc-ba98-cab...

We hire in the US and EU timezones.

Stackblitz | Full-time | REMOTE, US, EU timezones | https://stackblitz.com/careers

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.

* Rails Engineer: https://jobs.lever.co/stackblitz/26053a78-242e-400b-aa09-c0e...

* Product Marketing: https://jobs.lever.co/stackblitz/fcdf5e06-51fb-43cc-ba98-cab...

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!

I replied in a sibling, but anyways: I mean, I can also see that _on paper_, but by the same reasoning, MS would have never thrown away their engine.

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.

Can you elaborate on what makes you think that? (I'd love it to happen, btw)

Pardon my ignorance, but is prop drilling a problem once you've bought into Redux or similar?

> 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.

Shameless plug: https://jrvidal.github.io/aes-demo/

I like this one better though.