7 ms·
As someone that uses the language everyday, these are real quirks on the language, but they are not showstoppers. The benefits of using exactly the same languag
by Findeton 7y ago
As someone that uses the language everyday, these are real quirks on the language, but they are not showstoppers. The benefits of using exactly the same language in front-end and back-end, with shared types and everything, largely offset the small quirks.
However sometimes I kinda miss some functional stuff that you can for example find in Scala or Rust, like pattern matching. Specifically, we've had experience using/developing an input validation library for the backend in Typescript (https://github.com/StrontiumJS/Framework/ https://github.com/StrontiumJS/Framework/) that is composable and also returns the correct type in one go. We used a lot of try catches for that, but that makes validation slow. So we started using "maybe promises" which are similar to Scala's Futures with Success/Failure. But the fact you don't have pattern matching in Typescript like in Scala makes it a bit ugly.
- gazarullz 7y agoYou should try using computed propeties, it's the closest/cleanest way to pattern matching until tc39 will pass the pending proposal.
- firethief 7y agoHave you considered OCaml with BuckleScript or js_of_ocaml? The language that inspired Rust's nods to FP can be compiled to mostly-idiomatic Javascript.
- Shacklz 7y agoPattern matching is definitely something I also miss. For input validation and Optional/Either types, io-ts/fp-ts (https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts) fulfill my needs perfectly, especially io-ts is something I can't recommend enough. Saved me so many headaches from sudden breaking changes in APIs we consume.
- Fannon 7y agoPattern matching seems to be a current proposal, also driven by Microsoft: https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching