When reading the proposal title, I thought that this is for interop with WASM. Having fixed-size structs where every field has a wasm-related type would be beautiful for interop. Just a wasm function can just return or receive an instance of a typed struct. No more reading the result using a DataView or something like that. We have to use something like BufferBackedObject for that.
Proposal: JavaScript Structs
91–100 of 371 posts
Re: Proposal: JavaScript Structs
#92I 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…
It doesn't help how arcane the TS documentation is. Important docs live as frozen-in-amber changelog entries; huge tracts of pages "deprecated" yet still #1 on Google.
Google "typescript interfaces." #1 is a page that has been deprecated for years. How did this happen?
Re: Proposal: JavaScript Structs
#93Earlier quoted context omitted.
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…
> but there's absolutely no reason to use var any more Naw, var has function scope and hoisting, both of which are useful.
You should probably accompany this kind of claim with a code snippet to show what we're missing out on.
Re: Proposal: JavaScript Structs
#94I 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…
> When Typescript first came out, it was great. Types in Javascript are something we've always wanted. Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it!
TypeScript today can be written the same way that TypeScript was when it first started to become popular. Yes there are additions all the time, but most of them are, as you observe, irrelevant to you. They're there to make it possible to type patterns that would otherwise be untypeable. That matters for library developers, not so much for application developers.
To the extent there's a barrier to entry, it seems largely one that can be solved with decent tutorials pointing to the simple parts that you're expected to use in your applications (and a culture of not overcomplicating things in application code).
Re: Proposal: JavaScript Structs
#95I 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…
This is why always say the true beginner programming language is C. Stupid easy to learn, have some loops, have some conditions, make some memory allocations. You will learn about the fundamentals of computing as well, which you might as well ignore (unknowingly) if you start with something like JavaScript (where is this data living in my computer?).
The problem with C is that beginners generally want to build something.
"Oh, you want to build an app that does X? Well, first learn C for three months and then switch to Python/Javascript/etc. to build the thing that motivated you in the first place" doesn't fly.
Re: Proposal: JavaScript Structs
#96I 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 also don’t know how to refine my thought but it’s something along the lines of:
The people who are in a position to decide what features get added to a language are usually top experts and are unlikely to have any reasonable perspective on how complicated is too complicated for the rest of us.
If you live and breathe a language, just one more feature can seem like a small deal.
I think it becomes much more reasonable when that one more feature enables an entire set of capabilities and isn’t just something a library or an existing feature could cover.
Re: Proposal: JavaScript Structs
#97Earlier quoted context omitted.
Do you have examples of unreadable C#? The language didn’t change much IMHO. You have new features, like records, but C# code looks pretty much like what I started with in 2009
Now that I'm thinking about it, most of it is probably .NET bloat instead of C# bloat, but a few examples would be global usings, file scoped namespaces, records, target-typed new expressions, null coalesce assignments, etc. It's nothing huge, but combined with .NET bloat it can be overwhelming when you haven't worked in .NET for a while.
and pattern matches, primary constructors, range operator, switch expressions, etc. it does add up
Re: Proposal: JavaScript Structs
#98 𝅘𝅥𝅮𝅘𝅥𝅮𝅘𝅥𝅮𝅘𝅥𝅮
They've got decorators, record tuples, shadow realms, and rich rekeying
Dynamic imports, lazy modules, async contexts now displaying
JSON parsing, destructure privates, string dedenters, map emplacers
Symbols pointing, pipe operators, range iterators, code enhancers
Eager asyncs, resource tracking, strict type checks, and error mapping
Phase imports, struct layouts, buffering specs for data stacking
Temporal zones, buffer edges, chunking calls for nested fragments
Explicit locks, throw expressions, float16s for rounding segments
Base64 for typed arrays, joint collections, parsing pathways
Atomic pauses, void discarding, module scopes for seamless relays
Math precision, tuple locking, module imports, code unlocking
Source phase parses, regex bounds, iterators kept from blocking
Iterating, winding modules, atomic gates with locks unbound
Helper methods, contexts binding, async helpers, code aligning
Soffit panels, circuit brakers, vacuum cleaners, coffee makers
Calculators, generators, matching salt and pepper shakers
I can't wait, (no I) I can't wait (oh when)
When are they gonna open the door?
I'm goin' (yes I'm) goin', I'm a-goin' to the
ECMAScript StoreRe: Proposal: JavaScript Structs
#99I 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…
I agree; the point of a struct type would be to allow a compact memory representation, and you're not going to get it if your constructor can do if(someArg) { a = 1; } else { a = 1; b = 2; }.
You don't strictly need known/consistent types, but it sure helps, since otherwise everything needs to be 8 bytes.
I don't think a way to read into and out of ArrayBuffers is possible, since these can have pointers in them. I think it needs a StructArray class instead, so there's a way to actually make a compact memory array out of all of this.
Re: Proposal: JavaScript Structs
#100I 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…
Do you have examples of unreadable C#? The language didn’t change much IMHO. You have new features, like records, but C# code looks pretty much like what I started with in 2009
This one threw me off when I first saw it:
(int x, string y) = (default, default);