Fixed layout structs seem like a no brainer and a natural extension of the typed arrays. It’s strange that both Java and Jacascript went so long without them. Interacting with many APIs (webgpu, FFI, …) quickly becomes really unpleasant if you can’t control data layout.
Proposal: JavaScript Structs
111–120 of 371 posts
Re: Proposal: JavaScript Structs
#112I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…
Couldn't agree more. More features in a programming language makes it easier and more fun to write code, but makes it harder to read and maintain someone else's code. Considering more time is spent maintaining code as opposed to writing it (assuming the product is successful), readability is more important than writability.
Re: Proposal: JavaScript Structs
#113The 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…
The unsafe block doesn't actually do anything at all. It's just pointless cargo-cutling from Rust.
Re: Proposal: JavaScript Structs
#114Re: Proposal: JavaScript Structs
#115I feel conflicted. Working with multithreaded stuff in JS is a huge PITA. This would go some way to making things easier. But it also feels like it would radically complicate JS. Unsafe blocks? Wow-eee. With the rise of WASM part of me feels like we shouldn't even try to make JS better at multithreading and just use other languages better suited to the purpose. But then I'm a pessimist.
I read this and think "can't we just make freezing objects less expensive?"
Otherwise, that's all this seems like to me, a class where all instances are automatically frozen. Which is a great semantic, but they expose way too much of the internals, in this proposal, to achieve that.
Modern development is so goofy.
Re: Proposal: JavaScript Structs
#116Earlier quoted context omitted.
Exactly. Without new features and syntaxes people would still be doing MyClass.prototype.method = function () { } like idiots. Such a meaningless argument for preventing progress.
Nobody needs classes nor prototypes in JS. Objects + functions is more than enough. I stopped using these few years ago and miss nothing.
You and "anybody" are actually two different sets of people with different needs and desires
Re: Proposal: JavaScript Structs
#117Earlier quoted context omitted.
Javascript is not simple AT ALL. It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects pro…
In fact, Javascript is so complex that one of the seminal books on it was specifically "The Good Parts", cutting down the scope of it to just the parts of the language that were considered decent and useful.
I think the distinction with JavaScript compared to other 'complex' languages is that you don't have to go beyond "The Good Parts" to achieve significant functionality, and it has become idiomatic to use the good subset.
In some respects I think if there were a well defined "Typescript, The Good Parts" I would happily migrate to that.
I do wonder if there will, one day, be a breaking fork of JavaScript that only removes things. Maybe a hypothetical "super strict" might do the job, but I suspect the degree of change might not allow "super strict" code interacting with non "super strict" easily.
BiteCode_dev has provided a pretty good summary of a lot of the issues. A lot of them have easy fixes if you are prepared to make it a breaking change.
Re: Proposal: JavaScript Structs
#118Earlier quoted context omitted.
It's on the list of languages that used to be simple, I think.
Yes, but when "the good parts" came out, half of this list was already true. There is a reason we ignore a good chunk of the language to be productive with it.
Not just half of it, the central part of it. Javascript did not grow into something huge, it started that way. A prototype based wannabe Java that accidentally (?) shipped with a full scheme included alongside. The latter of which remained mostly dormant until "the good parts" came along and put them into the (deserved) spotlight, relegating the prototype stuff from idiomatic to niche, for when you are doing something particularly clever. It's a unique mess that has lead to something no purer language could dream of.
Re: Proposal: JavaScript Structs
#119Please stop. What a nonsense. JS is a dynamic language where everything is a Hashtable. It will never be really fast as your structs won’t be in single cacheline, you won’t be able to calculate field address during compile time by pointer offsets. There’s no simd, no multithreading, no real arrays. JS is such a simple, dynamic language. It should just stay this way. Please stop bloating it with every feature that’s t…
> Please stop bloating it with every feature that’s trendy this year.
Trendy structs. Did I return to 1980? (wipes happy tear)
Re: Proposal: JavaScript Structs
#120I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry. The ones that stand out the most to me are C# and Typescript. Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are c…
I think in this specific case it's JavaScript's requirement for backwards compatibility that bloats it... but there's a lot you can ignore. Like, you can declare a variable with var, let or const but there's absolutely no reason to use var any more. I feel similarly about the proposals to introduce records and tuples: https://github.com/tc39/proposal-record-tuple ... in most scenarios you'll probably be better off us…
> there's absolutely no reason to use var any more.
So I also thought. And then I recently learned that typescript uses `var` internally for performance.
From src/compiler/checker.ts:
// Why var? It avoids TDZ checks in the runtime which can be costly.
// See: https://github.com/microsoft/TypeScript/issues/52924
/* eslint-disable no-var */
var deferredDiagnosticsCallbacks: (() => void)[] = [];