
I'm Joining CloudFlare - steveklabnik
https://words.steveklabnik.com/i-m-joining-cloudflare
======
tptacek
This is a genre of post that I've never really understood. Klabnik is great
and all, but, ok? Sure? Were people really record-scratching over his totally
reasonable decision to take a good-paying job at a big company?

It's obviously not just Klabnik. In fact, when we did Starfighter a few years
back, I think Patrick did one of these posts as well. But: like every other
post about Starfighter on HN while we were working on it, the whole thing was
pretty uncomfortable. It's an experience I'd prefer not to repeat.

There are lots of excellent people taking all sorts of jobs at all sorts of
places, and, unless those jobs involve, I don't know, mechanizing payday loans
to squeeze poor people or hacking the phones of people the government of
Bahrain doesn't like, nobody needs to justify them. Some of these posts seem
like they might be good examples of content actually better delivered in a
tweet.

It's possible that I just don't think Cloud Flare has earned the spotlight
Klabnik is giving here. Who knows. But I felt the same way when Yegge
announced his job at Grab --- just, "why am I reading this?" I'm sometimes
reminded of the way Anthony Bourdain described the trailing years of Mario
Batali's tenure at Food TV (Batali was a "lion" but not in a good way). Like:
did you want to write this, or did Cloud Flare reallllllly want you to write
this?

~~~
steveklabnik
It's cool man, not everything is for everyone.

> Were people really record-scratching over his totally reasonable decision to
> take a good-paying job at a big company?

I actually anticipated a few people being confused because of a few reasons.
It seems like, so far at least, nobody has actually been confused. It happens.
But I've experienced a lot of that previously; so like, moving from "writing
documentation" to "product manager" and "everything is MIT/Apache2.0 licensed"
to "a closed source platform" can look like big changes from the outside.

And really, I have wanted to write this bit about edge compute for a while,
this is just a good excuse to finally publish the piece. I've been talking to
CloudFlare for a few months, and it felt slightly odd to write it before I
told the world "hey I may have some bias here." Now that I've made my decision
and that bias is clear, that helps further discussion.

~~~
tptacek
Yeah just to be clear, you're simply at the leading edge of a phenomenon
that's been puzzling me for awhile, probably starting with that Yegge/Grab
piece (after which, from what I can tell, he was never heard from again).
Don't fade away!

~~~
steveklabnik
:) <3

Oh, one last bit I missed:

> Like: did you want to write this, or did Cloud Flare reallllllly want you to
> write this?

I brought up to them that I wanted to write a post about joining, and asked if
they wanted marketing to look it over or something. They said "no need, we'll
be happy with whatever you write."

I see it as a mutually beneficial thing, and always have, everywhere I've
worked.

~~~
foobarbazetc
Are you concerned at all how the Wireguard thing is playing out vs your desire
to see this stuff open sourced?

~~~
steveklabnik
I think it depends on which "Wireguard thing" you're talking about, there were
several semi-controversies.

If you mean "Warp doesn't support generic clients", I commented about that
over on the Reddit thread:
[https://old.reddit.com/r/programming/comments/b9sznr/im_join...](https://old.reddit.com/r/programming/comments/b9sznr/im_joining_cloudflare/ek6tp9w/?st=ju4db19o&sh=0bcb793e&context=4)

If you mean "CloudFlare pursued BoringTon outside of the general WireGuard
project", well, I don't have any real insight into the specifics of why that
was chosen, but it seems extremely open source to me. As far as I know,
BoringTon is just an implementation of a protocol. There's a ton of reasons to
want to do things on your own rather than work on upstream. And if anything,
for protocols, independent implementations can be a good thing, more than a
bad thing.

If you mean something else, well, I'm not sure, those are the only ones I can
remember :p

~~~
tptacek
Well, they took WireGuard, wrote a Rust implementation of it, refused to
collaborate with Jason, who's been trying to get a Rust implementation of his
protocol off the ground, then rolled it out as a proprietary offering that
WireGuard itself is not allowed to connect to. This seems like the sort of
analysis that would be pretty cut-and-dried among open source advocates (I'm
not one of those, so I'm not saying it's cut-and-dried for me).

Your previous rooting interest in this story would have been for Rust itself.
And Rust itself would have been been best served by having it host the
dominant sanctioned userland implementation of WireGuard, not merely as an
implementation detail for a commercial offering that also treats WireGuard as
yet another implementation detail. Rust? Important! WireGuard? Important!
Warp? Who gives a fuck?

So this is a bit of a surprising response to see from you.

 _Apologies for the late edit:_

I should lay my own cards on the table here.

First, it's not much of a secret that I'm no fan of big Flare. But just to be
clear: good friends of mine have worked there, and several other people I
deeply respect have as well, and I don't judge any of them for that.

Much more importantly: Jason Donenfeld is, to my mind, the hardest working
person in show business, and he's set himself on one of the most important
projects in network security, basically all on his own, and the momentum he's
managed to achieve doing that is insane and a little inspiring --- especially
given the amount of shade he's been repaid with by network security luminaries
--- and basically the last thing in the world he needs is to burn cycles
worrying what some giant corporation is doing with his work (which, sure, does
not include this Rust implementation, but very obviously does include all the
hard protocol design and validation work he's been doing over the last several
years, which, if it were easy and straightforward to do, several people would
have done before him).

I've done about as much serious technical work on WireGuard as you have --- to
wit: none, though I am a loyal, diligent distributor of WireGuard stickers. My
partners all feel the same way, so we've just been sending the project cash.

If your employer has done the same, and dumped a giant bucket of cash on Jason
in exchange for having gotten so much mileage out of his work, that would be
an _excellent_ rejoinder to this particular set of concerns.

Eagerly, therefore, awaiting my comeuppance on this thread! :)

~~~
steveklabnik
So, I'm hedging because I frankly know next to nothing about WireGuard. It's
clear you know a lot more. But, without knowing more details, I can't really
say if it's good or bad.

> then rolled it out as a proprietary offering that WireGuard itself is not
> allowed to connect to.

So, I said this in the link, but the implementation of the protocol itself is,
as Zack said, fully open source. To me, that's the high order bit here. And as
I said on the reddit thread, it appears from the outside that this is more of
a support issue than anything else. Maybe that's a lie, but I'm inclined to
take jgc at his word.

On working with upstream, what they said publicly is this:
[https://blog.cloudflare.com/boringtun-userspace-wireguard-
ru...](https://blog.cloudflare.com/boringtun-userspace-wireguard-
rust/#comment-4401651800)

> We communicated with Jason throughout the process and have a ton of respect
> for him and the entire WireGuard community. In the short term, we need the
> flexibility to quickly update BoringTun's code base to support the project
> we built it for. That's harder when you need to coordinate with people
> outside Cloudflare and when we need to move as fast as we plan to. However,
> we really believe in Open Source and want the WireGuard community to thrive.
> We licensed the code very openly (3-paragraph BSD) and WireGuard may choose
> to fork it. If they do, we'll support it and plan to contribute any
> improvements in our own fork back. Over the long term, I think we're very
> open to merging this back into the upstream project.

This seems very reasonable to me. YMMV. I have no idea what requirements would
cause this friction at the moment, but peeking at
[https://www.wireguard.com/#contributing](https://www.wireguard.com/#contributing)
it looks like they do the "non-GitHub server + mailing list" for development.
I mean, I'm literally wearing a GitHub hoodie, but I know that I personally
prefer the GitHub workflow to the point where if doing work via that system
were an upstream requirement, I'd probably do my own thing on GitHub too.

Basically, it may be good, it may be bad. I don't have enough information to
really pass judgement.

~~~
tptacek
Hold on, you had no trouble judging whether it was good or bad on that Reddit
thread. And, in case the subtext isn't clear: you've been at Cloud Flare for
like, a minute. And as you said downthread: this is what you do: you advocate
and evangelize. So this seems like pretty legitimate grist for discussion. Are
you comfortable with your advocacy here, or having second thoughts about it?

:gif_of_homer_simpson_backing_slowly_into_the_hedge: is a totally legit
response to this whole situation, for what it's worth.

(I'll reiterate: it would be amusing if your employer just smote me where I
stand by revealing the large donation they've made to Jason's project).

~~~
steveklabnik
> So this seems like pretty legitimate grist for discussion. Are you
> comfortable with your advocacy here, or having second thoughts about it?

My job isn't to be a PR person for everything Cloudflare does. Cloudflare has
and does things I disagree with. It's a company with a lot of people working
there, after all :)

All of this stuff is completely outside of what is going to be my job. And a
job I haven't even started yet! I mean, sure, it's legitimate to talk about
like anything is, but if you want to know what's going on, I'm certainly not
the person to talk to about it.

~~~
tptacek
... right! I agree! So, again: why were you volunteering opinions about the
norms-compliance of this Cloud Flare project on Reddit, rather than just
saying, "huh, no idea, wasn't involved"?

~~~
steveklabnik
Because, while it's a personal thing I am working on, I haven't yet totally
learned to not write paragraphs of text when someone asks me a question. I'll
get there :) I'll save this thread as a reminder for next time I'm tempted ;)

~~~
tptacek
Totally legit response. Thanks!

------
streblo
All of this reminds me of a talk by Gary Bernhardt called The Birth and Death
of JavaScript ([https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)), which although farcical is actually a really compelling vision
of the future of infrastructure.

Congrats Steve! Excited to see how this turns out.

~~~
steveklabnik
I was lucky enough to be present for one of the times Gary gave this talk
live. I’ve been joking that for the past few years, his nightmare is my dream.
It, like a lot of Gary’s stuff, has been very influential on me.

Thanks!

~~~
davepeck
Just make sure you stay clear of the exclusion zone and you'll be fine.

------
StavrosK
I greatly enjoyed the "state of the union" summary on WebAssembly, and I liked
how cleverly it was disguised as a new job announcement. This sounds like a
dream job (at least for me), and it prompted me to look into edge computing
and WASM/WASI more seriously. Thanks for the article, Steve, and good luck!

------
devit
Regarding the WebAssembly part, it seems to me that native Linux code
sandboxed by seccomp would work just as well if not better, and has been
available since 2005 (and there's also NaCL if you want in-process, as well as
a bunch of VMs).

So I think the reason for "CloudFlare workers" not being available ten years
ago has to be found somewhere else.

~~~
steveklabnik
There's pros and cons, like anything else. For some more details about why
specifically Workers uses V8 and Isolates, I recommend this talk:
[https://www.infoq.com/presentations/cloudflare-v8](https://www.infoq.com/presentations/cloudflare-v8)

Specifically,

> But the kind of scalability I'm talking about here is scalability to the
> number of tenants, the number of applications that we can be hosting at one
> time. The challenge with this is that, again, we don't want people to choose
> one or two or five locations where their software runs; we want it to run
> everywhere. We want everyone's code running in every one of our locations.
> And some of our locations are not that big. Though some have lots and lots
> of computers, but others have maybe a dozen machines. How do you fit- we
> have 10 million customers- on a dozen machines? Turns out that the existing
> technologies for this, the existing server-side technologies, don't live up
> to the task. What we really need is basically 100X efficiency gain in number
> of people we can host and 100X decrease in how many resources each one is
> using.

------
jrockway
I really like Cloudflare's strategy with edge compute. It's kind of what you
have to do if you want to leapfrog over what AWS has achieved. "Oh, you have
all these data centers in convenient locations for datacenters? Great. We have
them near the user." That's important because a lot of future things depend on
low latency, like gaming in the "cloud" instead of on a $500 console you have
to buy every few years.

~~~
ilovecaching
\- AWS has an edge network. Microsoft and Google have _huge_ edge networks,
with PoPs all over the place. Akamai also has a huge edge network. You also
have to guess at the size of each PoP, which is just as important as having a
PoP in a location.

\- CF still has a less sophisticated targeting system than these larger
companies that have been doing this for a long time. Targeting is everything
when it comes to CDNs.

\- Streaming games is totally different than serving web pages. It requires
specialized hardware and targeting. It's basically a whole different business.

CF has a great strategy, but it seems to be focusing more on using their
agility to adopt WA and Rust early and turn them into advantages.

~~~
acdha
> CF still has a less sophisticated targeting system than these larger
> companies that have been doing this for a long time. Targeting is everything
> when it comes to CDNs.

Do you have pointers to public data comparing services?

~~~
foobarbazetc
Just look up Maglev from Google. I mean, that stuff is years ahead of CF
(don’t get me wrong, CF is fine).

Argo from CF is a year or so old and that sort of stuff was done like 10+
years ago at Akamai. Cotendo had a great system that was more impressive 5+
years ago.

Stackpath don’t have the sort of resources that CF has but have been doing
edge compute for a while now (though not WASM).

~~~
acdha
This is why I asked for data: I was hoping someone might have some numbers for
what this actually means in practice. For example, using the _very_ broad
numbers at [https://www.cdnperf.com/cdn-
compare?type=performance&locatio...](https://www.cdnperf.com/cdn-
compare?type=performance&location=world&cdn=akamai-cdn,aws-cloudfront-
cdn,cloudflare-cdn,fastly-cdn,google-cloud-cdn) shows that Google has the
performance nod in North America but is slower in Africa, Oceania, and South
America by over twice that margin where e.g. Akamai still has a substantial
edge.

Those are also not numbers I'd want to base a serious decision on since when
I've benchmarked CDNs in the past it usually came down to things like
reliability and something like 90th percentile numbers since the median
numbers were usually fast enough but the outliers were what made people mad.
Similarly, some providers had surprisingly high DNS latency (500+ms!) in
various parts of the world but delivered competitive performance after that,
requiring some judgement.

------
whoisjuan
FYI, AWS Lambda can, and for many things, does run on edge locations (166 edge
points). So your comparison is not very accurate. The right map to use on that
comparison would be a CloudFront map.

~~~
zackbloom
It's important to not confuse Lambda for Lambda@Edge. Lambda can be executed
in a total of 18 AWS regions (if you don't count GovCloud). More importantly,
actually running your code in every region would be somewhat tricky, their
architecture is built around you deploying to each individually.

Lambda@Edge does run on their CDN nodes, but it isn't quite for general-
purpose compute, there's a long list of restrictions you can find here:
[https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-
requirements-limits.html)

If you're interested in the performance differences, I ran some comparisons
using Catchpoint a while ago: [https://blog.cloudflare.com/serverless-
performance-compariso...](https://blog.cloudflare.com/serverless-performance-
comparison-workers-lambda/)

Lambda and Lambda@Edge also deal with things like cold-starts which impact
performance irrespective of the breadth of the network. You can see some of
those numbers here: [https://serverless-benchmark.com/](https://serverless-
benchmark.com/)

------
felipeccastro
This is the second post I see about this edge functions, and while I
appreciate the advantages (decreasing network latency should definitely have
an impact), will this matter much if the database is still centralized? If
most edge functions still need to talk to a centralized database, won’t that
be essentially the same, performance wise?

~~~
steveklabnik
You are 100% right. I said this in the post:

> My role as part of Storage will be to consider “what does data access and
> storage look like in this world?” If your code is moved to the edge, but
> your data is still in a central server, you don’t gain the full benefit of
> having the code close to the client. There’s a lot of interesting stuff in
> this space!

Fixing this problem, or at least coming up with the plan to fix it, is now
literally my job :) (There is of course already a plan in motion, given that
Workers KV exists today...)

~~~
yashap
FWIW, I think “edge compute but centralized db” is often not just “not gaining
the full benefit of edge compute”, it’s actually “way slower than everything
centralized.” I’ve worked on plenty of systems where a single web facing
endpoint results in 10+ db queries. With “everything centralized”, this means
1 big round trip to the data centre, then lots of tiny/fast within-datacentre
round trips. But move compute away from the db, and suddenly you’re triggering
tonnes of really slow db calls on every client request, and the whole system
slows down tremendously.

~~~
steveklabnik
Yep, this sounds fair! For smaller things that aren't 10+ queries, I can
imagine it not being that bad, but for that, yeah, that sounds much slower.

------
jgrahamc
Welcome, Steve, but, uh, ...

    
    
        ^F^f
    

:-)

~~~
steveklabnik
I just did it in the post, but can’t change the HN title, heh. My startup was
“CloudFab”, so I’m too used to typing “CloudF,” I guess.

Really looking forward to working with you!

~~~
jgrahamc
Yeah, I saw that the blog had it correct. Looking forward to working with you
also!

------
jwr
CloudFlare Workers look like a really interesting target for ClojureScript
applications. I'm not sure if that's doable for now within their limitations,
but would enable a whole new way of writing web apps.

------
vowelless
As you have decided to write a blog post about this, and post it to HN, can
you tell us what your total compensation will be?

~~~
steveklabnik
I'm not sure how those two things are connected, exactly, but all I'd prefer
to say right now is that I am quite pleased with it. Negotiating compensation
was one of the parts of the job search that I was least looking forward to,
but it was quite pleasant, actually.

------
wila
That sounds really exciting. Congratulations!

------
dbancajas
This is why I go to HN comment section. Sometimes I even go straight to
comments before reading the article. The amount of insight/ diplomatic
bickering is so unique it doesn't exist anywhere else (by that I mean reddit)
in the interwebz.

------
yash1th
Congratulations Steve :)

edit - Also there is a small spelling mistake in this line

> A lot of people see the realtionship

~~~
tracker1
Funny how the brain autocorrects when reading quickly.. I had to look at your
quote twice to see the issue.

------
orliesaurus
Hey Steve, thanks for your work in the API world, good luck at Cloudflare!

------
cbhl
Reading this piece, it feels like the logical next leap is for someone to come
up with "Personal Lambdas", where the lambda is able to run offline, with even
lower latency than the edge.

~~~
steveklabnik
So, fun fact: Workers is based off of the Web Worker standard
[https://developer.mozilla.org/en-
US/docs/Web/API/Web_Workers...](https://developer.mozilla.org/en-
US/docs/Web/API/Web_Workers_API/Using_web_workers)

As part of this, you have Service Workers: [https://developer.mozilla.org/en-
US/docs/Web/API/Service_Wor...](https://developer.mozilla.org/en-
US/docs/Web/API/Service_Worker_API)

> They are intended, among other things, to enable the creation of effective
> offline experiences, intercept network requests and take appropriate action
> based on whether the network is available, and update assets residing on the
> server.

So yeah, you can already do something like this today!

------
new12345
What application/use-case really require a lower than sub-second(what we
already have) latency? I can only think of cloud gaming. Are we betting future
on cloud on just gaming?

~~~
steveklabnik
It's a widely held belief that response times directly influence revenue. Lots
of web pages don't load in less than a second. Every bit helps. Increased
performance means that you can do more work before hitting your target,
meaning you can deliver more complex things.

------
phillipcarter
I'm impressed that, when I search for "Butt" with Cloud to Butt Plus turned
on, I only get results for product names. Bravo!

~~~
phillipcarter
On that front, "ButtBleed" sounds a lot worse than CloudBleed, IMO.

------
djhworld
Congratulations on the new job!

------
restinsource
Radical politics, emma's quotes and...cloudflare

------
GenericsMotors
Will you be rewriting Cloudflare in rust?

~~~
steveklabnik
Cloudflare is already using Rust in a bunch of places; no need to re-write.

~~~
GenericsMotors
My comment was tongue in cheek:)

Wish you the best of luck!

------
bribri
Wish you the best Steve!

------
kwindla
This wasm-at-the-edge stuff is so exciting!

It's always dangerous to predict the future, but one possible future for the
web feels like it's starting to come into focus: javascript as the default
language everywhere (frontend, backend, edge), plus the ability to compile
lots and lots of other languages to WebAssembly.

A runtime that works everywhere (or, more accurately, a handful of partially
compatible runtimes) will encourage moving processing around the network
relatively seamlessly. Code will run on the backend sometimes, and in the
browser and apps, sometimes, and in internet edge nodes, sometimes. This feels
like the future we've been aiming for since we first added Java applet support
to the browser.

There's a huge amount of toolchain and runtime work still to do to get there,
of course. But it's a pretty cool future. Even (maybe especially) to language
snobs like me.

The article describes the four eras of "how do I web server" as: physical
servers -> infrastructure as a service -> platform as a service -> function as
a service. Just to make that a little more anecdotal ...

I built my first websites in 1994. There really wasn't a commercial web, yet.
To build a website in 1994 you probably either stuck some files in a special
place under your home directory[0] (if you were at a university), or you
downloaded and installed Apache to some machine of your own. Maybe an old
machine you left running under your desk.

Then in 1995 Netscape went public and kicked off the "dot com" era, and Bill
Gates wrote the famous "Internet Tidal Wave" memo. [1]

All of a sudden you could get paid to build websites! Big ones (or so we
thought, back then). You probably needed redundant bandwidth, and a way to
expand server capacity, and 24/7 power guarantees. There wasn't really a way
to get that stuff except to buy hardware yourself and put it in a data center.
You paid somebody with a fancy building a few thousand dollars a month (at a
minimum) for a cabinet, and a committed "95th percentile" amount of bandwidth,
a power connection rated to a certain number of apps, and a network drop. Then
you bought a lot of machines from Dell or Sun (depending on your budget),
spent a lot of time setting them up, and drove with them in the trunk of your
car to the data center.

Then the first generation of "infrastructure as a service" (Rackspace) made
the logistics a lot easier, and the costs a little better. Then AWS made the
costs a _lot_ better. And now "platform as a service" offerings like Elastic
Beanstalk have made the logistics even easier still.

But, arguably, the as-a-service evolutions haven't made it possible to
actually do new things I couldn't do on my own hardware. Faster, easier,
cheaper, yes, definitely. And those are really important!

But wasm-at-the-edge feels _new_ and, maybe, transformative.

I really like this paragraph about "the future" at the end of the Cloudflare
announcement about supporting WebAssembly [2]:

"We're excited by the possibilities that WebAssembly opens up. Perhaps, by
integrating with Cloudflare Spectrum, we could allow existing C/C++ server
code to handle arbitrary TCP and UDP protocols on the edge, like a sort of
massively-distributed inetd. Perhaps game servers could reduce latency by
running on Cloudflare, as close to the player as possible. Maybe, with the
help of some GPUs and OpenGL bindings, you could do 3D rendering and real-time
streaming directly from the edge."

[0]-[https://httpd.apache.org/docs/2.4/howto/public_html.html](https://httpd.apache.org/docs/2.4/howto/public_html.html)
[1]-[https://www.wired.com/2010/05/0526bill-gates-internet-
memo/](https://www.wired.com/2010/05/0526bill-gates-internet-memo/)
[2]-[https://blog.cloudflare.com/webassembly-on-cloudflare-
worker...](https://blog.cloudflare.com/webassembly-on-cloudflare-workers/)

~~~
alexmingoia
You don't need WASM to deploy compiled binaries to a web server, so I don't
understand the excitement. It may be convenient for the provider (CloudFlare),
but not necessarily for the customer. Performance will be better without WASM
and it's an additional step in the build pipeline, compared with CloudFlare
supporting any x86 binary.

WASM's purpose is to compile languages to run in a web browser. A CloudFlare
"worker" is a web server that runs at a data center close to the user.

~~~
kwindla
It's useful to be able to write code that runs on your server, and in the
browser, and in an "edge" thingy too (for some definition of "edge"). x86
binaries aren't going to be able to do that.

------
LittlePeter
good for you

------
the_narrator
This post has hit number one on the front page, so I assume I am out of the
loop; why is this significant?

~~~
steveklabnik
For one, this post is more than "I got a job"; there's a lot of words spilled
about the evolution of web application platforms.

For another, I've been posting here for ten years.
[https://news.ycombinator.com/leaders](https://news.ycombinator.com/leaders)
has me at #19. (I'm a fan of patio11's "this is basically an odometer" take on
that, of course.) My "I'm leaving Mozilla" post got a lot of attention too, as
well as most of my previous job change posts. I know I like hearing about what
HN members are up to, and I guess other people do too.

~~~
thaumaturgy
Yeah, you've got enough name recognition here that I saw the headline and my
reaction was, "oh, good for him." Same with patio11 joining Stripe. I don't
think I'd call HN a community exactly, but there are still people behind the
names and it's nice to see positive changes happening for them.

And your post was technically interesting too. I hadn't caught wind of WASI or
WASM being run on edge services, so that's given me something to read more
about.

------
chairman_kw
Of course the submission disappears in true corporate controlled fashion once
uncomfortable comments appear.

Must be a fun place to work at. Is Cloudflare tracking this post?

~~~
bogomipz
Indeed. There were like half a dozen people from the company all commenting on
this post including their CTO. And then poof, gone.

~~~
zackbloom
We certainly didn't want the post to disappear. It was flagged by HN (either
the mods or people with enough karma to flag), we would happily have it be
restored if it were under our power.

I've read through every comment on this page and there's nothing here I
wouldn't stand behind, even if much of seems to be misunderstood as in this
thread.

------
ilovecaching
This is a pretty genius move on CloudFlare's part. By getting Steve and
investing in Rust before it and WA really takes off they get a seat at the
table, and will probably have considerable influence and domain knowledge in
both technologies compared to other companies when it becomes mainstream.

Rust is also hedging its bets on WA, and it's looking like Rust might be _the_
language of the future web on the server and client (thanks for all the fish
Javascript). CF investing in Rust is mutually beneficial. Rust is still new,
agile, and will let people write safe code, which is going to be critical when
running modules in the end user's browser.

Hope they let Steve spend a lot of his time continuing to make Rust great, and
hopefully Steve will encourage the other Rustacians at CF to make Rust better
for the rest of us.

