Comment by syrusakbary | Hacker News Reader

Comment by syrusakbary | Hacker News Reader

This is great. They mentioned a few months ago their will to open-source it [1] and now it's finally a reality, so props to Kenton and the Workers team on achieving it!

I've dug a bit on the OSS repo [2], and here are some of the findings I got:

    1. They are using a forked version of V8 with very small/clean set of changes (the diff with the changes is really minimal. Not sure if this makes sense, but it might be interesting to see if changes could be added upstream)
    2. It's coded mainly in C++, with Bazel for the builds and a mix between CapNProto and Protocol Buffers for schema
    3. They worked deeply the Developer Experience, so as developer you can start using `workerd` with pre-build binaries via NPM/NPX  (`npx workerd`). Still a few rough edges around but things are looking promising [3].
    4. I couldn't find the implementation anywhere of the KV store. Is it possible to use it? How it will work?

Open sourcing the engine, mixed with their recent announcement on a $1.25B investment fund for startups built on workers [4] I think will propel a lot the Wasm ecosystem... which I'm quite excited about!

[1] https://twitter.com/KentonVarda/status/1523666343412654081

[2] https://github.com/cloudflare/workerd

[3] https://www.npmjs.com/package/workerd

[4] https://blog.cloudflare.com/workers-launchpad/

Thanks! Some notes on your notes:

1. We float a couple patches on V8 but we keep it very up-to-date. Generally by the time a version of V8 hits Chrome Stable, we're already using it. I would indeed like to upstream the patches, which should be easier now that everything is open.

2. FWIW the one protobuf file in the repo is from Jaeger, a third-party tracing framework. We actually aim to factor that out into something more generalized, which may eliminate the protobuf dependency. Workerd is very much based on Cap'n Proto for most things (and the Workers team does most of the maintenance of Cap'n Proto itself these days).

3. Yep, one of our main goals was to bake this into our `wrangler` CLI tooling to make local testing easier. I'd also like to ship distro packages once things are a bit more stable.

4. The code includes the ability to configure KV bindings, so you can run code based on Workers KV. But, the binding is a thin API wrapper over an HTTP GET/PUT protocol. You can in principle put whatever you want behind that, and we plan to provide an implementation that stores to disk soon. The actual Workers KV implementation wouldn't really be that interesting to release as it mostly just pushes data over to some commodity storage back-ends in a way that's specific to our network.

Also on point 4: The next version of Miniflare -- our local testing environment -- is based on workerd and will include implementations of those HTTP APIs behind KV and R2 for testing purposes, which the Wrangler CLI tool will hook up automatically. (In fact maybe it already does, that team has been working so fast lately that I haven't been able to keep up...)

`npx wrangler dev --experimental-local`!

Is there an ETA on Miniflare v3? Ran into a problem recently using overlapping keys with forward slashes as they were not sanitized properly: https://github.com/cloudflare/miniflare/issues/167

> ...(and the Workers team does most of the maintenance of Cap'n Proto itself these days).

A team on workerd? I'm sure there is a lot of work involved in running the massive Workers platform, but curiously enough, the workerd git repo itself has relatively few commits from other engs... just where is the team? ;)

I had to squash history on the first commit for a bunch of reasons, but there are 55 co-authors listed. :)

https://github.com/cloudflare/workerd/commit/a265d5c22bf2a6b...

(Meta: please don’t use indentation/preformatted text for lists; just make each list item a paragraph of its own. Even now they wrap, it’s still very disruptive, harder to read and feels more like a citation of some form, in this instance it took me a moment to decide this was your writing rather than something you were quoting.)

Just to clarify on point 4, directly from the link;

> Cloudflare is not providing any funding or making any funding decisions, and there is no guarantee that any particular company will receive funding through the program. All funding decisions will be made by the venture capital firms that participate in the program. Cloudflare is not a registered broker-dealer, investment adviser, or other similar intermediary.

So it’s not a fund. Cloudflare just has an agreement that a set of venture funds will set aside capital for companies that leverage workers and in return Cloudflare will provide deals / resources to said startups.

The reason I bring this up is because this is significantly less helpful to founders building on their platform than simply having a strategic fund of their own. The tl;dr on why is because it’s an additional hoop to jump through to get to an investment decision.

As a founder that has raised a significant amount of strategic capital and operates in the same space as CF Workers, if you want companies built on your platform funded, optimize for fast process. I worry the dealflow will actually work in the wrong direction here, with these firms simply telling startups, “we’ll give you some CF credits if you build stuff using workers — helps us hit our promised allocation with Cloudflare.” Which might be the intent, but running a strategic fund is probably more founder-friendly and may create better outcomes.

Reply on news.ycombinator.com