4 ms·
Your single Go Process is typically #cores Processes. All the orchestration is still handled by you, just there falacities for it in the language for it. Just
by valarauca1 10y ago
Your single Go Process is typically #cores Processes. All the orchestration is still handled by you, just there falacities for it in the language for it.
Just because you are using stdlib not an external application does not change the functionality that is happening.
- regecks 10y agoI think this is a bit disingenuous. Do you also think that Java is multi-process? I can see the argument that an OS thread is a process but it is basically irrelevant in every way that matters in development and operations. An example - how do you access the same shared-memory (say, a map/dictionary) from multiple cores in any particular runtime? - Go: you make a map, you protect the map with a mutex, and you reference it directly. - Java: same, or ConcurrentHashMap or whatever is available. - 'Worker'/'forking' runtimes: you can't, right? You move the state to another component (such as Redis), or you use an OS-provided shared memory facility, or you need inter-process RPC etc ... -- Of course, sometimes workers being separate processes is a virtue rather then a burden ... but I'm not sure this is true in the case of Ruby or Python when it's more purely a limitation of the runtime.
- deleted 10y ago[deleted]
- tracker1 10y agoIt orchestrates using threads iirc, and the primitives for handling the communication in a more safe fashion are in the box, as you mention... and depending on the OS starting threads may be nearly as expensive as processes. That said, it's definitely less overhead than orchestration across forked threads.