Live data from Hacker News

Fastly hires entire Wasmtime team from Mozilla

bytecodealliance.org

11–20 of 153 posts

Re: Fastly hires entire Wasmtime team from Mozilla

#11
post #8

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…

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

Re: Fastly hires entire Wasmtime team from Mozilla

#12

My money was on Cloudflare to have hired them wholesale. Regardless, congratulations to everyone involved! This deal has got me thinking... whether a right way to "lay-off" a supremely talented bunch is to actually see if other companies are willing to offer them jobs? Kind of how player transfers happen in Football (soccer). Either the team goes to the newer company wholesale or you help find your engineers suitable…

Well that sort of happens in organisations large enough to have 'reorganisations' - which is effectively 'selling' teams (or parts of them) to internal 'buyers', or not finding a 'buyer' and letting them go.

Re: Fastly hires entire Wasmtime team from Mozilla

#13
post #10
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…

Hm interesting idea... but - wasm has modules, "imports", and "exports" for I/O and host communication. The glue is one of the harder parts of the problem. - wasm bytecode is sandboxable with a simple MMU mapping. That's one reason it has structured control flow rather than goto. (And this is why you need a special algorithm to compile C gotos to wasm.) RISC V certainly doesn't limit itself like that. So I think this…

I don't completely understand your second point there, because I'm not necessarily talking about full-system emulation. Just userspace emulation. So, why can't RISC-V be a sandbox? It's just loading a normal ELF into a virtual memory.

The first point is news to me, but I suppose you can build anything you want in an open ISA too. It looks like each object is like a shared object with an import and export table that connects things together, so the host would have to have a "modern" variant of a dynamic loader. It sounds like it would be painful to support that without an established way of doing it, that is standardized. So, guess I agree.

Re: Fastly hires entire Wasmtime team from Mozilla

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

I wonder which leads to a faster emulated machine?

Re: Fastly hires entire Wasmtime team from Mozilla

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

Very interesting, and thanks.

> the running code is not even provided with a way to access itself.

You can do the same thing with some ELF post-processing. I have done this, and used it over several months now. It works just fine, even though there is nothing in the RISC-V standard that explicitly says this must be true.

I asked the GCC people and they consider it a bug if there's any data in the text-segment. So, at leas there is that. Maybe we can call it optional support? :)

Re: Fastly hires entire Wasmtime team from Mozilla

#17

My money was on Cloudflare to have hired them wholesale. Regardless, congratulations to everyone involved! This deal has got me thinking... whether a right way to "lay-off" a supremely talented bunch is to actually see if other companies are willing to offer them jobs? Kind of how player transfers happen in Football (soccer). Either the team goes to the newer company wholesale or you help find your engineers suitable…

In my experience, acqui-hires benefit the company far more than the employees who get moved to a different company. The first time I was acquihired, my compensation actually decreased because they kept my base salary and rewrote the bonus structure such that it was impossible to hit previous payouts. Meanwhile, my prior company received a large payment for the transfer of our team.

Ironically, the new company was paying new hires much more. I would have been better off quitting and getting re-hired.

It's better if the employees can negotiate their own way into a different company or companies. No sense in letting the previous company try to cash in on the team on their way out.

Re: Fastly hires entire Wasmtime team from Mozilla

#18

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…

There are at least two other organizations that contribute to the Bytecode Alliance, so I don't see how Fastly has overtaken the standard. Could you elaborate on that?

As for "personal bias," I think that's fair game considering the personal history between you and one of the members of BA. Wouldn't exactly be psyched to work with you either.

Re: Fastly hires entire Wasmtime team from Mozilla

#20

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…

Wasm offers a unique opportunity to invent and define a new ABI standard, one with (at least minimal) support for the concept of classes. How to make it popular is another question.
Post reply on HN