Haha yes you're right - the map/filter/reduce style isn't that new really if you look at what you can do in Java and Javascript.
So yes, Java and JS (but not Go) already allow you to do this. But, arguably, Rust takes FP a step further - its type system is very refined and reminded me of Haskell's, which enables Rust to do some really nifty things.
So my point was more that Go does not allow you to use this style (at least not in a generic way).
But I understand the point about the problems that Google wanted to solve with Go.
I was already impressed with the size and quality of both the ecosystem and the community around Rust - ORM is there, web server/REST API server, remoting etc. If they are able to speed up the compiler a bit, then I think Rust can have a good future competing with Go.
By the way, your example of an async function makes sense, Go Routines aren't that much more than the "Promises" and "async/await" style that we already know from JS, but with some nice "syntax sugar".
If we simplify Go's channels into just an unbound stream of typed messages, we could use reactive streams RxRust e.g..
But we won't be able to exactly reproduce the comfort of language level features for asynchronously waiting for a return value, while the runtime takes care of halting the thread execution until said response really arrives.
"While the concept of 'goroutines' is unique to Go, they represent a feature of many languages known as green threads, where there are an arbitrary number of green threads per system thread.
Once upon a time in pre 1.0, Rust natively implemented green threads. It was decided however that green threads were somewhat antithetical to Rust's philosophy, particularly the aim of having a minimal runtime, so they were dropped in favour of system threads."
So okay, you can achieve the same thing but it will probably "feel" less seamless than it does in Golang.
Right! so there you have it ... however when I read the article that these Rust channels are for "native OS threads" rather than the 'green threads' or coroutines that we're talking about?
Haha yes you're right - the map/filter/reduce style isn't that new really if you look at what you can do in Java and Javascript.
So yes, Java and JS (but not Go) already allow you to do this. But, arguably, Rust takes FP a step further - its type system is very refined and reminded me of Haskell's, which enables Rust to do some really nifty things.
So my point was more that Go does not allow you to use this style (at least not in a generic way).
But I understand the point about the problems that Google wanted to solve with Go.
I was already impressed with the size and quality of both the ecosystem and the community around Rust - ORM is there, web server/REST API server, remoting etc. If they are able to speed up the compiler a bit, then I think Rust can have a good future competing with Go.
By the way, your example of an async function makes sense, Go Routines aren't that much more than the "Promises" and "async/await" style that we already know from JS, but with some nice "syntax sugar".
How would you implement Go's "channels" in Rust?
Yea, our opinions seem to match there. :-)
If we simplify Go's channels into just an unbound stream of typed messages, we could use reactive streams RxRust e.g..
But we won't be able to exactly reproduce the comfort of language level features for asynchronously waiting for a return value, while the runtime takes care of halting the thread execution until said response really arrives.
Right, I see, yes that's what Rust doesn't have, Go's runtime ... so that means it would be hard to implement it in exactly the same way.
Some "history" on Reddit (reddit.com/r/rust/comments/a6f85e/...
"While the concept of 'goroutines' is unique to Go, they represent a feature of many languages known as green threads, where there are an arbitrary number of green threads per system thread.
Once upon a time in pre 1.0, Rust natively implemented green threads. It was decided however that green threads were somewhat antithetical to Rust's philosophy, particularly the aim of having a minimal runtime, so they were dropped in favour of system threads."
So okay, you can achieve the same thing but it will probably "feel" less seamless than it does in Golang.
Yes, exactly. :-)
One more thing I actually forgot about and which may actually help and is more native than using something like Rx: Rust channels
Right! so there you have it ... however when I read the article that these Rust channels are for "native OS threads" rather than the 'green threads' or coroutines that we're talking about?
Yep, no green threads for Rust. Those channels are indeed thread backed. :-)