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?
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.
You just reminded me to go into my notification history and turn on "Override Do Not Disturb" for the earthquake early warning notification. I really like the notification history for that; you can go back to a notification you dismissed hours ago and edit its settings.
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.
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.
The clear divide in hiring preferences will be if it's owner operated or manager operated. Owner (like I suspect, you) will have clear goals, expectations, and fast ramp-up for the position. Manager wants cog_A in engine_B - predictable, loyal (to the hiring manager & their chain), good at office politics.
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.
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?
These are good questions! Here's some answers from the corner of the world I know best as a Wasmtime contributor at Fastly:
1. Spidermonkey.wasm is the basis of Fastly's JavaScript on Compute@Edge support. We have found it to be faster than QuickJS. The source code is here: https://github.com/fastly/js-compute-runtime.
3. Fastly's multi-tenant platform is closed source, but our single-tenant local development platform, which also uses wasmtime under the hood as well, is open source: https://github.com/fastly/viceroy. It isn't a big leap to make viceroy multi-tenant: Wasmtime provides everything you need, and all Viceroy would have to do is dispatch on e.g. HTTP host header to the correct tenant. Our multi-tenant platform is closed source because it is very specialized for use on Fastly's edge, not because the multi-tenant aspect is special.
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!
> 1. Spidermonkey.wasm is the basis of Fastly's JavaScript on Compute@Edge support.
How difficult is staying up to date with SpiderMonkey's latest or pre-release upstream versions? Do have to maintain your own SpiderMonkey patches to make upstream work for you?
We worked with Igalia to upstream the SpiderMonkey patches required to build for wasm32-wasi. We point to a fixed version (see: https://github.com/fastly/spidermonkey-wasi-embedding) which we haven't updated for a minute.
> - 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?)
Shopify and others use QuickJS as their JS engine of choice. See https://github.com/Shopify/javy as a starting point. The real benefit is allowing authors of plugins to write JS and not AssemblyScript, not any performance or instantiation time benefits.
> - 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.
There are a lot of choices for this. None I would consider mature, but some leads:
They handle the passing of data between host and guest for you. Your module, written in a language that compiles down to wasm, is evaluated against the request. They make host functionality, such as the ability to make other network calls, available to your module as needed.
> - 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?
See suborbital linked above. Not much. This is the primary current use case for server side wasm.
It is indeed early days, but we're pretty confident that the opportunity is real. Take webhooks. With webhooks, your customers have to bring and manage their own infrastructure. That's a pain in the ass. Everywhere that supports webhooks should also support Just Running My Damn Code. Like with GitHub Actions.
How does GitHub do it? Simple: They're owned by Microsoft. GitHub can bury the problem in an ungodly deluge of cheap virtual machines from their sister company, Azure.
You aren't owned by Microsoft, so how will you Just Run Some Code? You're going to use WebAssembly. Specifically, in a year or two, you're going to integrate some sort of off-the-shelf commodity product that's powered by WebAssembly.
Suborbital is one shot at what that future might look like. We'll be talking more about this in the next few weeks. And it's not just us: a lot of the serverside WebAssembly folks will be at Cloud Native WASM Day at KubeCon next month... say hello if you're there!
In what use cases can user-provided wasm realistically replace webhooks? It seems to me that in plenty of cases, you'd end up needing something like webhooks anyway. For instance, I use Stripe, and I implement their webhook to handle completed checkouts. My webhook implementation needs to update my database, send email using my email service provider credentials, etc. I doubt that running my own wasm code on Stripe's infrastructure would make things simpler. But I'd like to learn more on use cases where user-provided wasm really would be better.
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).
YC does offer a free version of their program open to anyone called Startup School (https://www.startupschool.org) that can be a good way to gain validation and judge interest. Applying to YC seems to be best for idea staged founders with impressive resumes and people skills or startups that have already gained some traction. If you are in the "Trough of Sorrow" stage as Paul Graham described it, then I'm not sure where you really turn for help.
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?
>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.
I started in late 2013 and was rejected by YC in 2016. Haven't applied to anything since, with the exception of Apollo. Certainly was very aware of that dynamic at the time.
As a solo founder who lacks the aforementioned impressive resume, and who's nearly a decade in, I no longer have much hope for accelerators.
This was written less than a month before COVID inflicted a great deal of pain and delayed things by a little more than a year:
Would it not make sense for you to get user validation with a smaller scale poc than the herculean plan you outlined. Also your plan seem to focus too much on funding goals than user acquisition or product market fit. Unless you are planning to create a spacex style capital intensive company, I don't see why you need so much funding for.
>Would it not make sense for you to get user validation with a smaller scale poc than the herculean plan you outlined. Also your plan seem to focus too much on funding goals than user acquisition or product market fit.
I used to think in those terms. Thing is, it's a multi-dimensional problem.
Dimension one is a human resource limitation. One person pitted against a rapidly evolving technology landscape with very high technical bar. What that equates to is making one demo/MVP after another and eventually burning out. Or, compromising quality. Early on, it was possible to do it the traditional way. Things are now moving too fast.
Regardless, the reward in either scenario is funding based on whatever "product market fit," and users that require tending to. Best case, you might end up a multi-billion dollar company if you make it. One not all that different from pile after pile of technical debts that routinely waddle to their respective exits, then exist in some hellish afterlife post-exit. That's typically defined as success. I imagine one loses their soul in the process of even creating such a thing.
Point being, I view user acquisition and product market fit as poison pills. Not just for the company optimizing for it, but for society as a whole. They are a large part of what is wrong in the world.
Dimension two is expansion of scope. The more you think, the more beautiful things get. It's really hard to go back and limit scope once you've woven ideas together over the span of years in a kind of tapestry where individual concepts end up almost symbiotic. Fortunately, I inadvertently dedicated my time to this type of thinking rather than grinding out demos.
So, what you're left with is selling a vision. Absent any track record, it still necessitates a demo—but the nature of that demo becomes fundamentally different—as does its target audience. More of a living design document built to help convey that vision.
---
>Unless you are planning to create a spacex style capital intensive company, I don't see why you need so much funding for.
Well, the goal is for people to wake up one day and find out that the way they interact with computing as a whole has fundamentally changed forever.
On HN, you see people grasping with regularity at individual threads which constitute pieces of this puzzle, with no clear consensus on what should be done. There's an almost morose acceptance that pervades the current technological hellscape in which we live. Now people are looking back at dreams of what once could have been as a way out of this mess, but that alone isn't sufficient.
In any case, things get expensive at that level. I'm in my mid thirties and the core team I want to hire is probably twenty years my senior on average. Some of them probably don't even care about the money.
In all likelihood it'll go nowhere and I'll remain a nobody, but it's already been a wild ride, and hopefully I'll at least have fun and be spared the stereotypical startup/accelerator/VC grind.
Hey, perhaps somewhere along the way I'll even figure out how to not sound delusional.
If your vision is truly so all-encompassing, maybe that's the thing you should work on selling -- but not to investors; to the people you want to work with. Solve your HR problem, get some co-founders, and get going.
That's more or less the plan. Convince some key people, maybe raise a seed round that pays for a couple years of formal pre-production, and very delicately snowball into a dream team contingent on further funding.
Co-founders can't work since I've been at it nearly a decade, but that's more for control/singular vision reasons and not equity.
In the mean time, I'm just thankful to be alive and working a full-time job to get there.
I think that's true. it's not dissimilar to an employment application. I never realized this before reading your comment but I think you frame it right: Basically they're looking for people to do the work required to build a business that they want to make them money, and to be coachable enough to take the advice of the YC folks. Just like an employee. Except it's not framed like that and the rewards can be different (but not always) it's just sort of like a higher level of risk, so the bell curve compared to employee salaries probably flattens out and broadens.
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?