4 ms·

For some context, this is from an “unpopular opinions” section of the podcast where they specifically ask for a controversial opinion. In the ensuing discussion

by paulgb 3y ago

For some context, this is from an “unpopular opinions” section of the podcast where they specifically ask for a controversial opinion. In the ensuing discussion, the prediction is further qualified: > I’m not gonna say it’s gonna replace every use case; it’s clearly not. But for certain high-performance latency-sensitive use cases like trying to deliver feature flags globally to mobile apps, or web apps around the world (that is our use case)… it’s definitely very applicable to this problem. I do think that if WASI gets sockets and threading soon as planned, it suddenly becomes compelling for a bunch of interesting workloads that containers are used for now.

troupo 3y ago
> But for certain high-performance latency-sensitive use cases like trying to deliver feature flags globally to mobile apps, or web apps around the world (that is our use case)… it’s definitely very applicable to this problem. I fail to see how it's applicable. Unless your entire world is Javascript and its performance
- preseinger 3y ago
  wasm is not bound to javascript in any meaningful sense
  - troupo 3y ago
    wasm literally came out of asm.js and browsers. And its original goal is literally to make stuff in browsers more performant compared to Javascript. So when people say stuff like "high-performance latency-sensitive use cases are applicable to wasm" they clearly only understand performance and latency in comparison to Javascript.
    - preseinger 3y ago
      it started there but that's not like the only goal of the thing and like there's plenty of people doing wasm on the server where performance is measured in microseconds
      - troupo 3y ago
        > it started there but that's not like the only goal of the thing According to the website and the core spec it's still the main goal > there's plenty of people doing wasm on the server where performance is measured in microseconds I'm old enough to remember when node.js was also marketed as "web scale" and high performance.

by paulgb 3y ago

troupo 3y ago

> But for certain high-performance latency-sensitive use cases like trying to deliver feature flags globally to mobile apps, or web apps around the world (that is our use case)… it’s definitely very applicable to this problem. I fail to see how it's applicable. Unless your entire world is Javascript and its performance

preseinger 3y ago
wasm is not bound to javascript in any meaningful sense
- troupo 3y ago
  wasm literally came out of asm.js and browsers. And its original goal is literally to make stuff in browsers more performant compared to Javascript. So when people say stuff like "high-performance latency-sensitive use cases are applicable to wasm" they clearly only understand performance and latency in comparison to Javascript.
  - preseinger 3y ago
    it started there but that's not like the only goal of the thing and like there's plenty of people doing wasm on the server where performance is measured in microseconds
    - troupo 3y ago
      > it started there but that's not like the only goal of the thing According to the website and the core spec it's still the main goal > there's plenty of people doing wasm on the server where performance is measured in microseconds I'm old enough to remember when node.js was also marketed as "web scale" and high performance.