Node.js worker threads are problematic, but they work great for us

[-]

light24bulbs@reddit

Really makes you wish Go didn't have a horrible type system and a very unsafe handling of pointers and nil. The concurrency puts basically every other language to shame.

[-]

On the other hand, Rust has a very nice type system, supports async fn and with a runtime like tokio you can easily get to the same concurrency level of a Go program. And you shouldn't even need raw pointers—just safe, opaque references.

[-]

light24bulbs@reddit

Fucking hard though innit

[-]

-_one_-1@reddit

Rust isn't that hard, it's just different. It becomes very pleasant to use when you take the time to understand it.

[-]

ExcelsiorVFX@reddit

This is exactly what I like about Rust, is that although the learning curve is steep, it feels very good to intentionally use different structures for memory instead of letting the language abstract it from you, while forcing you to use (probably) the correct one.

[-]

-_one_-1@reddit

Exactly. And even if you're really lazy and don't want to think about memory management, you can usually just put Rc<> everywhere and be done with it. At that point it becomes not that much unlike Java or similar.

Although as Rust makes it so convenient to use references, you can usually scrap “smart” pointers with unnecessary metadata overhead.

And as the most convenient memory access pattern is owning data, Rust incentives the programmer to avoid memory indirection unless really necessary.

It's also awesome how Rust maps the unit type to a nullary tuple, which is a ZST, and how ZSTs are automatically elided during lowering, which makes HashMap<K, ()> effectively a HashSet<K> with no unnecessary memory overhead.

[-]

fletku_mato@reddit

What do you mean with very unsafe handling of pointers and nil? If it's a pointer, it can be nil, and you just need to check it.

[-]

micha_i@reddit

Pointers should not be nullable by default. This lesson has been there since the C days and some new languages (Go) still get it wrong (Rust and Zig got it right)

[-]

Sn00py_lark@reddit

Nil is used for optional. So if a pointer isn’t nil how do or determine if it’s the default / 0 value or not provided

[-]

micha_i@reddit

By wrapping a pointer in an Option? Please look at how Rust handles it, you may discover a lot of new stuff regarding programming.

[-]

light24bulbs@reddit

They walk among us

[-]

fletku_mato@reddit

My question was serious. I don't understand why you find them unsafe (even if they do walk amoung us)

[-]

chucker23n@reddit

There's plenty of good languages with better attributes than Node.js before you have to resort to Go.

[-]

Sn00py_lark@reddit

Like?

[-]

Sn00py_lark@reddit

Kotlin may be better? I work mostly with go but optional seem good

[-]

lilB0bbyTables@reddit

The Go type system certainly has annoying limitations but they’re entirely manageable. The biggest offender in the language is “generics” which are basically useless or painful outside stand-alone package functions. But I’m not really sure I get the “unsafe handling of pointers and nil” complaint? Pointers can be nil - you always need to safe-check pointers, and pointer-receiver methods make it very trivial to encapsulate those assertions and keep them tucked away neatly if you want. NPEs exist in Java, it’s not like this is some wild exotic thing.

[-]

light24bulbs@reddit

Look at how zig solves this problem. You'll see it's much more elegant.

[-]

CpnStumpy@reddit

And didn't need to copy/paste err checks every 3 lines of code. And didn't default every value to zero so people constantly shoot themselves in the foot treating 0 like nil. And didn't treat dynamic linking like voodoo heresy.

[-]

light24bulbs@reddit

Satisfying that you find the same things to be super shit as I do.

[-]

Paulogiacomo1960@reddit

Worker threads feel like one of those features that are awkward right up until you have a workload that needs them.

Then suddenly the complexity is cheaper than rewriting the whole thing in another stack.

[-]

voteyesatonefive@reddit

What's even cheaper is not making the obvious mistake of writing something in JS that can be written in any other language.

[-]

Sn00py_lark@reddit

Crazy take. JS / TS is used in tons of large systems

[-]

AnnoyedVelociraptor@reddit

If you need shared state instead of message passing, SharedArrayBuffer lets threads share raw memory, and Atomics provides thread-safe operations on it.

Stop doing stuff in JavaScript that it was never meant to do. Use a real language.

[-]

Somepotato@reddit

uses a feature provided by javascript

gripes that it's not something javascript can do

[-]

chucker23n@reddit

It can do it. But it's not its strength.

[-]

kaelima@reddit

This platform seems to support Node.js, it makes sense that they are trying to provide the best possible product they can. They are also doing this with regular language features, so I genuinely don't understand the problem.

[-]

Shoddy-Childhood-511@reddit

I always give thanks for major NPM supply chain attacks.

[-]

Aggressive_Ticket214@reddit

That pool pattern is the key. Spawning a worker per task negates the whole benefit. We hit the same wall on a data pipeline processing thousands of records daily. The fix was keeping a fixed pool of workers alive and just posting messages to them. No cold start cost, no memory explosion from orphaned workers. The complexity shifted from 'how do I spin this up' to 'how do I manage backpressure when workers are saturated.' That second problem is harder but more rewarding to solve.

[-]

josephjnk@reddit

Node.js worker threads have expressed some outdated political opinions. There’s a Google doc

[-]

trigzo@reddit

Yeah, it is sad how under developed they are but at the end of the day, good engineers would pick the right tool for the job. If I needed parallelism, I wouldn't use Node.

Great post

[-]

voteyesatonefive@reddit

It's crazy that people are still using nodejs/npm for anything where there are reasonable alternatives, such any and all back-end development. There is no baby, it's all bathwater, throw it out.

[-]

lIIllIIlllIIllIIl@reddit

I know this is bait, but TypeScript is genuinely a pretty good language and being able to use the same language on the server and client is great. Other ecosystems have their own strengths and weaknesses. It doesn't have to be black or white.

[-]

voteyesatonefive@reddit

Using JS for your front and back end does enable you to increase the risk of being a victim supply chain attacks, so that's nice.

[-]

sk_sushellx@reddit

the "problematic but works great for us" energy is so real 💀 worker threads have a reputation for being painful to debug and the shared memory model is genuinely tricky, but for CPU bound tasks that would block the event loop they're basically the only native option. curious what use case you landed on because the teams that make worker threads actually work usually have a very specific problem they were solving lol

[-]

24sagis@reddit

AI ass comment

[-]

Warauth@reddit

The fact it’s deleted tells me everything I need to know.

Fuck clankers

[-]

oldsecondhand@reddit

worker threads have a reputation for being painful to debug and the shared memory model is genuinely tricky,

Parallel computing is tricky in general. The title gave the picture that there are implementation specific issues with it.

[-]

HalcyonicStorm@reddit

Check out Elixir and the BEAM , yall. much easier dealing with concurrency