7 ms·

> It didn't seem to make any sense to me given the nature of the claims of the language. You mean that it was good for writing network servers capable of handl

by smegel 11y ago

> It didn't seem to make any sense to me given the nature of the claims of the language. You mean that it was good for writing network servers capable of handling many tens of thousands of connections? You usually don't need more than one core to handle IO, and if you are doing processor intensive stuff a few more cores is not going to help if you have many thousands of requests - in this case a better pattern is a work queue and a way of letting the client know their work is done. Concurrency/threading is generally considered a "hard" topic within software dev, and if you lack a solid grounding in the basic concepts you are destined to misuse or misapply the paradigm.

amelius 11y ago
Sometimes a server does more than just I/O.
- smegel 11y ago
  Well if it "does more" for every request when you are handling many thousands of concurrent requests, that is going to be one hell of a busy server.
  - paulfurtado 11y ago
    I'm not sure what you're trying to argue here. If you want to serve many requests that do significant CPU work in parallel, multiple cores are necessary no matter how efficiently Go manages the connections. Additionally, even rendering HTML templates can take quite a bit of CPU time and when Go's concurrency is limited to a single-core, that means only one template can be rendered in parallel, blocking other requests.
    - smegel 11y ago
      > If you want to serve many requests that do significant CPU work in parallel For what definition of "many"? If you have 16 cores that is 16 requests being processed in parallel. Go hasn't even got out of bed by the time it is handling 16 connections. When Go is being used for it's intended purpose - handling thousands of concurrent connections, you need to be a lot smarter than just running on all the cores you have. I'm not saying you wouldn't use all cores to maximize utilization - what I am saying if that if you are scaling beyond one core, then you would already be thinking about scaling across multiple servers behind a load balancer - i.e. you are doing ops work on a production scale cluster. And if you are doing production ops work, you are going to be tuning all the processes under your control in detail, not just making rash assumptions about how they may or may not utilization multiple cores. The point I was arguing here is that someone who said "Back when I was learning Go" and who understands the "nature of the claims of the language" is not going to be running into these sorts of scalability issues, and would not be bitterly disappointed to learn of a default threading value of 1. Unless they had some misconstrued understanding of what Go's concurrency support was all about, and made an incorrect assumption that it was primarily about parallel computation, rather than it's true purpose of having many thousands of lightweight processes handling lots of network I/O.
  - amelius 11y ago
    My goal is to have a busy server, because that minimizes wasted resources :) The more users I can handle on one machine, the better. And latency is important. I can't have a user performing a lengthy operation, while at the same time blocking all other users. Real (not fake) threads are needed to combat latency.
    - smegel 11y ago
      > And latency is important. I can't have a user performing a lengthy operation, while at the same time blocking all other users. Real (not fake) threads are needed to combat latency. And if you have thousands of current connections (the kind of workload Go was designed to handle), and only a few hundred of them are performing "lengthy operations", you could have 4 cores, or 16, it won't make much difference compared to 1 core - which is the vast majority of the connections are going to be blocked for unacceptably long intervals. In this scenario, the only solution is to either queue up work and make the client come back later, or scale across many servers behind a load balancer. The point I am making here is that people who are engineering scaled out systems across multiple servers to handle thousands of concurrent requests are usually high-end ops people who are not going to be naively assuming that any process will be doing threading in a particular way - they would have already tested Go in details first and would very quickly have seen you need to set the GOMAXPROCS variable to use more than one core. They would probably look at the GC as well. Tuning stuff to run well is what ops people do, and choosing how many cores a process should use is pretty standard stuff (it may be sharing the server with other processes after all).
      - amelius 11y ago
        So your argument is basically that if you keep adding users, at a certain point my system will break? I think that is a strawman argument. In my opinion, it is perfectly legitimate to have the requirement of low latency, while running lengthy operations in the background (I'd show a spinner or a progress indicator, a very common approach). Yes, at a certain point this will break down, at which point I will add more servers. This is better than having no such system at all. If a language is only good for serving >>1M users and only doing I/O, then I guess it should not be branded as a general purpose, mainstream language, even if aimed at the web.

by smegel 11y ago

amelius 11y ago

Sometimes a server does more than just I/O.

smegel 11y ago
Well if it "does more" for every request when you are handling many thousands of concurrent requests, that is going to be one hell of a busy server.
- paulfurtado 11y ago
  I'm not sure what you're trying to argue here. If you want to serve many requests that do significant CPU work in parallel, multiple cores are necessary no matter how efficiently Go manages the connections. Additionally, even rendering HTML templates can take quite a bit of CPU time and when Go's concurrency is limited to a single-core, that means only one template can be rendered in parallel, blocking other requests.
  - smegel 11y ago
    > If you want to serve many requests that do significant CPU work in parallel For what definition of "many"? If you have 16 cores that is 16 requests being processed in parallel. Go hasn't even got out of bed by the time it is handling 16 connections. When Go is being used for it's intended purpose - handling thousands of concurrent connections, you need to be a lot smarter than just running on all the cores you have. I'm not saying you wouldn't use all cores to maximize utilization - what I am saying if that if you are scaling beyond one core, then you would already be thinking about scaling across multiple servers behind a load balancer - i.e. you are doing ops work on a production scale cluster. And if you are doing production ops work, you are going to be tuning all the processes under your control in detail, not just making rash assumptions about how they may or may not utilization multiple cores. The point I was arguing here is that someone who said "Back when I was learning Go" and who understands the "nature of the claims of the language" is not going to be running into these sorts of scalability issues, and would not be bitterly disappointed to learn of a default threading value of 1. Unless they had some misconstrued understanding of what Go's concurrency support was all about, and made an incorrect assumption that it was primarily about parallel computation, rather than it's true purpose of having many thousands of lightweight processes handling lots of network I/O.
- amelius 11y ago
  My goal is to have a busy server, because that minimizes wasted resources :) The more users I can handle on one machine, the better. And latency is important. I can't have a user performing a lengthy operation, while at the same time blocking all other users. Real (not fake) threads are needed to combat latency.
  - smegel 11y ago
    > And latency is important. I can't have a user performing a lengthy operation, while at the same time blocking all other users. Real (not fake) threads are needed to combat latency. And if you have thousands of current connections (the kind of workload Go was designed to handle), and only a few hundred of them are performing "lengthy operations", you could have 4 cores, or 16, it won't make much difference compared to 1 core - which is the vast majority of the connections are going to be blocked for unacceptably long intervals. In this scenario, the only solution is to either queue up work and make the client come back later, or scale across many servers behind a load balancer. The point I am making here is that people who are engineering scaled out systems across multiple servers to handle thousands of concurrent requests are usually high-end ops people who are not going to be naively assuming that any process will be doing threading in a particular way - they would have already tested Go in details first and would very quickly have seen you need to set the GOMAXPROCS variable to use more than one core. They would probably look at the GC as well. Tuning stuff to run well is what ops people do, and choosing how many cores a process should use is pretty standard stuff (it may be sharing the server with other processes after all).
    - amelius 11y ago
      So your argument is basically that if you keep adding users, at a certain point my system will break? I think that is a strawman argument. In my opinion, it is perfectly legitimate to have the requirement of low latency, while running lengthy operations in the background (I'd show a spinner or a progress indicator, a very common approach). Yes, at a certain point this will break down, at which point I will add more servers. This is better than having no such system at all. If a language is only good for serving >>1M users and only doing I/O, then I guess it should not be branded as a general purpose, mainstream language, even if aimed at the web.