Live data from Hacker News

Fastly hires entire Wasmtime team from Mozilla

bytecodealliance.org

41–50 of 153 posts

Re: Fastly hires entire Wasmtime team from Mozilla

#41

Earlier quoted context omitted.

If you don't see any issue on a corporation having most of the control over a spec, then I guess there isn't anything I can say that will convince you. > the whole conversation on your end seems petty and toxic, at first glance That's a first! Can you expand on that? Thanks! https://github.com/WebAssembly/WASI/issues/3

I'm replying here as a total independant, because you asked for a response :) Honestly, a logo for a project is both a huge thing, and a massive timesink. Your responses read that you just want to take over choosing the logo ("I'm happy to take on the responsibility of organizing it."). Then you seem to want to make this a whole issue encapsulating the problems with wasm (I am of course just reading one issue, not th…

[deleted]

Re: Fastly hires entire Wasmtime team from Mozilla

#42

Earlier quoted context omitted.

If you don't see any issue on a corporation having most of the control over a spec, then I guess there isn't anything I can say that will convince you. > the whole conversation on your end seems petty and toxic, at first glance That's a first! Can you expand on that? Thanks! https://github.com/WebAssembly/WASI/issues/3

I'm replying here as a total independant, because you asked for a response :) Honestly, a logo for a project is both a huge thing, and a massive timesink. Your responses read that you just want to take over choosing the logo ("I'm happy to take on the responsibility of organizing it."). Then you seem to want to make this a whole issue encapsulating the problems with wasm (I am of course just reading one issue, not th…

Thanks for your response! Agreed that a logo is a not thing that should be taken lightly.

Priorities in open-source communities are weighted differently by different members of it. We do care about accessibility, and the current logo have serious readability issues that affect disproportionally people with low-vision.

IMHO a "welcoming" community should encourage improvements, rather than halting collaboration because it doesn't come from the main members.

Re: Fastly hires entire Wasmtime team from Mozilla

#43
post #21

I have mixed feelings about this. In one side, I'm happy that some of the people affected by the Mozilla layoffs have now secured a job. On the other side, now almost all the power of the WASI standard is concentrated into the Fastly corporation (with wider penetration thanks to the WASI integration in Rust). The main and only player of the Bytecode Alliance becomes Fastly as well (as Mozilla is out of the server-sid…

surely you have a better example of your gripe than closing a GH issue on the logo design... the whole conversation on your end seems petty and toxic, at first glance.

[deleted]

Re: Fastly hires entire Wasmtime team from Mozilla

#44
post #37
post #21

Earlier quoted context omitted.

surely you have a better example of your gripe than closing a GH issue on the logo design... the whole conversation on your end seems petty and toxic, at first glance.

Some context from that thread I find important (I’m a bystander not involved in any way): > We would need to work with a lawyer to determine the IP issues around this. It’s possible that just using the same policy as for the WebAssembly logo works, but I know that various organizations have grown more concerned about IP in this space since then. > This is in no small part because your company, Wasmer, attempted to re…

[deleted]

Re: Fastly hires entire Wasmtime team from Mozilla

#45

Earlier quoted context omitted.

I think WebAssembly still has a bright future, regardless of a corporation practically gaining control over a standard (there's always opportunity for more standards). Here's a nice comparison between WebAssembly and RISC-V, written by Heyang (from the Wasmer team) that fits perfectly on the topic: https://medium.com/@losfair/a-comparison-between-webassembly...

I wonder which leads to a faster emulated machine?

Assuming the same implementation effort & skill: WASM, hands down (disclaimer: I have significant RISC-V experience and am an stout advocate, but RISC-V is a poor replacement for WASM).

ADD: a few of the reasons:

- When JITing RISC-V you cannot tell which are the last use of registers without a very expensive whole-graph analysis. Without that, you will have to generate more code than necessary.

- WASM's representation is very close to what you want in the compiler. In particular, you can directly tell all incoming control-flow edges, which makes analysis much more precise, gives optimization opportunities you would otherwise miss. Recreating this information from a binary is either impossible (due to computed branches) or expensive both in terms of analysis and the guards you have to generate to protect your assumptions.

Re: Fastly hires entire Wasmtime team from Mozilla

#46
post #21

Earlier quoted context omitted.

surely you have a better example of your gripe than closing a GH issue on the logo design... the whole conversation on your end seems petty and toxic, at first glance.

If you don't see any issue on a corporation having most of the control over a spec, then I guess there isn't anything I can say that will convince you. > the whole conversation on your end seems petty and toxic, at first glance That's a first! Can you expand on that? Thanks! https://github.com/WebAssembly/WASI/issues/3

I didn't say anything like that, I was commenting on your commentary and not Fastly or the BA. That strawman you built up is an example of toxicity.

The pettiness is that this looks like a non-issue blown into a flamewar where the BA has every right not to accept contributions from yourself because of past actions taken by the business you founded. I thought it was fine for them to close the issue was out of scope/focus, it didn't need more attention or for you to project your own gripes onto it.

All told this thread left a very bad taste in my mouth with respect to Wasmer, while I have a lot of respect for the BA and Wasmtime teams and I'm very glad that they found a home at Fastly.

Re: Fastly hires entire Wasmtime team from Mozilla

#47
post #8

Earlier quoted context omitted.

There's always RISC-V :) Nothing wrong with it, or anything preventing it to be just as fast. The only thing it doesn't have yet is a standardized vector-extension, but it's probably pretty close. We just need JIT support for an embeddable RISC-V emulator, and we're golden. Does it matter what the host language is these days server-side? I suppose there's a higher chance that the WebAssembly standard will adopt some…

I think WebAssembly still has a bright future, regardless of a corporation practically gaining control over a standard (there's always opportunity for more standards). Here's a nice comparison between WebAssembly and RISC-V, written by Heyang (from the Wasmer team) that fits perfectly on the topic: https://medium.com/@losfair/a-comparison-between-webassembly...

It's good, but a few issues:

- RISC-V is a large family of ISAs, though Unix platform targets a much narrower definition, the RV64GC. The "Feature table" lists FP and SIMD as "in extension" but doesn't do the same for Memory layout and protection. It's seems inconceivable to me that you would use paging in a WASM-replacement context. Same for instruction length, two-byte instruction depends on the "C" extension.

- There is nothing that prevents RISC-V in the browser from denying the ability to generate code on the fly. Just like, say iOS, it could run in a "W^X" model, that is, writable memory cannot be executed from.

- atomics, again, are part of an extension, the "A" extension. They do not have to be included, and do not make sense IMO in a single-threaded WASM replacement context.

All that said, WASM is well designed. The structured control flow is a bit painful for some producers and the lack of tail recursion elimination is criminal, but running running/JITting RISC-V in the browser would almost certainly add more overhead.

Re: Fastly hires entire Wasmtime team from Mozilla

#48

Earlier quoted context omitted.

I'm replying here as a total independant, because you asked for a response :) Honestly, a logo for a project is both a huge thing, and a massive timesink. Your responses read that you just want to take over choosing the logo ("I'm happy to take on the responsibility of organizing it."). Then you seem to want to make this a whole issue encapsulating the problems with wasm (I am of course just reading one issue, not th…

Thanks for your response! Agreed that a logo is a not thing that should be taken lightly. Priorities in open-source communities are weighted differently by different members of it. We do care about accessibility, and the current logo have serious readability issues that affect disproportionally people with low-vision. IMHO a "welcoming" community should encourage improvements, rather than halting collaboration becaus…

I agree improvements are good in generql, but logos are (in my experience) special. They can be a massive timesink, for big projects you have to get lawyers involved, and the arguments can suck up all the energy for months. Its also not something anyone can ignore, as once a logo is chosen you are stuck with it, generally.

If they are also rejecting good quality code, that's a whole other issue.

Re: Fastly hires entire Wasmtime team from Mozilla

#49
post #37
post #21

Earlier quoted context omitted.

surely you have a better example of your gripe than closing a GH issue on the logo design... the whole conversation on your end seems petty and toxic, at first glance.

Some context from that thread I find important (I’m a bystander not involved in any way): > We would need to work with a lawyer to determine the IP issues around this. It’s possible that just using the same policy as for the WebAssembly logo works, but I know that various organizations have grown more concerned about IP in this space since then. > This is in no small part because your company, Wasmer, attempted to re…

There is much more context to the "personal bias" statement than what is provided in the thread.

But 100% agreed, it's essential to stay critical before making your mind on a given thing.

Post reply on HN