5 ms·

I spent quite a lot of time writing Typescript using Fluture and a few other libraries a while ago. Coming from a functional background, combinators + futures a

I spent quite a lot of time writing Typescript using Fluture and a few other libraries a while ago. Coming from a functional background, combinators + futures actually feels quite natural to me, so I looked at the examples of the "bad" code here and thought I actually quite liked it. But I certainly don't mind the async syntax too much either. Will see how it works out some time!

marcosdumay 7y ago
All that redundant noise is one of the main reasons why I avoid Rust if I can write something in Haskell. Rust has it everywhere, what is expected for a low level language, but as long as they can remove it, they indeed should.
- jkoudys 7y ago
  Coming from mostly Js/ts, I've had the opposite experience. I'm finding what I write on rust may be more explicit, but often less noisy. Using an error wrapping lib and ? everywhere made the biggest difference. May not be as efficient as the most optimized rust code, but far faster than the equivalent JS for the same thing. I also pray every day for macros to make there way into ts, since I'm constantly dealing with friction on the boundaries of runtime vs static code that rust handles nicely with a macro.
jkoudys 7y ago
Oh the combinators in rust can be great. I think making the code read more imperatively is often a case of confusing the familiar with the simple. TS makes combinators way better too. That's why it's the `.await?` that sells me on the whole concept. Writing an error-path separately can be a headache, and as a result I still have daemons that have some dependency with an `unwrap` that sits there, poised to crash everything without warning. The `?` has cut the length of some of my modules in half. I've been waiting for a good way to do the same in async code for a while.
leshow 7y ago
It's not just about the combinators vs specialized syntax. I've had to write a library with 0.1 futures and you have to implement a lot of Futures manually. i.e. you need to implement the Future trait for your types pretty often. In those cases you cant use the combinators, you need to directly drive the state machine of your future with poll() and try_ready macro etc. With async/await I don't have to implement any futures manually anymore, the diff of my library updating to async/await is basically deleting 75% of my code.
- jkoudys 7y ago
  Yeah and this is huge. Not something I realised I needed coming from my experience in js, but it's a big deal in rust. It's not that different from needing to manually branch match arms and `into` your errors back for `Result`s, when those could all be communicated just as clearly with the far more concise `?`. The `.await` removes so much re-implementing the Future trait. It's been especially bothersome for me, because often I'm trying to figure out how this particular library implemented their Future. Now I feel like if I get the gist of how a Result is returned, I can apply identical reasoning to how `.await` is returning my Future, except that it's suspending the function and saving the state. Obviously that's what a generator does, but the `.await` syntax is far more expressive than `await` in js, because passing back that `Result` is a much more difficult thing to manage by hand.

marcosdumay 7y ago

All that redundant noise is one of the main reasons why I avoid Rust if I can write something in Haskell. Rust has it everywhere, what is expected for a low level language, but as long as they can remove it, they indeed should.

jkoudys 7y ago
Coming from mostly Js/ts, I've had the opposite experience. I'm finding what I write on rust may be more explicit, but often less noisy. Using an error wrapping lib and ? everywhere made the biggest difference. May not be as efficient as the most optimized rust code, but far faster than the equivalent JS for the same thing. I also pray every day for macros to make there way into ts, since I'm constantly dealing with friction on the boundaries of runtime vs static code that rust handles nicely with a macro.

jkoudys 7y ago

Oh the combinators in rust can be great. I think making the code read more imperatively is often a case of confusing the familiar with the simple. TS makes combinators way better too. That's why it's the `.await?` that sells me on the whole concept. Writing an error-path separately can be a headache, and as a result I still have daemons that have some dependency with an `unwrap` that sits there, poised to crash everything without warning. The `?` has cut the length of some of my modules in half. I've been waiting for a good way to do the same in async code for a while.

leshow 7y ago

It's not just about the combinators vs specialized syntax. I've had to write a library with 0.1 futures and you have to implement a lot of Futures manually. i.e. you need to implement the Future trait for your types pretty often. In those cases you cant use the combinators, you need to directly drive the state machine of your future with poll() and try_ready macro etc. With async/await I don't have to implement any futures manually anymore, the diff of my library updating to async/await is basically deleting 75% of my code.

jkoudys 7y ago
Yeah and this is huge. Not something I realised I needed coming from my experience in js, but it's a big deal in rust. It's not that different from needing to manually branch match arms and `into` your errors back for `Result`s, when those could all be communicated just as clearly with the far more concise `?`. The `.await` removes so much re-implementing the Future trait. It's been especially bothersome for me, because often I'm trying to figure out how this particular library implemented their Future. Now I feel like if I get the gist of how a Result is returned, I can apply identical reasoning to how `.await` is returning my Future, except that it's suspending the function and saving the state. Obviously that's what a generator does, but the `.await` syntax is far more expressive than `await` in js, because passing back that `Result` is a much more difficult thing to manage by hand.