3 ms·

If somebodies primary language is JS I think node is a great choice. 9/10 times node performance will be just fine for what people are doing. Writing real multi

If somebodies primary language is JS I think node is a great choice. 9/10 times node performance will be just fine for what people are doing. Writing real multithreaded code without a GIL is hard. I would think just scaling horizontal or vertical would be easier. And doing threading in Python is so confusing for new beginners. There are about a million different ways to do it.

hamburglar 6y ago
> Writing real multithreaded code without a GIL is hard. I'm starting to think this is going to be a major dividing line in developer skill going forward -- those who can write threadsafe code and those who can't. There's an awful lot of Java, C# and Golang out there and if a programmer can't reliably think through thread safety issues (which is not that difficult in simple cases), they aren't capable in that realm. One of the most frustrating things about my brief excursion into the land of Ruby was that the community was full of modules written by people who had no reason whatsoever to think about thread safety because they were programming for Rails, not Ruby in general.
- valand 6y ago
  > those who can write threadsafe code and those who can't This, abstracted, those who can write distributed software and those who can't yet. Dealing with shared resources is similar to dealing with shared memory if you zoom out a bit. We need more people to move from the latter group to the former, for reasons. The more people aware of distributed software and its challenges, the better.
- jashmatthews 6y ago
  This sounds very gatekeepy. The JVM and Golang have additional aides for writing thread-safe code because writing multi-threaded code is fucking hard. People at the top of our field working on browsers or VMs regularly fuck up the simple stuff. If it was easy we wouldn't have Erlang or Rust.
  - hamburglar 6y ago
    I'm very gatekeepy about only wanting competent developers working on my code.
jashmatthews 6y ago
> Writing real multithreaded code without a GIL is hard. A GIL doesn't help developers. It only keeps the internal state of the VM consistent. You still need to to use locks, thread safe collections etc. That's one major reason why some people feel that OS threads + GIL is a poor trade-off. https://github.com/ruby-concurrency/concurrent-ruby#thread-safety https://github.com/ruby-concurrency/concurrent-ruby#thread-s...
- nerdbaggy 6y ago
  Never knew that thanks!
vertex-four 6y ago
Writing multithreaded code without a GIL is hard, but there's really good workarounds for a lot of cases. For example, Boost ASIO's "strand" pattern. You can define a set of coroutines that never run concurrently, so synchronization is much easier, while you can have many strands. I use this model in some of my Rust code - I associate clients to a producer, meaning I don't have to work out a suitable contention-free bus. This is essentially equivalent to running N single-threaded processes, except that when I do have to share data across the system (e.g. a database connection pool), or if the lifecycle of the client crosses multiple strands, I have more tools in my toolkit.

hamburglar 6y ago

> Writing real multithreaded code without a GIL is hard. I'm starting to think this is going to be a major dividing line in developer skill going forward -- those who can write threadsafe code and those who can't. There's an awful lot of Java, C# and Golang out there and if a programmer can't reliably think through thread safety issues (which is not that difficult in simple cases), they aren't capable in that realm. One of the most frustrating things about my brief excursion into the land of Ruby was that the community was full of modules written by people who had no reason whatsoever to think about thread safety because they were programming for Rails, not Ruby in general.

valand 6y ago
> those who can write threadsafe code and those who can't This, abstracted, those who can write distributed software and those who can't yet. Dealing with shared resources is similar to dealing with shared memory if you zoom out a bit. We need more people to move from the latter group to the former, for reasons. The more people aware of distributed software and its challenges, the better.
jashmatthews 6y ago
This sounds very gatekeepy. The JVM and Golang have additional aides for writing thread-safe code because writing multi-threaded code is fucking hard. People at the top of our field working on browsers or VMs regularly fuck up the simple stuff. If it was easy we wouldn't have Erlang or Rust.
- hamburglar 6y ago
  I'm very gatekeepy about only wanting competent developers working on my code.

jashmatthews 6y ago

> Writing real multithreaded code without a GIL is hard. A GIL doesn't help developers. It only keeps the internal state of the VM consistent. You still need to to use locks, thread safe collections etc. That's one major reason why some people feel that OS threads + GIL is a poor trade-off. https://github.com/ruby-concurrency/concurrent-ruby#thread-safety https://github.com/ruby-concurrency/concurrent-ruby#thread-s...

nerdbaggy 6y ago
Never knew that thanks!

vertex-four 6y ago

Writing multithreaded code without a GIL is hard, but there's really good workarounds for a lot of cases. For example, Boost ASIO's "strand" pattern. You can define a set of coroutines that never run concurrently, so synchronization is much easier, while you can have many strands. I use this model in some of my Rust code - I associate clients to a producer, meaning I don't have to work out a suitable contention-free bus. This is essentially equivalent to running N single-threaded processes, except that when I do have to share data across the system (e.g. a database connection pool), or if the lifecycle of the client crosses multiple strands, I have more tools in my toolkit.