TypeScript: add difference between promises and async computations #9
Conversation
avm99963
force-pushed
the
push-youytoquvlpu
branch
from
e2d7333 to
5a7d19b
Compare
| * The equivalent of `await` in TypeScript, is simply the addition of the `!` character to the let statement in F#. | ||
| * In TypeScript, you can convert computation-heavy synchronous methods into asynchronous by using `async` keyword in function definition, in F# you simply wrap them with an `async{}` block (a computation expression). | ||
|
|
||
| Moreover, there's a subtle difference: in TypeScript, a promise can either be fulfilled or rejected. However, in F#, an `Async<'T>` object will always return a value of type `'T` once it is run. To achieve something similar in F#, you can return a value of type [`Result<'T,'TFailure>`](https://learn.microsoft.com/en-us/dotnet/fsharp/language-reference/results) or use [`Async.Catch`](https://learn.microsoft.com/en-us/dotnet/fsharp/tutorials/async#asynccatch) to catch exceptions that are thrown during its execution. |
There was a problem hiding this comment.
hey @avm99963 thanks for this PR, glad to see you back over here :) I was gonna merge right away but then I double-checked how can you check if a promise has been "rejected" in TS/JS, and it's via try-catch! Which means it's kinda the same in F# actually, well, actually with F# you would start an Async job with an API call first, for example, two cases:
- If you use Async.StartAsTask then you get a
Task<T>, but if there was an a problem with the task, as soon as you try to retrieve its result, an exception would be thrown. - If you instead run it with Async.RunSynchronously, then the exception would be thrown right away as a result of the invocation of this
Async.RunSynchronouslyfunction.
So it looks like the error handling basics of both TS/JS and F#/.NET are similar; and if you don't want to deal with exceptions but instead with error "codes" or cases, then you would use Result DU in F#, and another approach in TS?
There was a problem hiding this comment.
Thanks for the correction, @knocte! Indeed, the paragraph I added is not precise.
I read https://learn.microsoft.com/en-us/dotnet/standard/threading/exceptions-in-managed-threads and thought that an exception in an F# job that runs in a separate thread would crash the entire program, but I see this is not the case when using the 2 methods you stated. So I didn't build my mental model for F# properly :P
I double-checked how can you check if a promise has been "rejected" in TS/JS, and it's via try-catch!
Yup, in Javascript you can use try-catch blocks to handle errors thrown by awaited promises. It is syntactic sugar over the Promise object, and it is the most common syntax used (source: first-party experience at work and open-source projects).
When writing that paragraph I was thinking about the Promise object itself, which reminds me of the concept of railway programming, since you chain .then(), .catch(), and .finally() methods which deal with the results of fulfilled or rejected promises (so, approx. Result in F#, with fulfilled = Ok and rejected = Error). But I don't think it is relevant mentioning it in the guide.
I guess the only suggestion I have then is to fix the "TypeScript" typo ;) I'll close this PR and open another one with that change.
Thanks!
There was a problem hiding this comment.
thanks Adria, I like your attention to detail! because of that, I'd like to mention, just in case of the odd chance that you might be looking, that my company is always hiring; and precisely I see you're a student, so you might like our deal even better in your case, because we hire remote and only part-time (20h a week); shoot me an email if you're interested ;) our tech-stack is TS&FS. (NB: if you do, just note I won't probably reply until late Feb because I'm actually today going on holiday hehe.)
2 participants
No description provided.