[HN Gopher] Proposal: JavaScript Structs
___________________________________________________________________
Proposal: JavaScript Structs
Author : Kholin
Score : 109 points
Date : 2024-10-09 12:15 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| whizzter wrote:
| Not sure this is a good idea or not, for one it'd be awesome for
| doing performance oriented and threaded code in JS/runtimes, the
| idea seems related to how C# struct's already work (and tuples
| under the hood). Interop with WASM code might also be simplified
| if struct-like access was a built-in.
|
| The bad is that people wouldn't necessarily be prepared for their
| semantics (are they value or reference based?), how to shared
| prototypes between environments (mentioned as problem in the
| proposal itself), not entirely sure if this proposal would add to
| the complexity vs security for spectre like attacks.
|
| It'd be useful, but worth it is another question? (And would all
| major players see interest in it? esp considering that it'd need
| to be "JSzero" level propsal if they go in that direction. (There
| was a post here a few days ago about layering runtimes with JS0
| being the core with everything else being syntax transforms on
| top).
| egeozcan wrote:
| Huh, I thought that most work that used to use workers switched
| to Webassembly.
|
| Talking about JS proposals, I'm looking forward to this one:
| https://github.com/tc39/proposal-record-tuple
|
| Records and tuples can make a lot of logic much more easier to
| read, and way less fragile. Not sure how they would play together
| with the shared structs though.
| AprilArcus wrote:
| 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.
| sjrd wrote:
| 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" JavaScript (SES). That
| said, every other language in existence that has immutable
| structs and records allows to put arbitrary values in them.
|
| So it's at a standstill, unfortunately.
| modeless wrote:
| 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
| difficult to use.
| Jcampuzano2 wrote:
| JS devs - do everything but write in another language challenge
| level: Impossible.
| bastawhiz wrote:
| Call me when browsers support another language. What are we
| going to use? CSS?
| slashdave wrote:
| Well... sort of?
|
| https://emscripten.org
| bastawhiz wrote:
| Which compiles to...
| jitl wrote:
| WebAssembly
| modeless wrote:
| wasm
|
| "but wasm has to call JavaScript to use browser APIs" WasmGC
| is shipped in Chrome and Firefox and enabled by default in
| WebKit nightly
| nuz wrote:
| WasmGC is just garbage collection? Not browser APIs
| johnfn wrote:
| Let me know when WASM has a dev workflow that gets a change
| to your browser 1/10th as fast as Vite + TypeScript +
| React.
| postalrat wrote:
| WASM has to call javascript to do really anything.
| Arch485 wrote:
| Oh yeah. CSS is turing complete, after all!
| hyperhello wrote:
| Lots of programmers only really feel comfortable in C++ because
| it's the language they were trained in.
| lovethevoid wrote:
| Got it. Writing in Typescript.
| pier25 wrote:
| 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.
| connicpu wrote:
| The 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 structs are going to be
| adopted I think they probably need to be immutable after
| creation, or at the very least only modified with atomic
| operations.
| jsheard wrote:
| Isn't it really no different to what you can already do with
| WASM threads though? C/C++ or unsafe Rust compiled to WASM can
| have data races, but the worst it can do is crash the WASM
| instance, just like how you can have use-after-frees or out-of-
| bounds array accesses in WASM but the blast radius is confined
| to the instance.
|
| Granted, a JS runtime is significantly more complex than a WASM
| runtime so there is more room for error.
| modeless wrote:
| SharedArrayBuffer can already do data races on the web. And
| they can't crash the browser or computer.
| pjmlp wrote:
| That was gone with GPU access and WebAssembly.
| jitl wrote:
| The unsafe block doesn't actually do anything at all. It's just
| pointless cargo-cutling from Rust.
| bastawhiz wrote:
| I 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 layout memory and serialization go hand in
| hand. Obviously a lot of unanswered questions here but that's the
| point of the process.
|
| The unsafe block stuff, frankly, seems like it should be part of
| a separate proposal.
| jtolmar wrote:
| 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.
| weego wrote:
| It's hard to take anyone concerned about the 'performance
| ceilings' in javascript object creation seriously at this point.
| skrebbel wrote:
| why?
| aardvark179 wrote:
| Give developers an alternative to classes that favors a higher
| performance ceiling and statically analyzability over
| flexbility.
|
| Is an entirely reasonable goal. Object shape in JS tends to go
| through a fixed pattern of mutation immediately after
| construction and although that can sometimes be analysed away
| by the JIT there are a lot of edge cases that can make that
| tricky.
|
| You may not care, but I bet almost everybody who has actually
| worked on a JS engine does, and has good reasons for doing so.
| leetharris wrote:
| 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 constantly
| adding features. After all, it is their job. They are
| incentivized to keep making it more complex.
|
| The first time I ever used C# was probably version 5? Maybe?
| We're on version 12 now and there's so much stuff in there that
| sometimes modern C# code from experts looks unreadable to me.
|
| One of the reasons I have so much fun working in node/Javascript
| these days is because it is simple and not much has changed in
| express/node/etc for a long time. If I need an iterable that I
| can simply move through, I just do `let items = [];`. It is so
| easy and hasn't changed for so many years. I worry that we
| eventually come out with a dozen ways to do an array and modern
| code becomes much more challenging to read.
|
| 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!
|
| This is probably just old man ranting, but I think there's
| something there. The old version I used to debate about was C vs
| C++. Now look at modern C++, it's crazy powerful but so jam
| packed that many people have just gone back to C.
| pjmlp wrote:
| C23 has just been ratified, and C2y has already quite a few
| proposals.
|
| Programming languages are like any other software product,
| evolution or stagnation.
|
| Eventually they might implode, however whatever comes after
| will follow the same cycle yet again.
| seanw444 wrote:
| And branches [1] of C are still spawning and gaining
| traction, because C++ is perceived as overkill.
|
| [1]: https://github.com/c3lang/c3c
| throw49sjwo1 wrote:
| > And nobody uses most of it!
|
| Everybody who does Express, React, or any other popular
| advanced libraries with TypeScript is using these features.
| Some things are simply more useful to libraries than line of
| business code - that's fine. The line of business code is much
| better thanks to it.
| nosefurhairdo wrote:
| Yeah I was confused by this point as well. Especially because
| many of the recent Typescript releases are just improving
| performance or handling more cases (without needing to learn
| new syntax).
| tannhaeuser wrote:
| React and Expressjs predate typescript, Expressjs
| considerably so.
| throw49sjwo1 wrote:
| Doesn't matter, I'm talking about the type definitions -
| @types/react, @types/react-dom and @types/express.
| authorfly wrote:
| No, those are optional for the enduser to ever encounter.
| throw49sjwo1 wrote:
| I never said it's required. The typings are really useful
| if you want to use these libraries "with TypeScript" as I
| said in my first comment... The typings are the whole
| point - that's where the advanced type features are used,
| and every user benefits - their own code can be much
| simpler and safer thanks to it.
| anon7000 wrote:
| For sure! In a basic API endpoint, I don't need advanced
| typescript features.
|
| But if I'm writing a module that a lot of other consumers in
| the codebase will use, and I want to make their lives easy, I
| might use a lot of advanced TS features to make sure than
| type safety & inference works perfectly within the module.
| Whoever consumes it can then rely on that safety, but also
| the convenience. The module could have some convoluted types
| just to provide really clean and correct auto-complete in a
| certain method. But most people don't need to worry about how
| that works
| leetharris wrote:
| > Everybody who does Express, React, or any other popular
| advanced libraries with TypeScript is using these features.
|
| This is very true and my original post was short sighted. You
| could, of course, make most upstream dependencies without
| modern language features. However, their complex jobs get
| much easier with these features.
|
| Downstream, business logic is much easier to implement
| without these features compared to complex, low level
| functionality.
| adamc wrote:
| Java went through this too, although there, a lot of it is part
| of the ecosystem. See https://chrisdone.com/posts/tamagotchi-
| tooling/
| intothemild wrote:
| 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.
| afavour wrote:
| 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 using records
| rather than objects, and maybe that's what folks will end up
| doing.
|
| But boy does it all get confusing.
|
| > 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!
|
| I'm not so sure about that. I think we end up _consuming_ a lot
| of these features in the TS types that get published alongside
| libraries. We just don 't know it, we just get surprisingly
| intuitive type interfaces.
| thot_experiment wrote:
| > but there's absolutely no reason to use var any more
|
| Naw, var has function scope and hoisting, both of which are
| useful.
| afavour wrote:
| Not in a sensible codebase
| hinkley wrote:
| My job isn't to be infatuated with your code. It's to get
| through your code and get stories done.
|
| People don't really get better at handling the complexity
| of large code bases. We are fundamentally the same organic
| matter that existed prior to the first computer coming into
| existence. So as code bases and library bases grow larger
| and larger, they need to be proportionately easier to read
| or even ignore.
|
| Your code needs to be dead boring 90% of the time,
| otherwise you're imposing on your coworkers. And using
| variables before they're declared is just shitty behavior.
| thot_experiment wrote:
| Sure and I'd accept the weaker claim that "there's no
| reason to use var in a production codebase touched by
| many people"
| hombre_fatal wrote:
| You should probably accompany this kind of claim with a
| code snippet to show what we're missing out on.
| int_19h wrote:
| Useful for what?
| leetharris wrote:
| > I'm not so sure about that. I think we end up consuming a
| lot of these features in the TS types that get published
| alongside libraries. We just don't know it, we just get
| surprisingly intuitive type interfaces.
|
| Very true. As a downstream consumer, I can do all business
| logic in ancient, simple languages. But I'm sure these things
| are extremely nice to have for the more complicated upstream
| dependencies I rely on.
| hinkley wrote:
| When they made class declarations imply strict, I thought
| that was a pretty wise move. But it might have been good if
| they applied more limitations than that, made them super-
| strict.
|
| Such as for instance making 'var' not work in class
| declarations.
| afavour wrote:
| ES modules too would have been a great opportunity to cut
| out some of the outdated cruft.
| dunham wrote:
| > 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)[] = [];
| dartos wrote:
| At least typescript tooling hasn't changed. It was a pain to
| set up when it came out and it still is.
|
| At least we moved past webpack mostly.
| eddd-ddde wrote:
| 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?).
| n_plus_1_acc wrote:
| How can you teach C when there's no list of UB, there's
| sometimes no agreement on how to read the standard, and loads
| of non-standard-compliant compilers.
| bobthepanda wrote:
| Plenty of universities teach C every day even if that means
| specifying a compiler, and usually it's a very boring
| compiler that gets chosen
| lukan wrote:
| And this is why I always say, we have a world full of
| computer consumers, not programmers.
|
| C as a first language is only easy, if you happen to bring
| along a deep technical interest (and pre knowledge) about the
| "technical fundamentals of computing".
|
| Most people do not have that.
|
| Tell them about heap and memory allocations and you will get
| a blank stare.
|
| But show them some simple functions, to make some flashing
| graphics on the sceen - and they will have fun. And can learn
| the basics of programming at the same time.
|
| And then you can advance more low level, for those who feel
| the call. But please don't start with it, unless you have
| some geeky hacker kids in front of you who really want to
| learn computers. Then C makes sense. For "normal" people not
| so much.
| hombre_fatal wrote:
| 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.
| GordonS wrote:
| Aye, especially nowadays with the ubiquity of computing -
| "hello world", or console apps in general, aren't the most
| enticing of projects anymore.
| int_19h wrote:
| From that perspective, something like Pascal or Modula-2 is
| much better - you get all the same stuff but no footguns.
| pier25 wrote:
| > _or more performant_
|
| Obviously then can't make TS more performant (since it doesn't
| execute) but C# is very performant and even surpasses Go in the
| TechEmpower benchmarks.
| leetharris wrote:
| Absolutely. I love C# and .NET, they are incredible and very
| fast. I just meant to say that they aren't only focused on
| performance, but also focused on new features.
|
| One of the best things .NET did was adding minimal APIs in
| .NET 6 (I think) that are more like Express. They removed a
| lot of boilerplate and unnecessary stuff, making it easier to
| start building an API.
| egnehots wrote:
| Try Go. Go is really stable as a language and have a very small
| core feature set.
| leetharris wrote:
| This is easily the most appealing thing to me about Go. I
| learned Go through the "Learn Go with Tests" way and I had a
| ton of fun.
|
| It is hard for me to recommend using Go internally since
| .NET/Java are just as performant and have such a mature
| ecosystem, but I crave simplicity in the core libraries.
|
| Here's the link for anyone considering learning Go:
| https://quii.gitbook.io/learn-go-with-tests
| dgellow wrote:
| 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
| leetharris wrote:
| 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.
| jenscow wrote:
| and pattern matches, primary constructors, range operator,
| switch expressions, etc. it does add up
| francisofascii wrote:
| This one threw me off when I first saw it:
|
| (int x, string y) = (default, default);
| BiteCode_dev wrote:
| 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 proxies, counter-intuitive array and
| mapping manipulations, lots of different ways to create said
| arrays and mappings, very rich destructuring, so many
| weirdnesses on parameter handling, multiple ways to do imports
| that don't work in all contexts, exports, string concatenation
| + string interpolation, no integer (but NaN), a "strict mode",
| two versions of comparison operators, a dangerous "with"
| keyword, undefined vs null, generators, sparse arrays, sets...
|
| It also has complex rules for:
|
| - scoping (plus global variables by default and hoisting)
|
| - "this" values (and manual binding)
|
| - type coercion (destroying commutativity!)
|
| - semi-column automatic insertion
|
| - "typeof" resolution
|
| On top of that, you execute it in various different
| implementations and contexts: several browser engines and
| nodejs at least, with or without the DOM, in or out web
| workers, and potentially with WASM.
|
| There are various versions of the ECMA standard that changes
| the features you have access to, unless you use a transpiler.
| But we don't even touch the ecosystem since it's about the
| language. There would be too much to say anyway.
|
| There are only two reasons to believe JS is simple: you know
| too much about it, or you don't know enough.
| nwienert wrote:
| This is true, but what's also true is using biome or eslint
| more than half of your complaints are gone. JS has always had
| bad parts, but today it's a lot easier to avoid them thanks
| to linters. And if you do stay in the good parts, it's my
| favorite language, for many reasons.
|
| That said, I hate the constant stuffing of features (though
| not this one which is much needed), more stuff around JS like
| WebComponents, or CSS adding a ton of sugar.
| BiteCode_dev wrote:
| I think what saves JS, like Python, is that despite the
| modern complexity, you can start to be productive in a few
| days with just the essentials and learn the rest with a
| smooth curve, slowly as you progress.
| liveoneggs wrote:
| It's on the list of languages that _used_ to be simple, I
| think.
| BiteCode_dev wrote:
| 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.
| usrusr wrote:
| 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.
| wk_end wrote:
| I feel like a large slice of JS's complexity comes from
| footguns you aren't really supposed to use anymore; whereas
| with C# the complexity feels quite layered,
| multiparadigmatic, something-for-everyone, syntactic-sugary.
| But I probably know too much about JS and not enough about
| C#.
| BiteCode_dev wrote:
| Well, all the people that used JS 15 years ago followed
| Douglas Crockford advice very much to heart.
| leetharris wrote:
| Hmm, I understand what you mean. But I think there's a
| difference between complexity and optionality / versatility.
|
| For example, it has different ways to declare functions
| because assignment is generally consistent (and IMO easy to
| understand) and the "simplicity" of Javascript allows you to
| assign an anonymous function to a variable. However, you can
| also use a standard function declaration that is more
| classic.
|
| But I do understand what you're saying. If anything, I think
| it's generally in agreement with my feelings of "Javascript
| doesn't need to be more complex."
|
| > There are only two reasons to believe JS is simple: you
| know too much about it, or you don't know enough.
|
| This is hilarious and probably true. I think I am the former
| since I've been working with it for 20+ years, but I also
| think there's a reason it's the go-to bootcamp language
| alongside Python.
| BiteCode_dev wrote:
| I do appreciate the modern features a lot personally, and
| the fact they have been added without breaking the world.
| Interpolation, spreading, map and arrow functions are a
| huge usability boon. Plus I'm glad I can use classes and
| forget that prototypes ever existed.
|
| But I train beginners in JS and boy do I have to keep them
| in check. You blink and they shoot their foot, give the
| pieces to a dog that bite them then give them rabbies.
| girvo wrote:
| 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.
| Lerc wrote:
| 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.
| otteromkram wrote:
| JavaScript is simple in comparison to other languages. Not
| many people would disagree.
| carlosrg wrote:
| Every programming language attempts to expand until it becomes
| C++. Those languages which cannot so expand are replaced by
| ones which can.
| goatlover wrote:
| Go will resist this as long as possible.
| munificent wrote:
| 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 too much for you to
| absorb. Likewise C# 3.0, 4.0, etc. As long as you stay on the
| C# train, the rate of new features does not exceed the rate
| that you can learn them.
|
| Years later, another person comes along and is new to C#, which
| is now at version 5.0. They are presented with a huge sprawling
| language and they have to learn nearly all of it at once to
| deal with codebases they are contributing to. It's a nightmare.
| They long for a language that's actually, you know _simple_.
|
| So maybe they find some other newer language, Foo, which is at
| 1.0. It's small and they learn the whole thing. After a couple
| of years of happy productive use, they realize they would be a
| little _more_ happy and productive if Foo had just one or two
| extra little features. They put in a request. The language team
| wants happy users so they are happy to oblige. The user is
| easily able to learn those new features. And maybe some other
| Foo users want other new things. 2.0 comes out, and they can
| keep up. They can stay on the train with 3.0, 4.0, etc.
|
| They never explicitly _asked_ for a complex language, but they
| have one and they 're happy, because they've mastered the whole
| thing over a period of years. They've become part of the
| problem that bothered them so much years ago.
|
| Fundamentally, the problem is that existing users experience a
| programming language as the _delta_ between the latest version
| and the previous one. New users experience a programming
| language as the total sum of all of its features (perhaps minus
| features it has in common with other languages you already
| know). If you assume users can absorb information at a certain
| fixed rate, it means those two cohorts have very different
| needs and different experiences.
|
| I don't think there's a silver bullet. The best you can hope
| for is that a language at 1.0 has as few bad ideas as possible.
| But no one seems to have perfect skill at that.
| spease wrote:
| 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 alluding to is to
| continually deprecate small parts of the language, so that
| upgrading is manageable for active codebases. And you
| probably have to be really aggressive about pushing this
| forward, because there will always be excuses about why you
| should hold back _just this one time_ and this _one feature_
| is an exception that needs to be held back _just a little bit
| longer_.
|
| But in the long run, if you don't force people to change a
| little bit continuously, it will become a big enough issue to
| split the ecosystem. See python2 to python3. Or you end up
| forced into supporting bad practices for all eternity, like
| C++. And having to take them into account for every. Single.
| New. Feature.
|
| Further raising the barrier to entry to participation in
| developing the language to people who are completely focused
| on its development and have unusual mastery of it, who can't
| identify with the people struggling with its complexity.
|
| If not at the technical level, then at the business level,
| where people _definitely_ don 't have the time to understand
| why it'd be safer for the go-to heap allocation method should
| return a scoped pointer instead of a raw pointer.
|
| Unfortunately, this probably is only viable for strongly-
| typed languages like C#; for loosely-typed languages like
| Python, the risk of iterative changes is that if someone
| moves a codebase several generations ahead at once, it'll
| introduce lots of subtle changes that'll only become obvious
| once certain codepaths are exercised...and given how bad
| testing coverage is for a lot of software, that probably
| risks breakages only occurring once it's deployed, that are
| nontrivial to discern via reviews or even static analysis.
| johnfn wrote:
| Something about OP didn't strike me quite right, but your
| explanation here really nails it, I think. Especially because
| I can see that I'm in quite an old JS cohort - and quite
| happy with the language as a result - but if I were to start
| coding in JS yesterday I think I would gnash my teeth and
| tear out my hair.
| iainmerrick wrote:
| This is quite a compelling story, but thinking about it, I
| don't fully agree.
|
| There's more than one language that I initially disliked,
| and only learned to like after some of (what I saw as) the
| glaring flaws were fixed. After they added more features!
|
| For one, Objective-C. I didn't like it at all until they
| added ARC, removing the need for manual addRef / release
| everywhere. After that, coming to the language pretty late,
| I came to like Obj-C quite a lot.
|
| JavaScript is another one. For a long time I thought it was
| an awful language and avoided using it, but a few things
| have brought me round and now I really like it:
|
| - modules
|
| - async/await
|
| - TypeScript, if you'll allow that as a "JavaScript
| feature"
|
| I even quite like JS classes, although I could live without
| them.
|
| Simplicity is good, but power and expressiveness are also
| good.
| lelandfe wrote:
| 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?
| hsbauauvhabzb wrote:
| AWS has that issue too - v1 documentation takes precedence
| over v2, the same with bootstrap, too. I suspect google
| algorithms don't quite understand deprecation / latest
| version prioritisation.
| lolinder wrote:
| > 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).
| Waterluvian wrote:
| 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.
| int_19h wrote:
| For many languages these days, evolution happens in public,
| and you can look at those discussions and see how this
| sausage is made. If you do it for C#, if anything, the
| pattern is that relatively inexperienced users are the ones
| who propose features (to make some specific pet peeve of
| theirs easier), while the more experienced folk and
| _especially_ the language designers who make the final call
| aggressively push back, point out corner cases, backwards
| compatibility, maintenance burden etc.
| MathMonkeyMan wrote:
| What did Bjarne Stroustrup supposedly say? There are two kinds
| of programming languages: the ones everybody complains about,
| and the ones nobody uses.
|
| I'll put on my Scheme hat and say "with hygienic macros, people
| can add whichever language features they want." Maybe Rust is a
| good experiment along those lines: C++ with hygienic macros.
|
| Everything that people keep using grows into a monster of
| complexity: programming languages, software, operating systems,
| law. You must maintain backward compatibility, and the urge to
| add a new feature is too great. There's a cost with moving to
| the new thing -- let's just put the new thing in the old thing.
| azangru wrote:
| > it has a huge barrier to entry
|
| You don't have to use every feature of the language. Especially
| not when you are just learning.
|
| > 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!
|
| Exactly. But no-one seems to be arguing that typescript has a
| huge barrier to entry.
| breadwinner wrote:
| 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.
| neonsunset wrote:
| > sometimes modern C# code from experts looks unreadable to me
|
| This is a culture issue and has always existed in C#, Java and
| C++ communities sadly (and I'm seeing this now with TS just as
| much, some Go examples are not beacons of readability either, I
| assume other languages suffer from this similarly).
|
| In the past, people abused BinaryFormatter, XML-based DSLs,
| occasionally dynamic, Java-style factories of factories of
| factories, abuse of AOP, etc. Nowadays, this is supplanted by
| completely misplaced use of DDD, Mediatr, occasional AutoMapper
| use (oh god, at least use Mapperly or Mapster) and continuous
| spam of 3 projects and 57 file-sized back-ends for something
| that can be written under ~300 LOC split into two files using
| minimal API, records and pattern matching ( _with_ EF Core
| even!).
|
| Neither is an example of good code, and the slow but steady
| realization that simplicity is the key makes me hopeful, but
| the slow pace of this, and new ways to make the job of a
| developer and a computer more difficult that are sometimes
| introduced by community and libraries surrounding .NET by MS
| themselves sour the impression.
| PedroBatista wrote:
| I mean.. After ES6 with classes what is JavaScript anyway? Just
| bring Structs too, the more the merrier.
| tengbretson wrote:
| Nahhh
| digger495 wrote:
| They should just go write golang, if this is what they want.
| afavour wrote:
| 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.
| akira2501 wrote:
| 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.
| szastamasta wrote:
| Please 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 trendy
| this year. We already have classes that we didn't need. We don't
| need structs for sure.
| tantalor wrote:
| High performance applications are already being written that
| depend on features like shared memory, but because the language
| has poor support for them then developers have to use ugly
| workarounds. This proposal solves that with built-in support.
|
| >It should just stay this way
|
| Counterpoint: JS has been evolving significantly, look at ES6
| and ES8 in particular if you need help finding examples.
| rty32 wrote:
| Exactly. Without new features and syntaxes people would still
| be doing MyClass.prototype.method = function () { } like
| idiots. Such a meaningless argument for preventing progress.
| szastamasta wrote:
| Nobody needs classes nor prototypes in JS. Objects +
| functions is more than enough. I stopped using these few
| years ago and miss nothing.
| jitl wrote:
| You and "anybody" are actually two different sets of
| people with different needs and desires
| szastamasta wrote:
| I just mean you won't write a video codec or a 3d renderer in
| JS. It will never get there. Just leave these things to
| WebAssembly where needed and leave JS as a slow, dynamic
| language we use for web apps.
| tantalor wrote:
| It's a false dichotomy. Computers are fast. You should be
| able to write fast computer programs in any language.
|
| The limiting factor on a program's performance should be
| the design of algorithms and data structures, not the
| programmer's choice of language or runtime.
| wiseowise wrote:
| > Please stop bloating it with every feature that's trendy this
| year.
|
| Trendy structs. Did I return to 1980? (wipes happy tear)
| meindnoch wrote:
| Leave. The. Language. Alone.
| BoingBoomTschak wrote:
| The similarity with CL's divide between structs and classes is
| uncanny; especially with ((:type vector) :named).
| dangoodmanUT wrote:
| I thought it said "Proposal: JavaScript Sucks" and was not
| surprised by the number of upvotes from HN
| PeterWhittaker wrote:
| (Wipes away tears of laughter) I needed that! [1] [2]
|
| [1] just got some bad news [2] all in all, I love working in JS
| when I have to, but I've worked in it long enough to know of at
| least very many of the foot guns.
| nikeee wrote:
| 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.
| lxe wrote:
| 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 Store
| i007 wrote:
| // Step 1: Convert JSON object to string const jsonObject = {
| name: "John", age: 30 }; const jsonString =
| JSON.stringify(jsonObject);
|
| // Step 2: Convert the string to binary data const encoder = new
| TextEncoder(); const encodedJson = encoder.encode(jsonString);
|
| // Step 3: Create a SharedArrayBuffer and a Uint8Array view const
| sharedArrayBuffer = new SharedArrayBuffer(encodedJson.length);
| const sharedArray = new Uint8Array(sharedArrayBuffer);
|
| // Step 4: Store the encoded data in the SharedArrayBuffer
| sharedArray.set(encodedJson);
|
| Now you can use Atomics, no?
|
| https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
| winrid wrote:
| The thing I like about this is when I get a heap dump I could get
| names for things instead of "object shapes", which would be cool.
| alkonaut wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-10 23:01 UTC)