4 ms·

>Single-threaded isn't a benefit Huh? Of course it has some benefits. Unfortunately everything is just trade-offs. A benefit of single-threadedness is that you

>Single-threaded isn't a benefit Huh? Of course it has some benefits. Unfortunately everything is just trade-offs. A benefit of single-threadedness is that you don't deal with the certain pitfalls of multi-threadedness.

eropple 9y ago
If you are dealing with a single-threaded, non-concurrent problem, yes, that's true. Node isn't that. In my experience, the pitfalls of multi-threadedness are more around concurrency than they are parallelism, so that tradeoff strikes me as largely a false one.
- always_good 9y ago
  I'd say the exact opposite. Race-conditions in parallelism are where the classic problems lie. We aren't going to agree here, but you sounded like you thought your position was axiomatic or something, and that's what I disagree with. Meanwhile I am content that we may have different preferences, that's not a problem.
  - eropple 9y ago
    The problem, in every case I can think of (and it intuitively seems true), is continuation, whether it's done in software with coroutines or in hardware with process scheduling/threads. Which is a concurrency problem rather than a parallelism problem, which then expands to "are problems of linearizability concurrency or parallelism?". Which might be a more settled way to answer the question in a CS manner. Can you describe a race condition that cannot be replicated on a single thread with either preemptive or cooperative multitasking/coroutines? I'm racking my brain and can't come up with one. If your coroutines are deterministically given time, then I guess you can avoid race conditions, but "are my coroutines deterministic" seems like a really difficult thing to conclusively prove in all cases (like, just add network I/O latency), and the conceptual barrier remains the same whether they're deterministic or not. (Edit: a friend just noted the possibility of writing to memory/disk and reading halfway through, and if you don't have atomic writes that's true, but you can have preemptive, single-process multitasking that interrupts mid-write; that's why we have file system lockfiles, isn't it?) I use node-async-locks when writing JavaScript sometimes if I have to deal with shared state, because, hey, I might have to await something and come back to this later. (Obviously I try not to, because duh, but sometimes you're stuck with it and can't immutable-all-the-things. So you define a critical section and do your thing.)
  - eropple 9y ago
    Coming back to this, I'd really like to direct your attention to my reply. Am I missing something with regards to this?
defined 9y ago
Seriously, use Erlang or Elixir and have both concurrency and ease of programming and debugging relative to Node.js. Spoken as someone who has created multiple Erlang projects with close to zero unintended downtime for months or years in production.
- eropple 9y ago
  I like what I've seen of Elixir. (As a Rubyist by habit, I should.) But it doesn't do what Node does: Use JavaScript. We can say 'til we're blue in the face that that doesn't matter (and I do, as a Ruby/Grape guy for APIs), that matters. Lowered impedance mismatch is a thing. I use Ruby because I'm still more productive there--but that's a library problem (RDBMSes), not a language problem. Node really is good-enough. I'd go for either a JVM or a BEAM-based solution if I was building things where there were significant and meaningful losses on the table if I fucked up, but for most things? Nah. Just...not important enough.

eropple 9y ago

If you are dealing with a single-threaded, non-concurrent problem, yes, that's true. Node isn't that. In my experience, the pitfalls of multi-threadedness are more around concurrency than they are parallelism, so that tradeoff strikes me as largely a false one.

always_good 9y ago
I'd say the exact opposite. Race-conditions in parallelism are where the classic problems lie. We aren't going to agree here, but you sounded like you thought your position was axiomatic or something, and that's what I disagree with. Meanwhile I am content that we may have different preferences, that's not a problem.
- eropple 9y ago
  The problem, in every case I can think of (and it intuitively seems true), is continuation, whether it's done in software with coroutines or in hardware with process scheduling/threads. Which is a concurrency problem rather than a parallelism problem, which then expands to "are problems of linearizability concurrency or parallelism?". Which might be a more settled way to answer the question in a CS manner. Can you describe a race condition that cannot be replicated on a single thread with either preemptive or cooperative multitasking/coroutines? I'm racking my brain and can't come up with one. If your coroutines are deterministically given time, then I guess you can avoid race conditions, but "are my coroutines deterministic" seems like a really difficult thing to conclusively prove in all cases (like, just add network I/O latency), and the conceptual barrier remains the same whether they're deterministic or not. (Edit: a friend just noted the possibility of writing to memory/disk and reading halfway through, and if you don't have atomic writes that's true, but you can have preemptive, single-process multitasking that interrupts mid-write; that's why we have file system lockfiles, isn't it?) I use node-async-locks when writing JavaScript sometimes if I have to deal with shared state, because, hey, I might have to await something and come back to this later. (Obviously I try not to, because duh, but sometimes you're stuck with it and can't immutable-all-the-things. So you define a critical section and do your thing.)
- eropple 9y ago
  Coming back to this, I'd really like to direct your attention to my reply. Am I missing something with regards to this?

defined 9y ago

Seriously, use Erlang or Elixir and have both concurrency and ease of programming and debugging relative to Node.js. Spoken as someone who has created multiple Erlang projects with close to zero unintended downtime for months or years in production.

eropple 9y ago
I like what I've seen of Elixir. (As a Rubyist by habit, I should.) But it doesn't do what Node does: Use JavaScript. We can say 'til we're blue in the face that that doesn't matter (and I do, as a Ruby/Grape guy for APIs), that matters. Lowered impedance mismatch is a thing. I use Ruby because I'm still more productive there--but that's a library problem (RDBMSes), not a language problem. Node really is good-enough. I'd go for either a JVM or a BEAM-based solution if I was building things where there were significant and meaningful losses on the table if I fucked up, but for most things? Nah. Just...not important enough.