211–220 of 318 posts
> Mixing threads with event loops is possible, but so complicated that few programmers can afford the mental burden for their applications. Correct me if I'm wrong, but doesn't basically every UI framework from the last 20 years do exactly this?
PHP is way better with this than Go, and much easier to learn.
I think you are being down-voted for just making a generalized claim with no mention of why? care to explain, what areas does PHP out-perform Go?
Yes, you can use CGI to get the same model in practically any language, but we see very few languages these days making this tradeoff.
For some reason, people decided they wanted the performance gain of spawning threads per request instead of processes per request. Honestly, it's ridiculous. Reasoning about isolated processes per request is easy compared to many threads. Sure, in php you can't share a pool of db-connections between requests, and if you need to lock a filesystem resource you're stuck because you can't share a mutex between requests so you have to make an ad-hoc one some other way, and the overhead is like 50MB/request meaning the difference between a server handling 1000 requests with php and 60000 requests with go...
But being able to just have processes which were all isolated and request scoped was nice. The OS was your GC so you didn't have to worry about freeing memory, and the OS's scheduler did a damn good job of making sure php processes blocked on IO got context switched between.
Earlier quoted context omitted.
So what's preventing Linux from adopting switchto support? I'd love to see the discussion around it.
Beats me! The author no longer works at Google from what I can tell—emails to him bounced. I'd love to see 1:1 threading become competitive with M:N for the heaviest workloads. It just plays so much nicer with the outside world than M:N does.
After working lots of years with all of the available async paradigms (eventloops, promises, async-await, observables, etc) I would tend to agree. Even though many of those things (including Rusts futures implementation) are very well-engineered, the integration problems (as e.g. outlined in the what color is your function article) are very real. And the extra amount of understanding that is required to use and implement those technologies might often not justify the gains. One basically needs to understand normal threaded-synchronization as well as async-synchronization (e.g. as with .NET Tasks or Rusts futures) to build things on top of it. Same goes for the extra level of type indirection (Task vs T), or the distinction between "hot" and "cold" tasks/promises.
If it would be possible to get 1:1 threading into the same performance region for most normal applications (e.g. everything but a 1 million connection servers) it seems to very favorable.
Go concurrency is just threads. It's a particularly idiosyncratic userland implementation of them. There are two claims here I'd like to unpack further: 1. "I've measured goroutine switching time to be ~170 ns on my machine, 10x faster than thread switching time." This is because of the lack of switchto support in the Linux kernel, not because of any fundamental difference between threads and goroutines. A Google eng…
Nothing you're saying is wrong, but your perspective is totally off. For someone experienced with C++, or say, Rust (ahem), obviously Go is a bit backwards when it comes to concurrency and race conditions. Obviously you can mimic go's goroutine stacks, obviously you can obtain fast thread switching. But Go isn't targeting C++ or Rust, and it's not targeting the domains those languages are best at (although admittedly…
I checked my assumptions, you're kind of right about python developers switching but it's hard to know the real base distribution of people who know those languages (there might just be more python/js developers not more switching proportionally). Not much ruby guys though and plenty of Java/C/C++
> Mixing threads with event loops is possible, but so complicated that few programmers can afford the mental burden for their applications. Correct me if I'm wrong, but doesn't basically every UI framework from the last 20 years do exactly this?
Yeah, multithreading with event loops was never a big deal. Simple API to run something in a thread pool out of event loop is definitely much easier, than using threads. Apple did Grand Central Dispatch and I believe it's universally recognized to be easier than using threads.
Earlier quoted context omitted.
I'm not the person you're asking, but I want one thread per connection, and I want one million connections per host.
But then with a million of threads either M:N or 1:1 you have other problems, namely the whole shared memory multithreading model breaks and you can forget about all the locks/channels if you want to actually do something useful with that.
Earlier quoted context omitted.
So does Ericsson still use Erlang in their recent network hardware etc?
I recall hearing no, somewhere. I am under the understanding, (don't know where from) that Cisco DOES use Erlang in their stack, and there is a group of people at VMware that does.
Earlier quoted context omitted.
> The only real difference for most code is that it pushes you very hard to use channels directly, as they're the only type-safe option. It is, but it is also a super important difference: Go provides inbuilt libraries to make inter-thread synchronization more bearable for the average user, e.g. channels and waitgroups. These are lot harder to misuse than bare mutexes and condition variables. Since those are not avai…
Practically every language includes stuff higher level than bare mutexes and atomics. That people use them doesn't mean other options aren't available . And yeah, totally 100% agreed, most people should never implement them themselves. But "futures", "blocking queues", "synchronized maps", and "locked objects" (e.g. a synchronized wrapper around a java object) are extremely common and often higher level than channels…
Primitives for synchronizing concurrent control flow (like Go's select()) seem less common. E.g. in Java I would have some executor services, and could post all tasks to the same single threaded executor to avoid concurrency issues. But it's clearly a different way of thinking than with channels/select.
You are also fully right about waitgroups. They are really nothing special. But they might see more use in Go since some structuring patterns are more often used there: E.g. starting multiple parallel workflows with "go", and then waiting for them to complete with a waitgroup before going on.
Earlier quoted context omitted.
Depends. I would argue that e.g. Go's CSP approach is not implementable on top of Akka, since actors there are not allowed to block on reception of single message. They will always get messages pushed, so the blocking Go concurrency constructs can not be built on top of it. It's obviously slightly different with Erlang, where Actors can block. I think the basic Actor definition does only say that Actors need to send…
Lack of blocking support in runtime cannot prevent you from implementing waiting. Either through higher-order event driven code or just plain busy-waiting style message exchanging until you receive your message.