| ▲ | pizlonator 4 hours ago |
| I knew it was possible :-) https://webkit.org/blog/7846/concurrent-javascript-it-can-wo... |
|
| ▲ | bakkoting 18 minutes ago | parent | next [-] |
| In case anyone missed it, this PR is based on that: > This is an implementation of the design Filip Pizlo published in 2017: "Concurrent JavaScript: It Can Work!". |
|
| ▲ | gwbas1c an hour ago | parent | prev | next [-] |
| Years ago I did "multithreaded Javascript" by calling into Rhino (Javascript engine) from multiple threads. Granted, I converted Rhino from JVM to CLR, so it wasn't exactly a stable environment, but it did "work". |
|
| ▲ | aardvark179 2 hours ago | parent | prev | next [-] |
| It’s certainly possible, but I worry that weird things can happen when doing something as “simple” as defining a property if another thread is messing with the prototype chain. Even thread safe property maps can’t entirely save you because operations that need to go up the prototype chain are not and cannot be atomic. |
| |
|
| ▲ | CharlesW 3 hours ago | parent | prev | next [-] |
| That's excellent work and a great read, Filip! |
|
| ▲ | quotemstr 3 hours ago | parent | prev [-] |
| Yes, you did. And it's a good design. You even did the GC question justice. My concern is more in the spirit of "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.". Of course JS being single threaded wasn't a hard constraint. Lift it, and people like you can use the parallelism to do great things. The problem is that most developers are not you. Shared memory concurrency is foot-artillery (especially if truly parallel). Adding threads to the JS ecosystem is selling W48 nuclear artillery shells at the toy store. JS's ostensible limitation to a single thread forced users to do what they should have been doing anyway: message-passing, thread-per-core architecture, and actor-ish stuff. People who don't know better reach for shared memory concurrency because it seems like a good way to solve problems, but it's actually a dangerous attractor in idea space. JS engine limitations were accidentally keeping people away from it. Now that they can hear the siren's song of a mutex, they'll run around on the hard problems of parallel programming. Now, that's not a reason to avoid shipping such a system. It's just not something I would have chosen to implement for the masses. |
| |
| ▲ | pizlonator 2 hours ago | parent | next [-] | | I don’t understand the thread phobia Comparing it to nukes is a bit extreme, don’t you think? | |
| ▲ | hexasquid 3 hours ago | parent | prev | next [-] | | This is consistent with the endless contempt people have had for JavaScript and those that use it. | | |
| ▲ | pizlonator 2 hours ago | parent [-] | | Yeah I don’t get that either It’s a super successful language | | |
| ▲ | Waterluvian 2 hours ago | parent | next [-] | | I think with ES6 and newer things really cleaned up and now we’re left with avoidable ugly parts, of which every language has. Before when you didn’t even have strict equality checking, for example, you were forced to know about implicit type casting. Getting on the same page with modules also helped a lot. Typescript directly in Node is great. Look mom, no build system!! I’m just hoping one day browsers will accept TS the same way. | | |
| ▲ | thedelanyo an hour ago | parent | next [-] | | > I’m just hoping one day browsers will accept TS the same way. Wouldn't that be a direct kill of JS? | |
| ▲ | ricardobeat an hour ago | parent | prev | next [-] | | When did JS not have strict equality? | | | |
| ▲ | cyberax 2 hours ago | parent | prev [-] | | You still need a compiler for TSX, though. There's also a tiny bit of non-erasable Typescript (enums). | | |
| ▲ | Waterluvian 2 hours ago | parent [-] | | There’s a mode to pretend those features don’t exist and not allow them. Meaning it gets far simpler to just type elide rather than any actual compilation effort. I think this idea is getting more popular and it would be kinda nice if TS committed to not adding any more features like that. | | |
| ▲ | MrJohz an hour ago | parent [-] | | TS has committed to not adding any more features like that. Features only get added when they reach a certain threshold on the TC39 standardisation track. |
|
|
| |
| ▲ | hyperhello 2 hours ago | parent | prev [-] | | It's successful because it's been kept away from the kind of programmers who think the time spent to endlessly specify everything four times is nothing compared to the sadness of losing a byte or a cycle. These are the descendants of people who hundreds of years ago would have insisted that real work is in Latin. C++26 is available for them, or Node/React with hundreds of dependencies if they want JavaScript, or they can even compile and run whole operating systems into WASM now, or anything else. Just let JavaScript be the domain of people who do other things for fun. |
|
| |
| ▲ | curtisblaine 9 minutes ago | parent | prev [-] | | Worth noting that javascript has had workers, shared memory and atomics for years and that you can use them today. Look at this guy writing a lockless allocator: https://greenvitriol.com/posts/lockless-allocator The only difference in this PR is that it makes threads light (workers are fat because they carry a whole v8 instance with them) and it makes shared memory default with light threads (now you need to pass a shared array buffer first). Javascript is probably not your first language, I get it, but it has had "the siren song of a mutex" for years now. What really surprises me and I can't explain is why you went and took time to express such strong opinions on something that you obviously don't even know or use that well. |
|
