2 ms·

> All of the language differences between .NET and Java fall in this "non-consensus" zone Curious if you think fibers vs async/await is still in this zone (amo

> All of the language differences between .NET and Java fall in this "non-consensus" zone Curious if you think fibers vs async/await is still in this zone (amongst experts). It seems fibers are objectively better. But I'm no expert*

pron 4mo ago
I think user-mode threads are better when the language already has threads. I'm not sure they would have been better for JS. But yeah, this one is probably less controversial than things like properties and extension members, which we also said "yeah, nah" to.
- sroussey 4mo ago
  https://github.com/oven-sh/WebKit/pull/249 https://github.com/oven-sh/WebKit/pull/249
  - aardvark179 4mo ago
    Although the work being done to enable multiple threads in JS is impressive I think it will be hard to make robust in many casss without locks, or fairly strict limits what operations can be performed on objects shared between threads. The property lookup and modification process in JS is complex enough as is, is not specified in an atomic kind of way, and has many opportunities for user code to be run as part of accessor properties. Enabling it in multithreaded implementations is tricky without opening up deadlocks when modifying property collections, and even with that could likely be broken by some suitably evil code. Ive worked on more than one implementation that offered some degree of multithreaded access and it’s generally only safe when limited to simple properties. Async / await avoids those issues because none of the places where user code can be executed allow async code, so there is no opportunity for the world to be changed under your feet during something like property access.
    - sroussey 4mo ago
      https://tc39.es/proposal-structs/ https://tc39.es/proposal-structs/ Structs, Shared Structs, and Synchronization Primitives There are a few things that would be required to make it all work, this would be one of them.
  - pron 4mo ago
    I'd be very surprised if Google go for it.

pron 4mo ago

I think user-mode threads are better when the language already has threads. I'm not sure they would have been better for JS. But yeah, this one is probably less controversial than things like properties and extension members, which we also said "yeah, nah" to.

sroussey 4mo ago
https://github.com/oven-sh/WebKit/pull/249 https://github.com/oven-sh/WebKit/pull/249
- aardvark179 4mo ago
  Although the work being done to enable multiple threads in JS is impressive I think it will be hard to make robust in many casss without locks, or fairly strict limits what operations can be performed on objects shared between threads. The property lookup and modification process in JS is complex enough as is, is not specified in an atomic kind of way, and has many opportunities for user code to be run as part of accessor properties. Enabling it in multithreaded implementations is tricky without opening up deadlocks when modifying property collections, and even with that could likely be broken by some suitably evil code. Ive worked on more than one implementation that offered some degree of multithreaded access and it’s generally only safe when limited to simple properties. Async / await avoids those issues because none of the places where user code can be executed allow async code, so there is no opportunity for the world to be changed under your feet during something like property access.
  - sroussey 4mo ago
    https://tc39.es/proposal-structs/ https://tc39.es/proposal-structs/ Structs, Shared Structs, and Synchronization Primitives There are a few things that would be required to make it all work, this would be one of them.
- pron 4mo ago
  I'd be very surprised if Google go for it.