I wrote a large web app in scala using Futur only and it turned into a monster because of it. Even if you don’t use callback you still need to manualy unwrap them and they pollute your méthode signature.
Then more recently I wrote a pub/sub server in c# using the “await” keyword. While much better it still polute your method signature and make the debugger and stacktrace useless. Also you still have to think about trying to no make anything that could block spinlock or calling api that are not Async ex: Createfile
Compare this to Golang where project like Groupcache (1) have super clean code that replaced a thousand line of code C++ system at google.
Why do you think Golang fiber/gorotine are worse ?
One big advantage of Futures is they are decoupled from their execution environment.
For example, different types of executors can be used depending on the type of Future. For example, you may have an IOThreadPoolExecutor to handle accepting and responding to connections that should spend very little time blocking and a CPUThreadPoolExecutor for offloading heavy processing. In Go, you have no say in how goroutines are scheduled, you sacrifice control to reduce complexity.
Another big one in network programming is the polling mechanism. In Go, you have no control over your polling mechanism, whereas with a Future is decoupled from the event loop, and you can write your own event loop on any experimental kernel APIs you'd like.
Rust made the right move because in Rust, just as in C++, we want maximum control. Futures are more primitive, and it's possible to build coroutine models on top of them, but not vice versa.
My understanding is the main issue with “await” model is that you only abstract The Task model.
Running task don’t gave a real ID and stack like “Go” and “Erlang” you can list all running fiber how much memory and CPU they use ...
I believe you could write your own event loop easily in Go if they exposed the internal api used to pause and resume goroutine, you can already pause goroutine by having them wait on a mutex and resume them from your custom event loop by releasing that mutex.
You can drop to raw fd's and do whatever you like... of course this negates a lot of the niceties that go affords you.
No, fibers were removed with nothing to replace them. The futures as we know them today did not exist in the far, far past when fibers and the whole runtime thing got dropped.
You wouldn't want a Go-like M:N solution in Rust. It would be slower for no reason.
Depends on how many threads you have and what OS you’re running on.
you don’t have to pay the memory usage and context switch cost you would have if using large amounts of threads.
It’s also faster to do IO processing from a single thread in batch instead of having one OS thread per request.
Memory usage per thread is a property of the GC, not M:N threading. You can have very small stacks in a 1:1 implementation too.
You can also read data from several file descriptor in a single System Call.
This way you significantly reduce the number of System call instead of doing one blocking read() per connection. I believe context switch round trip (from user space to kernel to user space) is much more expensive than simply switching between goroutine of the same process.
Chrome manages to do async stack traces for their implementation of the similar JavaScript feature. I wonder if this would be possible for C# and Rust.
I've looked at ilovecaching's comment history (at least up to ~60 days ago) and they seem consistent on being a networking programmer who uses C++. Was there a particular comment you found which would indicate this isn't the truth?
why would you make me do this? you can doxx people on your own dime... still, for posterity:
https://news.ycombinator.com/item?id=18328964 "...now I am working full time as a Rust developer"
https://news.ycombinator.com/item?id=18310666 "As a long time Erlang developer..."
https://news.ycombinator.com/item?id=18265199 "As someone who has worked two jobs now writing, deploying, and operating Erlang clusters, I recommend switching to Rust."
https://news.ycombinator.com/item?id=18251478 "Becoming a professional Haskell and Erlang developer really shifted my view on OOP"
https://news.ycombinator.com/item?id=18185795 "I've been using Rust in production for a little over half a year, and my team and I have run into very few issues. [...] We're all extremely glad we chucked C++ and Go and switched to Rust. "
https://news.ycombinator.com/item?id=18171917 "I am exclusively using Go and Rust at home and at work, and I find myself equally productive in both."
you get the point.
For example, in the same comment that begins with "As a long time Erlang developer", they later continue: "I’m more optimistic about Rust ... We’ve been able to scale Rust to handle the same load as our Erlang cluster". So there's no contradiction here.
1) rust genuinely is a great language and his opinion in the comment is something I have as a professional c++ programmer or the past
2) his comment history is only suspicious and only mildly, there's nothing outright contradictory. I would give him the benefit of doubt.
Rust is great, and I highly recommend learning Rust if you want to become a better C++ developer. C++ introduces a lot of unnecessary headaches Rust completely solves. Rust is worth the switch if only because reading error messages from expanded templates is horrible compared to type system that actually understands type parameters.
I'm really bullish on Rust becoming even more mainstream, to the point anyone can pick it up and use it in their business without a second thought by 2020.