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

191–200 of 371 posts

Re: Proposal: JavaScript Structs

#191

Post by devjab »

Zanfa wrote: post #178
BiteCode_dev wrote: post #64

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

And ESM vs CJS. What should be an inconsequential transition, has turned into a minefield where adding a dependency to your package.json might blow up your build system, testing library or application without warning. Literally wasted weeks of my life debugging this pile of poop that is the JS ecosystem.

Is this really a JS or a Node issue though? We have no such issues with Bun.

Re: Proposal: JavaScript Structs

#192

Post by voidr »

Most of the JavaScript developers I've encountered recently refuse to use Map, and if you dare use it, they will say that it's complicated code and premature optimisation before even making an attempt to understand it.

I feel like trying to add fast data structures into JavaScript is futile, I think at this point it would be better to make it easier for JavaScript and the browser to interface with faster languages.

The only thing I would add to JavaScript at this point is first class TypeScript support so that we can ditch the transpilers.

Re: Proposal: JavaScript Structs

#194

Post by eknkc »

jenscow wrote: post #97
leetharris wrote: post #72

Earlier quoted context omitted.

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

I came to love pattern matching so much that now when I write TypeScript I get frustrated. It is a weird balance.

Re: Proposal: JavaScript Structs

#195

Post by demurgos »

Lerc wrote: post #117
girvo wrote: post #102

Earlier quoted context omitted.

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

ESM is the closest to a major version for JS. It forces strict mode, which includes many non-backwards compatible changes [0]. Most notably, it removes the `with` statement. Other examples of removals are octal literals or assignments to undeclared variables.

[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: Proposal: JavaScript Structs

#196

Post by millipede »

intothemild wrote: post #121
adamc wrote: post #25

Earlier quoted context omitted.

Java went through this too, although there, a lot of it is part of the ecosystem. See https://chrisdone.com/posts/tamagotchi-tooling/

The java tooling is the number one thing I hate about using the language. It's all just bad. Then. You get forced into using intelij because it seems to smooth over a lot of the toolings problems with "magic". It's horrible.

Saying this as probably the biggest Java fanboy I know: they are pretty bad. Gradle is pretty much the worst build system Ive used. IntelliJ might as well be folded into the JDK, because I don't think it's possible to be productive in Java without it.

Re: Proposal: JavaScript Structs

#197

Post by kevingadd »

terandle wrote: post #173
munificent wrote: post #76

Earlier quoted context omitted.

I've been meaning to write a longer essay on this for years, but I believe the reason for this observation is different cohorts. Imagine you are a C# programmer just as C# 1.0 is released. C# is a fairly simple language at that time (and similar to other languages you already know), so you can get caught up on it fairly easily and quickly. A few years later, C# 2.0 comes out. It's got a handful of features, but not t…

Been using .net since 2.0 and nah C# has jumped the shark. Primary constructors are a very poorly designed feature that for some reason was added in the last version. The new-ish yearly release cycle I think is mostly to blame, they feel like they need to add some headline features every year but the team also, maybe due to org-chart politics, seems to not really able to make deep runtime level changes that are neede…

The emphasis on syntax sugar has a very useful side effect, which is that new language features can be used on old runtimes. To this day some of the newer C# features are usable when targeting the ancient .NET Framework 4.x, like 'ref returns'. This would not be possible if every new language feature was paired with runtime-level changes. (Many new language features do come with changes to the runtime and BCL). I support a bunch of people who use NET4x to this day and I'm able to write modern C# for that target thanks to the language and compiler being designed this way.

A lot of stuff is also designed to be independent of library changes - IIRC for example if you use nullability, the compiler will emit the Nullable attribute's definition into your .dll as a hidden class, so that your library will work even on older versions of the runtime with older base class libraries. Doing this complicates the compiler (and adds a tiny, tiny amount of bloat to your dll) but means that more people can adopt a new feature without having to think about upgrading their SDK or runtime.

My personal opinion is that if a change can be done adequately entirely at the compiler level without runtime/library changes, it should be done there. It allows the people working on the language, libraries and runtime to iterate independently and fix problems without having to coordinate across 3 teams.

Re: Proposal: JavaScript Structs

#198

Post by zarzavat »

sjrd wrote: post #32
AprilArcus wrote: post #12

Earlier quoted context omitted.

I don't think R&T will ever ship at this point, since the browser vendors are apparently unwilling to absorb the complexity that would be required to add new primitive types with value semantics.

I've been following that proposal closely, and even (unsuccessfully) tried to contribute suggestions to it. I think what's killing it is that the authors of the proposal won't accept arbitrary values as fields of R/T, but all the potential users are saying that they won't use R/T if they can't put arbitrary values in them. The reluctance of the authors is due to backward compatibility with sandboxed "secure" JavaScri…

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.

Re: Proposal: JavaScript Structs

#199

Post by awesomeMilou »

pier25 wrote: post #55
Jcampuzano2 wrote: post #6

JS devs - do everything but write in another language challenge level: Impossible.

There's a lot of that, certainly, but there are legitimate reason to use JS/TS. Frontend is an obvious one but also using services like CF Workers or Deno Deploy which are optimized for V8. You're going to get better uptime and lower latency than anything else at that cost.

Serious question, when would you want to use synchronization primitives in the frontend? I've seen the discussion revolve around service worker / web worker usage, but I think sharing ressources between a worker and the main thread has been discussed in the past and has ultimately been abandoned for security reasons.

Re: Proposal: JavaScript Structs

#200

Post by [deleted] »

branko_d wrote: post #182
leetharris wrote: post #18

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

And here is the obligatory quote from Bjarne Stroustrup: "There are only two kinds of languages: the ones people complain about and the ones nobody uses."

[deleted]
Post reply on HN