I can only speak for TypeScript and Elm. And I must say that for those of you that really value the ergonomics of the language you use, Elm trumps JS & typescript. Not only do you not get runtime exceptions in Elm, but reasoning about complexity in Elm is much easier given the explicitness of its type system. In typescript you do not have a Maybe type which makes the notion of nullable objects explicit. In typescript you do not have a Result type, which makes failure situations explicit as well. All these additional types might make it seem like a burden to deal with, but what it actually does is force you to reason about all the various states of your program ahead of time instead of after you release and realize your users are looking at a runtime error caused by an edge case you didn't think about.
Edit: Spelling :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I can only speak for TypeScript and Elm. And I must say that for those of you that really value the ergonomics of the language you use, Elm trumps JS & typescript. Not only do you not get runtime exceptions in Elm, but reasoning about complexity in Elm is much easier given the explicitness of its type system. In typescript you do not have a
Maybetype which makes the notion of nullable objects explicit. In typescript you do not have aResulttype, which makes failure situations explicit as well. All these additional types might make it seem like a burden to deal with, but what it actually does is force you to reason about all the various states of your program ahead of time instead of after you release and realize your users are looking at a runtime error caused by an edge case you didn't think about.Edit: Spelling :)