41–50 of 64 posts
OT but this... > I strongly believe that async is the new billion dollar mistake of the 2020's: a design aberration that wasted so much developers time that it had cost billions of dollars to companies. Yes. Nicely put
What does this even mean, how can you do any form of modern computation without async?
Earlier quoted context omitted.
Completely disagree. Async as a paradigm has probably created billions of dollars in that it's allowed many many many developers to reasonably scale beyond what they could've otherwise.
Agree wholesale. I've got a complex data reader built on a single server that receives tens of thousands of requests a day, and most tend to happen in a few hour window. Async was super important to scale to user requests by allowing non-blocking calls to not get captured behind blocking ones.
You have been blocked, apparently Android Chrome is a malicious browser.
Earlier quoted context omitted.
What does this even mean, how can you do any form of modern computation without async?
async / await as they exist in JavaScript, Python, and Rust aren’t the only way to execute tasks concurrently.
For those that aim to continue working on top of WASIp1, WASIX (https://wasix.org) might be a great way to get your programs with sockets and threads fully running on Wasm.
Note: I work at Wasmer (https://wasmer.io), a WebAssembly runtime.
The promise of being able to use any library from any language is really quite compelling, and that's what the WASM component model is about for me. It's pretty sad to say this amount of hate TBH
I'm excited for having extremely lightweight sandboxed. WASI enables having a runtime with a bunch of loaded libraries. You can start a very small script & link in the already loaded modules on the fly, in a very secure fashion.
It's be like having an isolate-oer-requesf model. Super secure, but with fantastically low overhead. Ideally instead of having a huge app server, a front end router would be picking which specific actions to run.
The ability to spin up a cast number of very lightweight secure processes and have them communicating with each other is fascinating. App servers as we build them are ghastly complicated swiss army knives, and being able to have something like a "serverless"/lambda architecture where we can narrow the scope down & really think about what has to be in a given request handling's process could be a big operational boon, if we're willing to once more venture away from the comforting warmth of the monolith that folks love huddling up next to.
As usual though hope & possibility is speculative & nuanced & diverse, and disbelief & disgust is blanket & unifying. I have no clue how I'm still so shocked to see negativity upvoted, positivity out down upon, after it happening so many times but I keep being surprised how strongly negativity reigns. And how fiercely & widely it downvotes! There's just something about the disbelievers & skeptics that they have to smash the downvote, can't abide possibility or excitement; there's never any wait and see, never any maybe about it. Just doom & gloom on and on.
Uhh really? You just got done pointing out
> But, WASI 0.1 was severely limited about the type of data that it could exchange: basically integers and pointers to buffers.
We obviously couldn't stop there.
The author has all sorts of shit to throw about the interface definitions being way more complex than they want.
It turns out calling other languages isn't just about calling their stuff. You also need to be able to import and then latter link the things you want to use. Being able to say what it is you want brought in, what you want to link to, that's stuff the runtime needs to be able to do.
Look at c and c++. They've been around for decades and there's still nearly no mainstream package/library management. Because it looks like what Kerkour asked for, because everything is too simple in that world.
You need this stuff. You need to be able to create high level semantics to interoperate across. You need a rich enough ABI to let languages negotiate for & get the things they're going to call.
The qualms against async are even less well defined & even more unsupported, which is compensated for being ever more foaming at the mouth & wild gesticulating. Rather than acknowledge that yeah, some people like & use async in languages, there's utterly untargeted shade of the broadest degree:
> Most importantly, after all these years, nobody knows when to use [rust's async] or not! Should this library be async or not?
Io-less libraries that can put off being async are in fact excellent. But there still, in most systems, are things happening over time, and async happening in Python and Node and others radically upped the game of what was possible. And in the past decade have even evolved into something pretty nice & great & usable.
But Rust having some difficulty figuring out how to manage their ecosystem is, to Kerkour, apparently enough to damn the whole enterprise, "The new billion dollar mistake." Having been around for cgi-bin and mod-perl, I don't think I'm so massively massively confidently assured.
Things aren't always exactly as perfect as we might want. And that just really drives some people wildly mad, is inexcusable. 'We should never have tried, ruin to those trying to improve things, & drop it all & go back!,' seems to be the message. Actually the message here is even worse, more, 'these people are vultures trying to syphon money with the express intent to create waste & milk the anarchy,' which is some contagious shit to be spewing.
This seems so overblown. WIT's are not that complex. Theres reasons stuff is like this (permitting wasm engines form a registry to give people what they're asking to use, without needing internals that would have to DIY this all themselves). And maybe such a broad objective as a universal computing runtime might be possible with less. But honestly the risk of underbidding & failing to connect different systems well seems far worse than the risk of, I dunno, what the author seems to be apoplectic about, perhaps maybe enjoying using a package manager to help satisfy dependencies.
One thing the author is right about, that makes me extremely sad:
> I hardly see browser vendors implementing this
I can excuse this today, because it is unknown. But wow it's scary as hell seeing how uninvolved & interest the browsers look. The browsers seem full speed ahead building their own take on platform, doing their own file system APIs and what not. There's great efforts by many to bridge the two worlds, to create WASI runtimes for the browser, but some day I really hope the promised universal machine of WASI is something the web can enjoy and use. But I'm also not in a hurry; I think there's a lot of figuring how best to make this wasi 0.2 world nice & letting languages figure out their own tooling to come play. Patience & improving & iterating is good; trying is good. We improve & progress through time and effort.
Earlier quoted context omitted.
I think the argument here is that you don’t need a full N:1:M mapping of data types to make this work. Transparency is a myth. If you try it (as in Sun RPC, DCE, CORBA, COM, etc.) you end up just writing wrappers anyway as you hit some edge case that the universal type system doesn’t support. E.g., look at the clunky IDL interfaces COM had to invent to get interop with JavaScript objects because IDL had baked-in assu…
I just realized: The very fact that WASI isn’t using any of the previous N attempts at a supposedly universal IDL, but instead inventing yet another one, itself demonstrates the problem with this approach.
Earlier quoted context omitted.
> Writing code that lives in an event loop is pure pain, Do you think? I find explicit event loops pleasurable. Does that make me a freak?
They're pleasurable when you're the only author. They become a minefield unless every contributor is diligent, which happens very often.
P99 latency for every route on your web server will be fixed at the max time any individual unit takes to execute before yielding plus loop overhead and its own time. This can drastically increase it for many routes.
Meanwhile some genius insists that our app is “io bound” so the single threaded async runtime must be a perfect fit.
Apart from just being generally faster at least with go I know that when somebody screws up there should be n other threads still executing tasks.