eins1234
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!
Also 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?
But personally, I was really hoping for a 13-inch convertible with touch and pen input from these guys... Maybe next year?
Apparently my phone supports notification history, but it was also turned off by default... Bad defaults strikes twice in a row.
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?
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.
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.
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.
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.
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.
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?
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. 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).
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?)
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.
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.
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?
In what world does a 11 person team qualify as an Enterprise? Though pedanticism aside, my problem is more with the opaque pricing than the naming.
Even if we had a local runner, if it takes a ton of time to start and complete every step, it'd be almost as painful to debug as a remote runner taking the same time. On the other hand, if the cloud runner is ridiculously fast, and completes steps on the order of single digit seconds, it would be fairly painless to debug.
Null is a real value that can be compared intuitively like any other value (`Equals(null, null)` returns true). [1]
However, in indexes, any term that evaluates to null is simply not stored in the index. So we can create a unique index with multiple null values because they simply won't exist in the index, so won't violate the unique constraint.
If we do care about null values in a particular index, we can handle that by mapping the null value into another value that will get stored in indexes using a "binding", and then use that index to query for or constrain uniqueness by that mapped value [2].
This is not the most convenient thing in the world, but at the end of the day, it feels like an edge case, so I'm happy with having to jump through some hoops to handle it in exchange for making the much more common cases (null comparisons and unique indexes with nullable values) more intuitive and less error prone.
[1] https://fauna.com/blog/understanding-nothing-or-null-in-faun...
[2] https://docs.fauna.com/fauna/current/learn/cookbook/fql/sear...
I'm convinced it's exactly this. I gave them the benefit of the doubt with the M1 that it's just a first-gen quirk, something that they managed to address with the Pro and Max and would become a non-issue going forward.
But now that M2 has been introduced with the same limitation, it's become crystal clear that this is yet another classic Apple anti-consumer profit-seeking tactic.
Hoping the rest of the industry can eventually catch up to and hopefully overtake Apple silicon in performance/watt and discourage this kind of behavior, but given the sheer amount of resources they have available compared to every other player, I'm not holding my breath.
I tried to exercise some restraint this time, but screw it. Here's another rant:
Beware of Cloudflare's tactic of luring people in to their CDN product with "free" bandwidth, and then locking useful features arbitrarily behind what I can only imagine is a thousands of dollars per month enterprise plan. Just look at their cache-purging page for a super obvious example of this (there are plenty more, way too many to list), everything other than basic purge by URL is enterprise only: https://developers.cloudflare.com/cache/how-to/purge-cache/
These days Cloudflare is literally my last choice for a CDN for my new projects. My new go-to is bunny.net, who charges a reasonable usage-based fee for bandwidth and gives you unfettered access to all the features they've built (and doesn't route your users to farther/closer nodes based on how much you pay: https://cloudflare-test.judge.sh/). Though I'd even reach for Cloudfront with their expensive bandwidth costs these days, because at least their pricing is transparent and scales smoothly with usage, and they don't arbitrarily cut you off from useful features that you might not know you need yet.
Even their bandwidth might not really be "free", since I've heard if you actually use any significant amount, the sales people will come knocking on your door to coerce you to get on the same enterprise plan or have your site taken down.
Is there an easy way for regular consumers to set up recurring payments in a "push" configuration (i.e. from my bank to someone else's) rather than "pull" configuration (i.e. most subscriptions where the service charges a credit card on an interval)?
I split a T-Mobile multi-line plan with a few friends where I'm the payer, and I remember looking into this a while back to help them pay their share on time and without hassle, but coming up empty.
Feels like it would be useful for paying for something like Mullvad too, but I feel like there are benefits to that model that reaches beyond the individual use cases I mentioned.
It'd allow me to manage money going out of my account from 1 centralized location, making money flow more predictable and less chaotic than the status quo where a random amount of money is pulled out of my account from various credit cards every month, and I have to log into each account separately to figure out how much.