Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposal: JavaScript Structs

github.com

Post reply on HN
Print view View original

301–310 of 371 posts

Re: Proposal: JavaScript Structs

#301

Post by LegionMammal978 »

maxdamantus wrote: post #251
zarzavat wrote: post #198

Earlier quoted context omitted.

If you allow arbitrary values, what's the difference between a record and a frozen object? I thought that the whole point is to have guaranteed deep immutability, which you can't have if it's got arbitrary objects in it.

> If you allow arbitrary values, what's the difference between a record and a frozen object? The behaviour of equality. Frozen objects are already considered to have unique identities, in that `Object.freeze({}) !== Object.freeze({})` even though both objects are otherwise indistinguishable. This behaviour can't be changed and it relates to the fact that `Object.freeze(a) === a`. > I thought that the whole point is t…

Thanks for the history! Reading through the issues, I agree with you that some of the motivations against objects in records seem pretty strange. Mostly they seem to be around existing JS-written 'membranes' (related to the SES stuff mentioned above?) getting confused by primitives-containing-objects, depending on which permutation of typeof checks they use. Out of curiosity, do you think that the Shadow Realms proposal they refer to will ever go anywhere?

Otherwise, there's the argument that "x.y" syntax shan't be used to access a mutable object from an immutable record, but that just feels like the all-too-common motive of "we must ensure that users write morally-correct code (given our weird idiosyncratic idea of moral correctness), or otherwise make them pay the price for their sins".

Re: Proposal: JavaScript Structs

#302

Post by nox101 »

fergie wrote: post #253

Maybe I'm missing something, but this seems to add very little. Please correct me if I am missing something. 1) Struts are encouraging a coding style that restricts what you can do. This inflexibility is then negated by adding unsafe blocks? 2) Struts don't, as far as I can see, address any of the _actual_ weaknesses of js classes- such as not being able to create aysnc constructors. 3) The cited performance benefits…

I'm kind of with you on this. I probably didn't read enough details but it sounds like a library that abstracted over shared types arrays would already do all of this or at least solve the same problem.

I'd rather see binary struct views added to typed arrays. Ideally with a settable offset so you don't have to create a new view for every instance. That seems more useful than this middle ground that can already be poly-filled. I guess binary structs can also be poly-filled but it feels like a far more obvious speed win. Marshalling data in/out of WASM, in out of WebGPU/WebGL, parsing binary files, and sharing data across shared memory all get solved at once and with speed.

Re: Proposal: JavaScript Structs

#303

Post by ericmcer »

klysm wrote: post #160
BigJono wrote: post #157

Earlier quoted context omitted.

Yep and TS has all of that plus a gigantic layer of bullshit on top. The web development community has created the perfect environment for nobody to ever get any work done while still feeling like they're being productive because they're constantly learning minutiae.

Typescript is the best thing to happen to JavaScript since ES6

Yeah I was almost gonna say it makes this proposal feel redundant. I can enforce object shape pretty well using TS, not sure why we need another OOP like thing that tries to do the same.

Re: Proposal: JavaScript Structs

#304

Post by ralmidani »

My head is spinning after skimming the sections on shared memory, locks, mutexes, etc. Implementation and adoption would probably be a decade-long saga. Not to mention teaching folks when to use these and how to use them correctly.

In e.g. Elixir these are non-issues. Please, just give us declarative structs that are immutable by default (if they’re really needed, make constructors and mutability opt-in). Isn’t the trend already toward more FP in JS?

Re: Proposal: JavaScript Structs

#306

Post by andai »

A stricter, faster subset of JS would be very welcome, which seems to be what the unshared struct part of this proposal provides.

By the way, doesn't V8's optimizer already do something like this internally? I read one of their tech blogs back in the day that explained how they analyze the structure of objects and whenever possible, compile it to the equivalent of a C++ class.

I guess doing it explicitly makes the optimizer's job much easier -- the more guarantees you give it about what won't happen, the more optimizations it's free to make.

Re: Proposal: JavaScript Structs

#307

Post by andai »

afavour wrote: post #39

I 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.

> 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.

I think TS is a negative influence on JS, because now instead of saying "maybe we should fix the JS type system" they just say "no need to fix what's broken, people who care will just use TS anyway" (even though TS can only do so much).

On the other hand, TS mainstreamed the idea of typed JS (well, ActionScript did that decades ago, but somehow no one noticed or cared?), so it's also a positive influence?

Most people are drawn to WASM because "I can do frontend stuff without writing JS!" but for the most part that's not true, and in my experience the problems introduced by the indirection and interop, and the complexification of the mental model, and the bloating of the build system (and its fragility), were not worth it and I just switched back to TS.

So I do really wish that JS would be improved -- it remains inescapable -- especially with regard to fixing fundamental design flaws rather than just adding more shiny stuff on top.

Re: Proposal: JavaScript Structs

#308

Post by andai »

zanethomas wrote: post #130

I don't understand the need for the ever-growing list of "enhancements" to JS. Take Class for example. Class is entirely unnecessary and, essentially, tries to turn JS into a class-oriented language from its core which is object-oriented. I never create classes. I always create factory functions which, when appropriate, can accept other objects for composition. And I don't use prototypes, because they are unnecessary…

I like JS's flexibility too, but I have to point out that your object-oriented JS code is compiled into C++ classes by the v8 optimizer! (Unless you change their structure, in which case it gives up (deoptimization).)

Re: Proposal: JavaScript Structs

#309

Post by sensanaty »

pjc50 wrote: post #220
spease wrote: post #89

Earlier quoted context omitted.

I can't speak for how C#; but in C++'s case, the issue is that there's a lot of programmers who don't keep up with the language that they're using. As a result, you get a few people pushing the language ahead, who are deeply involved in its future. And then the vast majority of people are still using C++03, and it's still taught the same way as it was ~20 years ago. I think the only way to address what you're alludin…

> continually deprecate small parts of the language Did you see https://news.ycombinator.com/item?id=41788026 ? "My concern, and IMO what should be the overwhelming concern of the maintainers, is not the code that is being written, or the code that will be written, but all the code that has been written, and will never be touched again. A break like this will force lots of python users to avoid upgrading to 3.17, jet…

But they can simply continue using whatever version of Python works for them, right?

I never got this argument, personally. Sure, having to rip out a bunch of code because of lang-level changes can suck, but you also only really need to do that if you're starting a new project anyway or for whatever reason want to keep being pinned to @latest version of the lang.

If you're a researcher who uses Python 2 as a means to an end, then just stick to Py2. It's unreasonable to expect the entire python world to freeze in place so you don't have an annoying migration journey. If you need the latest Py3 features, them's just the brakes I'm afraid, eventually APIs need to change.

Re: Proposal: JavaScript Structs

#310

Post by lxe »

bre1010 wrote: post #272
lxe wrote: post #169

Earlier quoted context omitted.

Thanks. I put 37 actual proposals in here.

automatic circumsizers when

It's stage 0 for now but there are polyfills.

In .babelrc do

    {
      "presets": [
        [
          "@babel/preset-env",
          {
            "targets": {
              "esmodules": true
            },
            "include": ["es.autocirc"] 
          }
        ]
      ]
    }
Post reply on HN