วีดีโอ

Thank you, Timo, for your kind words! Looking forward to it too :)

I'm glad it was helpful! The important thing it to understand the principle, the library you use is not that important. Heck, you can implement the Result type on your own too! ;)

@@BeyondTypeScript Yea! You are totally right

Thank you for the suggestion! Indeed, there are lots of alternatives to `ts-results`.

Thank you for your comment! Generally speaking, for safeParseInt there are indeed just two outcomes - either int or Error (with only one possibility for sad path - 0). So, it's okay to return int | Error. However, the Result type help to turn a partial function (not defined for all inputs) into a total function (defined for all inputs), by returning a value of type Result<V, E> instead of int (for example). Notice that the Result type takes two generics - Result<Value, Error> and can be constructed in two ways - Ok<Value> or Err<Error>. However, the Error generic can hold another ADT for all possible outcomes (in more complex cases). For example, a file system operation can fail for a number of reasons - all of them can be defined as an ADT (by the way, same is true for the happy outcomes). This situation would be a bit cumbersome to describe without any differentiation mechanism - int | FileNotFound | BadPath | FileLocked | Whatever. Compare this to Result<int, FileSystemError>. On top of that, sometimes, there are cases where your function may return int | int - but which one is which? All in all, I'd say that it's a good practice to stick to a single code style - either throwing exceptions, or int | Error, or Result type. Mixing them will lead to confusion in the team. However, if I have a choice, I always use the Result type. I hope it all makes sense :)

Completely agree!

I appreciate your comment, thank you! Yeah, that the goal.

I've learned a lot from your comment, thank you! 🙏 You are right, you can compile Rescript code into JS code. However, the compiler performs type checking, and Rescript is a language with strong typing. Therefore, type coercion is impossible. You'll need to write mapping functions. Examples of such functions are "Int.toString" or "Int.fromString". It may sound like a lot of work, but this way, if it compiles, it is correct. Also, you'll need to prove to the compiler that the data coming into your program is what's expected (think decoders). Thank you for your comment and I hope it helps!

@effect/schema is a good example of powerful and safe type coercion at runtime (encoder/decoder pattern).

I get your point. The good thing is that both can co-exist too, we don't have to choose either or. Rescript is a tool to get the job done. Most importantly, we can learn the differences between type systems, ecosystem, etc. These new ideas alone will help make better choices and decisions in the future.

I didn't know about this library, thank you for sharing! But as I read ts-belt, the first thing I thought about was Rescript's Belt :) I'll give it a go.