[HN Gopher] Fastly hires entire Wasmtime team from Mozilla
___________________________________________________________________
Fastly hires entire Wasmtime team from Mozilla
Author : swyx
Score : 355 points
Date : 2020-10-26 16:06 UTC (6 hours ago)
(HTM) web link (bytecodealliance.org)
(TXT) w3m dump (bytecodealliance.org)
| ignoramous wrote:
| 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 roles elsewhere.
|
| One might argue there's no advantage to the company laying-off
| people, but they could save on the severance package, and
| frankly, two companies entering an understanding like this bodes
| well on other levels where someone could probably explore a
| "cross-company" job change with blessings of the employers on
| both sides of the table.
|
| Of course, things like salary negotiations take a hit for the
| candidate especially, but internal transfers to different teams /
| location in bigger companies already work this way. May be year-
| end reviews and code can be shared on a need-to-know basis
| between the companies with employee consent.
|
| In particular, such arrangements between smaller / crash-strapped
| companies and bigger / well-funded companies might work out for
| the good. Then again, you never want the bigger company to start
| poaching wholesale from the smaller one. May be there's a balance
| in here somewhere that can be worked out given enough time and
| data.
| OJFord wrote:
| 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.
| PragmaticPulp wrote:
| 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.
| marcinzm wrote:
| As I see it, there's no requirement for you to take the aqui-
| hire and it's on you to ensure you are fairly compensated (no
| one else). So take it, interview, get an outside offer and
| then quit. Or don't take it, get fired, interview and get an
| outside offer. An aqui-hire is an option and more options are
| always good as long as you remember that which option you
| take it solely up to you.
| tpxl wrote:
| In my opinion, the acquihire you went through was poorly
| implemented, and the pay reduction disrespectful.
| saghm wrote:
| I think their more general point still stands, though; why
| would you expect a company trying to "sell" their employees
| to negotiate in the employees' best interests rather than
| that of the company itself?
| maffydub wrote:
| I wouldn't... but I would expect the company trying to
| "buy" the employees to act at least partly in their
| interests - otherwise the new employees will soon become
| ex-employees!
| toyg wrote:
| That's why in football there are 3 parties to a transfer
| deal: the two clubs _and the player's agent_.
|
| In a regular company trying to sell a whole chunk of
| workers, that should probably be a union. Which is indeed
| what happens in many European countries when this sort of
| thing happens.
| 0xffff2 wrote:
| That's somewhat irrelevant without data on what percentage
| of acquihires are poorly implemented.
| marcinzm wrote:
| Most aquihires are "take it" or "you're all unemployed."
| Since some money > no money the aquihire is inherently a
| benefit to the employee. You still have the option of not
| taking it and being unemployed. Or taking it and then
| looking for a new job. But you have more options and more
| income than if it didn't happen.
| ocdtrekkie wrote:
| With the sports example... the company "laying off a team" may
| actually be able to expect a payment in exchange for
| facilitating the transfer of their well-assembled, functional
| team to another company. It's entirely possible that wouldn't
| actually be a bad outcome for everyone involved:
|
| - Source company which is financially strained gets some income
| in addition to reduced salary expenses.
|
| - Destination company saves on paying other recruiting costs
| and acquires a pre-assembled team. They're essentially buying a
| working unit instead of having to build their own.
|
| - Employees avoid the uncertainty of being dropped in the
| middle of the process (or summarily laid off), assuming the
| right protections were in place in the agreement.
| temp667 wrote:
| This is the acquihire model. You don't actually have to do the
| acquihire.
|
| A company could just offer folks jobs directly (CA frowns on
| companies working to block employee mobility given employers
| can also fire folks with basically no notice). But it smooths
| things to wrap it up in an acquihire.
|
| Startups often get offers like this.
|
| Wasn't there a recent case on HN where google or apple after
| the company rejected the aquihire just offered the positions to
| staff directly? I think they got sued?
| ignoramous wrote:
| Acquihire was not quite what I was getting at...but more
| along the lines of companies cooperating to facilitate quasi-
| free movement of their employees under appropriate conditions
| especially when it benefits all or the majority of the
| stakeholders involved, even when it is a single lone
| employee.
| qgrgergfqgfev wrote:
| I don't think cloudflare does WASM @ edge no?
| detaro wrote:
| They do. Their Workers product supports JS and WASM (but they
| seem to be less active when it comes to spec development
| around it etc)
| Tehnix wrote:
| Contrary to most comments so far apparently, I'm just happy to
| see any WASM projects secure corporate backing. I think Ferrous
| System wrote about it nicely[0], but having people full-time on
| projects like this has a tremendous positive impact.
|
| Congratulations to the whole Wasmtime team! :)
|
| [0]: https://ferrous-systems.com/blog/knurling-one-month/
| mwcampbell wrote:
| > Serverless on Fastly's Edge, powered by Lucet
|
| Looks like that product is in private beta. It'll be interesting
| to compare and contrast it with Cloudflare Workers. In any case,
| I'm glad there's going to be some competition in that space.
| [deleted]
| syrusakbary wrote:
| 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-side Wasm game).
|
| So... how this could be bad? The Bytecode Alliance has been
| biased since their inception, blocking any attempt of
| collaboration from Wasmer based on personal bias (I work at
| Wasmer) and other external entities out of their control [1] [2]
| [3]. This move is conceding them now a full-control over a
| standard such as WASI, placing the whole standard at risk [4]
|
| [1] https://twitter.com/syrusakbary/status/1202351432050954240
| [2]
| https://github.com/WebAssembly/WASI/issues/3#issuecomment-71...
| [3] https://twitter.com/cjihrig/status/1320763509463015425 [4]
| https://twitter.com/cjihrig/status/1320761713365581824
| fwsgonzo wrote:
| 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 instructions that favor
| cloud computation now, with these news.
| chubot wrote:
| 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 idea is glossing over a lot of details... not
| all ISAs are equal, especially ones meant to be transmitted
| over the network!
| fwsgonzo wrote:
| 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.
| whizzter wrote:
| Had an idea of trying to "script" things for games, the
| idea was to use a the WASM backend of a regular C/C++
| compiler to generate code that could be loaded
| dynamically and share structures (ignoring sandbox for
| this) so that testing could be done seamlessly, sadly
| WASM seems to be 32bit for the time being (atleast for
| Clang, dunno about GCC but that has other issues), also
| looked at Risc-V and missing export/import tables looks
| like it could make things far more complicated (might
| still try using Risc-V though since i'm thinking of
| generating syscall tables automatically along with Elf-
| loading)
| fwsgonzo wrote:
| Sounds awesome. I have some abstractions for making
| interfacing easier, but I don't have any auto-generated
| structures.
|
| https://github.com/fwsGonzo/rvscript
|
| I have done that here. Example:
| APICALL(api_math_smoothstep) { auto
| [edge0, edge1, x] = machine.sysargs <float, float, float>
| (); x = std::clamp((x - edge0) / (edge1 -
| edge0), 0.0f, 1.0f);
| machine.cpu.registers().getfl(10).set_float(x * x * (3 -
| 2 * x)); return 0; }
|
| "machine" is an argument to each system call handler, so
| you can have multiple machines for many purposes. For
| example, I suspect you can use a machine as a savegame -
| because they are serializable.
| chubot wrote:
| The wasm paper covers these issues, and is short and
| pretty readable:
|
| https://scholar.google.com/scholar?cluster=14979605902538
| 775...
|
| tl;dr security introduces a lot of design constraints
| that RISC V doesn't have.
|
| section 2.3 on structured control flow:
|
| _WebAssembly represents control flow differently from
| most stack machines. It does not offer simple jumps but
| instead provides structured control flow constructs more
| akin to a programming language. This ensures by
| construction that control flow cannot form irreducible
| loops, contain branches to blocks with misaligned stack
| heights, or branch into the middle of a multi-byte
| instruction. These properties allow WebAssembly code to
| be validated in a single pass, compiled in a single pass,
| or even transformed to an SSA-form intermediate form in a
| single pass._
|
| Also, wasm is a "Harvard architecture" rather than von
| Neumann (separate address space for code and data), also
| for security reasons:
|
| section 2.2:
|
| _Linear memory is disjoint from code space, the
| execution stack, and the engine's data structures;
| therefore compiled programs cannot corrupt their
| execution environment, jump to arbitrary locations, or
| perform other undefined behavior. At worst, a buggy or
| exploited WebAssembly program can make a mess of the data
| in its own memory._
|
| However, wasm also leaves some things to be desired
| security wise. Buffer overflows in C are still buffer
| overflows once you compile to wasm, and can be chained in
| to JS exploits.
|
| https://old.reddit.com/r/ProgrammingLanguages/comments/ic
| b9v...
|
| If you try to use RISC V in the same contexts, you'll
| have the same problems. If you have an additional layer
| of process sandboxing, then those could be mitigated. But
| then RISC V is not a wasm replacement.
|
| Although maybe wasm is hopeless for C code, so you need
| more sandboxing anyway, so then it's on par with RISC
| V... interesting question.
| fwsgonzo wrote:
| You don't have to have the executable code in-memory for
| RISC-V emulation.
| syrusakbary wrote:
| 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...
| jhallenworld wrote:
| I wonder which leads to a faster emulated machine?
| FullyFunctional wrote:
| 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.
| fwsgonzo wrote:
| 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? :)
| FullyFunctional wrote:
| 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.
| mbStavola wrote:
| 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.
| singularity2001 wrote:
| 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.
| qppo wrote:
| 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]
| oefrha wrote:
| 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 register "WebAssembly" and "Wasm" as trademarks.
| The USPTO rejected the application, but I don't think we can
| assume that attempts to register a brandmark for a WASI logo
| would be similarly rejected.
|
| This doesn't seem to be a he said she said situation; gp had
| the chance to defend himself and all he could come up was a
| very weak "The trademark requests were driven by our lawyers"
| (and what came after that was even more shameless if you ask
| me): https://github.com/WebAssembly/WASI/issues/3#issuecommen
| t-71...
|
| Given that context, I'd say the gp comment (especially the
| "personal bias" part) is likely motivated smearing.
|
| Bottom line: don't make up your mind just because it's the
| top comment of an HN thread, or because the
| discrimination/racism card is played (racism card isn't
| played here, it's in the linked GH issue). If you want to
| form an opinion, read the other side first.
| syrusakbary wrote:
| 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.
| oefrha wrote:
| If there's more context you're certainly not
| communicating it very well and all we see is some company
| attempting to trademark something they neither invented
| nor owned and crying discrimination with little to no
| supporting evidence.
|
| Also, did you delete your downvoted comment then post the
| same thing in a new one? I saw your comment posted a
| while ago, in the gray, then when I refreshed before
| responding, bam, "0 minutes ago". That's not cool.
| syrusakbary wrote:
| No doubt. It clearly seems that I'm not communicating
| well enough. But just to be clear: is not in Wasmer
| intent to own the Wasm trademarks (as stated in the
| Github issue).
|
| And to answer your question: yes, I deleted the comment
| because I thought it was going to start a non-productive
| discussion (it had 1 point at the moment of deletion).
| Then I realized deleting could provoke some other issues,
| and decided to repost again.
|
| Yeah, I know bunch of BA people will downvote my
| comments... and it's ok!
| [deleted]
| [deleted]
| syrusakbary wrote:
| 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
| CJefferson wrote:
| 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 the many
| related problems)
| [deleted]
| syrusakbary wrote:
| 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.
| morty_s wrote:
| >people with low-vision.
|
| What does this mean? How does this relate to current
| logo? Is this a color blindness issue?
| syrusakbary wrote:
| There is a color accessibility with the current logo.
|
| I've explained it here:
| https://speakerdeck.com/syrusakbary/wasi-logo-proposal
| [deleted]
| marcinzm wrote:
| They stated that a proper logo process would require too
| much of their time to devote to right now and they don't
| want a half-assed process. Also, to your proposal to
| manage the process, they clearly don't trust you after
| your company tried that trademark BS. So from their point
| of view anything you're involved with would actually
| require even more of their attention due to potential
| legal liability.
|
| So it's not about not being a main member but rather
| about being basically seen as a bad actor to the
| community. Actions have consequences and the consequence
| for the trademark BS is being seen as an enemy of the
| community. The way to resolve that is to not annoy them
| about things while being as helpful as possible. Your
| comments on Github definitely are not that (they're
| adversarial, clearly annoy them with something they don't
| want to deal with, etc.) which simply cements their view
| of you being a bad actor.
| CJefferson wrote:
| 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.
| qppo wrote:
| 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.
| [deleted]
| aarchi wrote:
| It's good to see Wasm development continuing outside of Mozilla,
| but it's a shame that Mozilla seems to be going under.
| syrusakbary wrote:
| Yeah, it's now clear that Mozilla focus on Wasm is only on the
| client-side for the browser.
|
| It seems most of the Mozilla people working on Cranelift are no
| longer employed to work on it.
| simlevesque wrote:
| Fastly have a great product. I've always liked their support too:
| when you need to have access to low level APIs like pure VCL you
| juste have to ask and they provide it, it is deeply powerful.
|
| I think they can make a great impact with these hires.
| batter wrote:
| I will stay pessimistic here. Wiring VCLs is painful and very
| limited. But writing Rust takes CDN support to completely
| different level. Even if they will introduce other languages i
| don't understand why anyone would rely on Fastly to run their
| software. Especially once you realize you need some storage and
| it will Fastly again.
| vmchale wrote:
| Cranelift coming along is exciting!
| [deleted]
| qgrgergfqgfev wrote:
| Holy moly! This is pretty amazing. I was playing with terrarium
| the other day and it looks pretty cool
| https://wasm.fastlylabs.com/
___________________________________________________________________
(page generated 2020-10-26 23:00 UTC)