undefined | Better HN

0 pointsjondubois9y ago0 comments

Maybe, Golang also has similar advanced multi-threading constructs.

But I do a lot of REST API (and WebSocket) work and all of the workload that happens inside my Node.js program is extremely lightweight.

If I need to perform some heavy computation, I will offload it to a separate child process - Node.js forces me to put that code in a separate file/module but I actually like this because it encourages separation of concerns. It feels very natural so I don't really need any other special constructs.

I looked into goroutines a while ago; it looks cool, but I probably wouldn't use them much because I don't like the idea of having code from the same source file splitting off into multiple processes/threads; it makes is harder to read and reason about the code (this is a bit like what happens with multi-threaded code when you have mutexes all over the place).

To me, this feature has the same utility value as the ability to define multiple classes per source file - Ok, that's cool, but is it a good idea to do that?

0 comments

1 comments · 1 top-level

wyager9y ago

I don't really have strong feelings about source file organization, but the way it works in Haskell is that all IO actions have type "IO a", where "a" is the type of the action's result. To do multithreading, you just do e.g.

    foo :: IO () -- optional type declaration
    foo = forever (print "hi")
    forkIO foo

Now Foo will run in its own green thread forever. Very simple. This works with any IO action. You can put it in whatever file you like. For communicating across threads you have many great options like STM. If you like Go-style chans, there are libraries that provide various types of chans.

j / k navigate · click thread line to collapse