3 ms·
No, this is not true and you got couple of things wrong. Erlang's model is more like an asynchronous event driven programming on steroids, while idiomatic Go is
by zzzcpan 10y ago
No, this is not true and you got couple of things wrong. Erlang's model is more like an asynchronous event driven programming on steroids, while idiomatic Go is synchronous and is merely a traditional multithreading, which is known to be unusable for non-trivial concurrent problems. Here's the thing though, people don't really understand these things, they always want something easy that solves a simple problem they have in mind and always fail to grasp how much flexibility they sacrifice and how much harder or even impossible it will get for more complex problems. And believe me, if you get into concurrency you're gonna have a lot of problems that are very hard or even impossible to solve synchronously. The world is an asynchronous place.
- fooyc 10y agoI'm doing a lot of concurrent code and Go behaves very well with tens of thousands of concurrent coroutines and network sockets. I couldn't tell the same thing about Nodejs, for instance, which is why I tried Go in the first place. Incidentally my code is much easier to understand, too.
- stymaar 10y agoI personally find the nodejs async much more intuitive than goroutine + synchronous code in it, but this is a highly subjective subject. nodejs use to be pretty annoying when dealing with complex workflow in term of code legibility when it was fully callback-based, but with async/await you get the best of both world IMHO.
- fooyc 10y agoasync/await is a huge improvement over callbacks, but you still have to make sure that everything in your code is async, else you block everything. Also, it doesn't magically works with all functions, the functions have to support async/wait. And it's still less natural than writing sync code
- ecnahc515 10y agoGo certainly does not do traditional threading. It has Go routines, which is are lightweight "threads" which gets multiplexed on top of real OS threads. It's basically implementing async IO at the runtime level.
- stymaar 10y agoIn term of programming interface, you deal with them as if it was a traditional thread. (with its pro and cons: pro: all your code is sequential, it's intuitive to understand what the programmer wanted to do in a specific scenario. cons: data-races are hiding in every corners :/) Being a green thread with a growing stack is an implementation detail for the developer writing Go code.
- fooyc 10y agoIn a thread, every single function call is not a separate thread. In async, every single function must be async (or be super fast and i/o-free).