3 ms·

Because Go has built in primitives to make micro services. The cleanest asynchronous io model that I have ever seen. Simple serialization by default. Did I m

by iTokio 9y ago

Because Go has built in primitives to make micro services. The cleanest asynchronous io model that I have ever seen. Simple serialization by default. Did I mention the blazing fast compile times? Just that would make it way more “faster” to build your service in Go :) And above all the language is simple with robust idioms. Okay, I admit it is somewhat too simple, cough generics. And you won’t get C like performances for sure.

woah 9y ago
IMO, the goroutine model has the same synchronization challenges as multithreaded programming. For network code that is io bound, I find async/await much cleaner.
- jrs95 9y ago
  It's not that bad with channels. I suppose you don't have to worry about synchronization issues as much with async/await on Node since that's a single threaded environment, but async/await with something like C# isn't any less complicated in that regard that goroutines and channels. Generally Go code isn't written like typical multithreaded code with synchronization unless you're really trying to optimize something.
- rqs 9y ago
  async/await and goroutine is not same thing here. When you talking about async/await, you're actually talking about asynchronization, and when you talking about goroutine, you're talking about parallel (which is a selling point of Go). If the thread that responsible for executing the async/await blocks, then the entire progress/thread rely on that async/await will block. So if you want to comfortably use async/await, the entire call stack must be build for it, and that can be a huge challenge for the ecosystem of that language. goroutine resolved that problem by spawn a new system thread so the rest of the progress will not be effected too much by the block. Go also resolved that problem by wrapping IO on top of an internal async API so basic IO operation will not cause actual block for too long.
  - pjmlp 9y ago
    Not necessarily, .NET and C++ task models (as done on Windows) rely on thread pools. When a thread responsible for async/await needs to block, the task is parked and another one will get allocated to the running thread.
- tmzt 9y ago
  the effort to add async/await to Rust is ongoing, with an experimental RFC [1]. There is also a working implementation using procedural macros [2]. [1] https://github.com/rust-lang/rfcs/pull/2033 https://github.com/rust-lang/rfcs/pull/2033 [2] https://github.com/alexcrichton/futures-await https://github.com/alexcrichton/futures-await
- dom96 9y ago
  If you want a compiled systems language with async/await you should take a look at Nim. Implemented fully using macros so you can even extend it (Nim's metaprogramming features are awesome).

by iTokio 9y ago

woah 9y ago

IMO, the goroutine model has the same synchronization challenges as multithreaded programming. For network code that is io bound, I find async/await much cleaner.

jrs95 9y ago
It's not that bad with channels. I suppose you don't have to worry about synchronization issues as much with async/await on Node since that's a single threaded environment, but async/await with something like C# isn't any less complicated in that regard that goroutines and channels. Generally Go code isn't written like typical multithreaded code with synchronization unless you're really trying to optimize something.
rqs 9y ago
async/await and goroutine is not same thing here. When you talking about async/await, you're actually talking about asynchronization, and when you talking about goroutine, you're talking about parallel (which is a selling point of Go). If the thread that responsible for executing the async/await blocks, then the entire progress/thread rely on that async/await will block. So if you want to comfortably use async/await, the entire call stack must be build for it, and that can be a huge challenge for the ecosystem of that language. goroutine resolved that problem by spawn a new system thread so the rest of the progress will not be effected too much by the block. Go also resolved that problem by wrapping IO on top of an internal async API so basic IO operation will not cause actual block for too long.
- pjmlp 9y ago
  Not necessarily, .NET and C++ task models (as done on Windows) rely on thread pools. When a thread responsible for async/await needs to block, the task is parked and another one will get allocated to the running thread.
tmzt 9y ago
the effort to add async/await to Rust is ongoing, with an experimental RFC [1]. There is also a working implementation using procedural macros [2]. [1] https://github.com/rust-lang/rfcs/pull/2033 https://github.com/rust-lang/rfcs/pull/2033 [2] https://github.com/alexcrichton/futures-await https://github.com/alexcrichton/futures-await
dom96 9y ago
If you want a compiled systems language with async/await you should take a look at Nim. Implemented fully using macros so you can even extend it (Nim's metaprogramming features are awesome).