3 ms·
Sure, but that is incredibly weak from a typing point of view, and not compiler-checked in most languages. You have no clean way of describing multiple pre-con
by dawidloubser 11y ago
Sure, but that is incredibly weak from a typing point of view, and not compiler-checked in most languages.
You have no clean way of describing multiple pre-conditions (refusal reasons), or to evolve those over time in existing systems, without assuming that developers will somehow correctly read your API documentation, and manually write the code everywhere to handle all possible exceptions, with no help from your compiler or your language's type system.
This is how to indicate exceptions in the 1970s. The world has moved on since then :-)
- lmm 11y agoLanguage level exceptions are how to indicate exceptions in the '90s. The world has moved on since then. Modern languages have a compiler-checked sum type, and protobuf can support these (oneof). You get the good parts of exceptions (being able to cleanly separate error handling from happy-path code, and doing it concisely and readably via do-notation or equivalent) without the bad parts (invisible nonlocal control flow, breaking referential transparency, hard to abstract over). (You still have the problem of returning a new type of error condition that your client code wasn't expecting, but it's the same problem as returning a new type of successful value that your client code wasn't expecting, and you can solve it in the exact same way).
- dawidloubser 11y agoI'm not trying to be facetious, but do you literally just mean Haskell? Because none of the languages widely used in corporate / industry do. I'd settle for 1990s tech over 1970s tech any day when it comes to contracts (APIs).
- lmm 11y agoScala - which I've been using in corporate/industry for 5 years now - works as I described. Of course that's only my experience. (There are certainly plenty of places stuck on older tech - but I'd think those places won't be interested in adopting something as new as GRPC)