this post was submitted on 24 Jul 2026
25 points (100.0% liked)
Programming
28086 readers
502 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
These kinds of struggles with JavaScript and TypeScript are part of why I moved to Rust. I value the sanity checks the compiler provides: warning when a
Resultis ignored and refusing to compile when amatchon anenumis missing a branch.Also, in Rust,
Resultis for recoverable failures, whilepanic!is generally reserved for bugs, broken internal assumptions, or cases where the program has reached a state that it believed should be impossible.I'm using Rust on the server, Typescript on the client. Some very interesting options have appeared in Typescript over time for better ADT handling!
ts-pattern provides a match function that verifies matches are exhaustive. Yes, it's a static check. It's got a powerful matching language that does stuff like extract nested properties from complex inputs, like Rust's match. I recommend reading the documentation - for me it led to some "I didn't know that was possible!" moments.
I've also been using fp-ts to get
OptionandEithertypes. (Eitherinstead ofResultbecause fp-ts is inspired by Haskell.) It has features for processing fallible values as monads which gets close to the conciseness of Rust's?operator and try Trait, but is more generalized. It also has mtl-ish types likeTaskEitherwhich roughly serve the purpose of a Promise but with an explicit error type.Now that you mention it, must-use detection for
Eithervalues would be helpful. Eslint has a built-in check that does exactly that for Javascript's native Promise type. I haven't tried it, but it looks like eslint-plugin-fp-ts has a rule that might do the same for other types.Yeah, in most languages
panic-type operations are relatively expensive compared to return-compare operations, and most languages recommend not using throw as a common-case branching pattern when testing return values is available. You usually don't want throw/catch to be called in a tight loop.