Proposal: JavaScript Structs
github.com
Proposal: JavaScript Structs
1–10 of 371 posts
Re: Proposal: JavaScript Structs
#2Not sure this is a good idea or not, for one it'd be awesome for doing performance oriented and threaded code in JS/runtimes, the idea seems related to how C# struct's already work (and tuples under the hood). Interop with WASM code might also be simplified if struct-like access was a built-in.
The bad is that people wouldn't necessarily be prepared for their semantics (are they value or reference based?), how to shared prototypes between environments (mentioned as problem in the proposal itself), not entirely sure if this proposal would add to the complexity vs security for spectre like attacks.
It'd be useful, but worth it is another question? (And would all major players see interest in it? esp considering that it'd need to be "JSzero" level propsal if they go in that direction. (There was a post here a few days ago about layering runtimes with JS0 being the core with everything else being syntax transforms on top).
Re: Proposal: JavaScript Structs
#3Huh, I thought that most work that used to use workers switched to Webassembly.
Talking about JS proposals, I'm looking forward to this one: https://github.com/tc39/proposal-record-tuple
Records and tuples can make a lot of logic much more easier to read, and way less fragile. Not sure how they would play together with the shared structs though.
Re: Proposal: JavaScript Structs
#4Huh, no types. So every field is 8 bytes I guess?
I suppose if you want a defined/packed memory layout you can already use SharedArrayBuffer and if you want to store objects in it you can use this BufferBackedObjects library they linked. https://github.com/GoogleChromeLabs/buffer-backed-object
I also expect that in browsers this will have the same cross-origin isolation requirements as SharedArrayBuffer that make it difficult to use.
Re: Proposal: JavaScript Structs
#5Huh, I thought that most work that used to use workers switched to Webassembly. Talking about JS proposals, I'm looking forward to this one: https://github.com/tc39/proposal-record-tuple Records and tuples can make a lot of logic much more easier to read, and way less fragile. Not sure how they would play together with the shared structs though.
[deleted]
Re: Proposal: JavaScript Structs
#6JS devs - do everything but write in another language challenge level: Impossible.
Re: Proposal: JavaScript Structs
#7The general idea of types with a fixed layout seems great, but I'm a lot more dubious about the idea of unsafe blocks. The web is supposed to be a sandbox where we run untrusted code and with pretty good certainty expect that it can't crash the computer. Allowing untrusted code to specify "hey let me do stuff that can cause data races if not done correctly" is just asking for trouble, and also exploits. If shared structs are going to be adopted I think they probably need to be immutable after creation, or at the very least only modified with atomic operations.
Re: Proposal: JavaScript Structs
#8I initially didn't like the high level idea, but I warmed up to it. My only concern is that the constructor isn't guaranteed to define the same fields with the same types, which kind of defeats the point.
I'd improve this proposal in two ways:
1. Explicitly define the layout with types. It's new syntax already, you can be spicy here.
2. Define a way for structs to be directly read into and out of ArrayBuffers. Fixed layout memory and serialization go hand in hand. Obviously a lot of unanswered questions here but that's the point of the process.
The unsafe block stuff, frankly, seems like it should be part of a separate proposal.
Re: Proposal: JavaScript Structs
#9It's hard to take anyone concerned about the 'performance ceilings' in javascript object creation seriously at this point.
Re: Proposal: JavaScript Structs
#10The general idea of types with a fixed layout seems great, but I'm a lot more dubious about the idea of unsafe blocks. The web is supposed to be a sandbox where we run untrusted code and with pretty good certainty expect that it can't crash the computer. Allowing untrusted code to specify "hey let me do stuff that can cause data races if not done correctly" is just asking for trouble, and also exploits. If shared str…
Isn't it really no different to what you can already do with WASM threads though? C/C++ or unsafe Rust compiled to WASM can have data races, but the worst it can do is crash the WASM instance, just like how you can have use-after-frees or out-of-bounds array accesses in WASM but the blast radius is confined to the instance.
Granted, a JS runtime is significantly more complex than a WASM runtime so there is more room for error.