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

321–330 of 371 posts

Re: Proposal: JavaScript Structs

#321

Post by randomdata »

neonsunset wrote: post #275
totallykvothe wrote: post #170

Earlier quoted context omitted.

.NET/Java are only as performant as Go if you completely ignore memory usage and focus only on time.

OpenJDK and .NET compilers run circles around Go one. It's not even close. The second you go beyond "straight-line" code where function body has limited amount of locals and does not make much calls, the difference becomes absolutely massive. Go also does not do any sort of "advanced" devirtualization that is bread and butter of both to cope with codebase complexity and inevitable introduction of abstractions. Hell,…

> Go also does not do any sort of "advanced" devirtualization

Depends on the implementation. gc doesn't put a whole lot of effort into optimization, but it isn't the only implementation. In fact, the Go project insists that there must be more than one implementation as part of its mandate.

Re: Proposal: JavaScript Structs

#322

Post by MarkusQ »

debit-freak wrote: post #285
chii wrote: post #239

Earlier quoted context omitted.

> reasons to believe JS is simple it's because people are talking past each other, and that's because people are using language wrong, and are merely talking past each other. The word simple is often used to mean "easy" or "familiar". Simple is very different from easy, and familiar things are easy but doesn't have to be simple at all. javascript is not simple, but it is easy.

> using language wrong There is no wrong use of language; there's just people who don't bother to communicate well in the most effective language available. In this case you could simply cohere the two viewpoints since you have insight rather than blaming one party and calling them wrong (...which is wrong).

> There is no wrong use of language

Thy can'n't sirus be. language works only farso as withbreathings we follow, Leading paths through gardens means fail, and bloom'st chaos wear not!

Re: Proposal: JavaScript Structs

#323

Post by neonsunset »

randomdata wrote: post #321
neonsunset wrote: post #275

Earlier quoted context omitted.

OpenJDK and .NET compilers run circles around Go one. It's not even close. The second you go beyond "straight-line" code where function body has limited amount of locals and does not make much calls, the difference becomes absolutely massive. Go also does not do any sort of "advanced" devirtualization that is bread and butter of both to cope with codebase complexity and inevitable introduction of abstractions. Hell,…

> Go also does not do any sort of "advanced" devirtualization Depends on the implementation. gc doesn't put a whole lot of effort into optimization, but it isn't the only implementation. In fact, the Go project insists that there must be more than one implementation as part of its mandate.

GoGC is the fastest overall implementation and the one that is being used in >95% cases, with the alternatives not being-up-to-date and producing slower code, aside from select interop scenarios.

Until this changes, the "Depends on the implementation" statement is not going to be true in the context of better performance.

Re: Proposal: JavaScript Structs

#324

Post by zanethomas »

wruza wrote: post #311
zanethomas wrote: post #293

Earlier quoted context omitted.

I wonder why it seems natural to you? I'm guessing JS wasn't your first language and you didn't learn the power of composition instead of classes.

Because I think in objects (non-strictly related groups of data and methods) and it’s natural to how my business processes work. Light OOP creates neither translation nor maintenance layers to it. See https://news.ycombinator.com/item?id=41808034 I'm guessing JS wasn't your first language Good intuition. My first language was basic, 8080 asm, x86 asm, pascal, C, perl, python, haskell (most useless), lua, objc. Js/ts…

:)

I started with 6800 machine language. Then c, smalltalk, scheme and etc.

Rather than spend a lot of time and botch a comparison between classes and factory functions I'll link you to an article.

He went further, introducing something he calls stamps, but I found them to be awkward the only time I tried to use them.

https://medium.com/javascript-scene/javascript-factory-funct...

Re: Proposal: JavaScript Structs

#325

Post by kinjba11 »

neonsunset wrote: post #275
totallykvothe wrote: post #170

Earlier quoted context omitted.

.NET/Java are only as performant as Go if you completely ignore memory usage and focus only on time.

OpenJDK and .NET compilers run circles around Go one. It's not even close. The second you go beyond "straight-line" code where function body has limited amount of locals and does not make much calls, the difference becomes absolutely massive. Go also does not do any sort of "advanced" devirtualization that is bread and butter of both to cope with codebase complexity and inevitable introduction of abstractions. Hell,…

Yep, for expert driven projects, such as Go and C#, it is nearly always a case of "everything is a tradeoff".

Another good article for comparing GC between Go and C# https://medium.com/servicetitan-engineering/go-vs-c-part-2-g...

Re: Proposal: JavaScript Structs

#326

Post by colejohnson66 »

yakshaving_jgt wrote: post #288
conartist6 wrote: post #278

Earlier quoted context omitted.

"let" is one of the good parts. Just don't use const or var.

Why is it? Why is block scoping useful?

Because it's how almost every C-syntax-like language works. JavaScript is the odd one out.

Re: Proposal: JavaScript Structs

#327

Post by yakshaving_jgt »

colejohnson66 wrote: post #326
yakshaving_jgt wrote: post #288

Earlier quoted context omitted.

Why is it? Why is block scoping useful?

Because it's how almost every C-syntax-like language works. JavaScript is the odd one out.

I’d prefer to just embrace it. Keep the language small. Prototypical inheritance works just fine. There’s enough in The Good Parts to get all the work done.

Re: Proposal: JavaScript Structs

#328

Post by dvlsg »

ralmidani wrote: post #304

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 t…

There's technically a proposal to add immutable lists and records floating around somewhere. I think it's kind of old at this point. I'm still hoping it makes it through, though.

Re: Proposal: JavaScript Structs

#329

Post by debit-freak »

MarkusQ wrote: post #322
debit-freak wrote: post #285

Earlier quoted context omitted.

> using language wrong There is no wrong use of language; there's just people who don't bother to communicate well in the most effective language available. In this case you could simply cohere the two viewpoints since you have insight rather than blaming one party and calling them wrong (...which is wrong).

> There is no wrong use of language Thy can'n't sirus be. language works only farso as withbreathings we follow, Leading paths through gardens means fail, and bloom'st chaos wear not!

I don't think that's a serious barrier in this case. The above poster just would rather dismiss a statement rather than give it serious thought. It's easier to simply claim to know the one true meaning of "simple" rather than actually communicate effectively.

Re: Proposal: JavaScript Structs

#330

Post by modeless »

syg wrote: post #236
modeless wrote: post #4

Huh, 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…

To be more precise, aligned to whatever size such that you can guarantee field writes that don't tear. Pointer-aligned is a safe bet. 4-byte aligned should be okay too on 64bit architectures if you use pointer compression like V8 does. What kind of types did you have in mind? Machine integers and "any" (i.e., a JS primitive or object)? And yes, in browsers this will be gated by cross-origin isolation.

If the memory layout is fixed and fields are untyped then every field must be at least 8 bytes to potentially hold a double precision floating point value. There would clearly be value in adding typing to restrict field values to 1 or 2 or 4 byte integers to allow packing those fields. But I can see that it would add complexity.
Post reply on HN