eins1234's comments

Also curious about how Node.js support would work?

I've heard about efforts to compile SpiderMonkey to WASM to run JS, but never V8 and the entirety of Node.js. That would be super exciting if that's what you're looking to accomplish. Would love to follow along and contribute if this is part of an open source effort!

Curious if you think cold starts could be a problem with this approach? Share-nothing architecture sounds great until you realize you have to load the entirety of V8 and Node.js on every request, but maybe you've figured out some way to work around that?

Also, how do you think the lack of JIT could affect real-world JS runtime performance? Or is there a solution for that too?

Really happy for anyone looking for a larger high-performance laptop!

But personally, I was really hoping for a 13-inch convertible with touch and pen input from these guys... Maybe next year?

Was this under the "Crisis Alerts" category for Google? Going to set it for my phone too, even though this kind of thing really should be set to override do not disturb by default.

Apparently my phone supports notification history, but it was also turned off by default... Bad defaults strikes twice in a row.

Are the benchmarks used for generating the results on the website available for us to poke around in? https://turbo.build/pack

I'm curious about the "Cold Start" time for 30k modules taking 20s, which still doesn't feel like the best possible experience, even though it's a significant improvement over the other contenders listed.

Is there a separate, faster "Warm Start" time after everything is cached? Or is this it?

My Samsung got the notification from Google too, so probably not a Pixel exclusive thing.

Though I wish it would have overridden silent mode. 10s of advanced warning isn't all that helpful if I only find out about the notification 10 minutes later.

If I don't think someone can bring significant value to the business by the second month at the latest, I won't hire them. And if I do hire someone and they don't end up bringing significant value to the business by the second month (or if they end up bringing negative value), then I let them go.

So if they make it even to just month three, it means the hire was well justified. If they leave any time after that, even if it's before their first anniversary, I wish them good luck on their next venture and thank them for the value they brought to the business during their tenure.

The length of their tenure for past positions is completely irrelevant in all of this, so doesn't factor into my hiring decisions at all. Frankly I don't understand why anyone would do any differently.

At the end of the day, I think preferring employees who are "loyal" to past employers is a sign of insecurity on the company/hiring manager's side. It means they secretly think their company is at best only average at retaining great employees, so they resort to biasing towards "loyal" employees as a clutch. I would suggest they work on employee retention instead of disqualifying perfectly good candidates for not having been "loyal" enough in the past.

Employees don't owe any "loyalty" to their employers. It's the employer's job to retain employees. When an employee leaves early, it's almost always because the employer was doing a shitty job at retention.

Totally, if you've tried both and vastly preferred one, it's a no brainer. :)

At the end of the day, I don't think there's a right choice here. Either way we choose to go, with or without a cofounder, starting a startup is just damn hard, and either path has a ton of potential pitfalls, so the best we can do is just pick the path that better suits our life situation/preferences.

FWIW, the actual recommendations in the article are a lot more nuanced than the rather inflammatory title. I for one appreciated it, if nothing more than as something to counter the prevailing propaganda in the valley around how having a cofounder always increases your chances to succeed, even though cofounder conflict consistently ranks as one of the top startup killers. I especially concur with the conjecture that "cofounder dating" (and services that facilitate and encourage it) likely leads overwhelmingly to bad outcomes for the vast majority of cases, and people might have better chances to succeed as a solo founder than to resort to founding with someone they've been on just a handful of "dates" with.

I think the counter argument in the article that was more relevant was the grass is always greener on the other side part. It's hard to form an informed opinion until we've been on both sides.

Though I think it's totally valid to want to try the cofounder approach if you've tried the solo approach and just totally hated it and never want to do it again. I think there are probably also plenty of founders out there who have had a bad cofounder experience and would only consider solo-founding for their next venture.

A perspective from the other side: I definitely don't regret specializing rather early on in my career.

Doing a little bit of everything early on is great, and in fact is required to figure what you're good at and what you enjoy, both important factors in choosing what to specialize in.

But going deep into one specific craft to the point where I could confidently assert that I was one of the best in the world at the craft has been an extremely fulfilling experience. Deep expertise is also something that peers will naturally look up to and respect, and can unlock the highest tiers of compensation a lot faster than breadth alone.

I've been forcing myself to branch out ever since deciding to start my own startup, but the focus on gaining deep expertise in a single craft early in my career is what eventually allowed me to contain imposter syndrome and gain the confidence needed to start this new journey.

Nice, the fact that Fastly is comfortable betting on Spidermonkey.wasm is the vote of confidence I needed to dig in! Also really love seeing how much Fastly is giving back to open source!

This is super helpful. Thank you so much! Will start digging into these right away.

Instantiating a runtime in microseconds is deeply exciting!

Though after skimming through the docs, I'm still left wondering a few things:

- JS is notably missing from the list of languages supported on the front page. But I see mentions of a Spidermonkey.wasm in the blog post. Is running JS on top of wasmtime in production a realistic prospect today? If so, where can I read more? (mainly interested in this for the instantiation time benefits, though maybe all/most of that will be negated by the embedded JS engine?)

- How should I go about building a typical web service on top of wasmtime? Can wasmtime itself handle network requests/connections or would I need to build the web server in some other host language and pass request data to wasmtime modules? Haven't been able to find anything in the docs about this.

- What would it take to build a multitenant web service where customer code is isolated using wasmtime, like the one like described in the post?

Yeah that's exactly it. If you're in that "Trough of Sorrow" (and statistically speaking most startups in the world are at any given moment), YC and everybody else will not touch your startup even if you had resumes that would have been impressive enough to get your foot in the door with just the idea.

Ofc if an applicant made it past the "Trough of Sorrow" and reached PMF on their own, it's a no brainer, any decent VC would be throwing money their way at that point. For the rest of the applicants though, it just feels a bit backwards to me how YC seems to rather bet on founders with impressive resumes who have built nothing over similarly impressive founders who have proven that they can build something tangible, but need some help getting it past this infamous "Trough of Sorrow" that most successful startups are known to have gone through.

But hey what do I know. Surely they have the data internally to back that up right?

This is obviously based on anecdata, take it with a healthy helping of salt, but from what I've heard from a bunch of founder friends who have applied to YC with varying results, I get the sense that if you want to get in, you might be better off applying before you even start working on your startup.

Once you actually start, the bar for getting in seems to get much higher, because there's suddenly a lot more concrete data points to benchmark your startup against. Before that all they have is basically an idea and a bunch of resumes. This is of course contingent on the fact that you have impressive looking resumes and at least a plausible idea.

It's a bit of a catch 22 for B2B startups hoping to use the YC startup network as a source of early customers, but didn't apply early enough. If you're thinking of starting a B2B startup that could make good use of YC's network, my recommendation would be to apply as early as possible, before you even start working on it. Worst case scenario is you get rejected and end up having to apply again in 6 months (which is fine because you applied 6+ months earlier than you might have otherwise, and now have feedback from their rejection to make your next application better).

I don't know a whole lot about how email works under the hood but...

When the best vendors out there proudly advertise multiple whole integer seconds in average latency in the best case (https://postmarkapp.com/why), I can only assume there's a lot of room for improvement for the protocol itself, and it's not just an issue with clients.

Sending text between servers on the internet shouldn't take this long in 2022.

(And holy crap what's with Apple's 99s latency?)

> Yeah, because enterprise pricing is so nefarious.

The cover up I was referring to was the 10 user limit before Enterprise pricing gets applied, hidden behind a tooltip deep in their pricing grid.

I thought it was obvious given that every one of these companies have enterprise pricing and advertise it front and center, but only Vercel hides the user limit. Assuming your post is in good faith and not a deliberate strawman, I concede that I could have been more specific.

That's good to know! Would be nice to hear from someone from CF on how they plan on monetizing these "direct uploads" before we start investing in a migration.

The increase in value provided by these services is very much linear w.r.t. number of users. The 10x+ leap in cost with enterprise pricing is not at all justified by additional value provided.

I don't mind paying a fair, pre-disclosed price for services that provide value. I do mind opaque enterprise sales tactics that try to take full percentage points off my available runway for no discernable increase in value when I try to add one more user. Doubly so when they go to such lengths to cover it up as Vercel is currently doing.

Also, found out the hard way that "Enterprise" pricing (i.e. call us and we'll charge you an opaque amount based on whatever we think you can afford pricing) starts at 7 users.

Vercel is not much better at 10 users, and they hide it deep within their pricing table behind a tooltip so you're not likely to realize this until it's too late.

Cloudflare Pages doesn't charge per user but limits concurrent builds which can get really painful.

I honestly can't find a good option in this space anymore... What happened?