From Rust to TypeScript

Author here. Thanks for the correction.

You caught me red-handed for not testing these codes in playground.

In JS it's the function would be converted to a string representation of its code and concatenated to the result of `bar(someNumber)`.

Some quick playing with ts-node says that the same thing should happen, depending on the return type of bar. Given the definitions above, it should throw a TypeError, but if bar returned a string, I think it would still behave as I said.

Plus the undefined name 'number' in foo(). TypeScript flags that along with 'baz();'.

What does puzzle me is that TS doesn't flag 'return bar(someNumber) + bar;' - I'm curious if anyone knows why it seems to allow that.

Sounds like you posted this comment after only reading that example at the beginning. Did you read the rest of the article? What were your thoughts at the end of it?

I really wish the TS team would have used frozen null prototype objects for enums instead. Feels like it would have been a perfect fit.

With that said I am curious why you think one shouldn’t use enums. I know it’s a “factory” IIFE like namespaces at runtime but otherwise I don’t understand why it’s undesirable?

There are also const enums, which get inlined/erased at compile time. Even so, I still avoid using enums and prefer literal types instead.

I don’t understand why so many people advise against TS enums. The string variant is no different at runtime from a const of the same mapping, but they also achieve nominal typing in an otherwise structural type system, which is super useful for preventing ambiguity errors

1.

Ah thanks for the suggestions. These reminds me scrounging this article https://dev.to/gcanti/getting-started-with-fp-ts-either-vs-v...

My pet peeve doing this in JS/TS is the fact that writing

``` fold( () => someIdealVal, () => someNonIdealVal )(someAssertion(someValue)); ```

means that those functions passed as the parameters might be instantiated at the execution time rather than on compile time. (This is not proven as the final resulting machine code depends on how good the bundler(webpack)/compiler(tsc)/runtime(v8/rhino) is)

For the sake of performance, I am tempted to write it like this

``` const a = () => someIdealVal const b = () => someNonIdealVal

const someFold = fold(a, b); ```

Writing it like this feels worse for readability. The "story of the function" cannot be told top to bottom, therefore other devs who read this must jump between lines non-sequentially like watching Christopher Nolan's memento.

Rather than pitting readability against performance, I prefer to shelve that fold/pipe/chain pattern for later consideration

2.

I can relate to this. Enums are frustrating especially if you have to write library with it.

I have a pretty good time using this alternative instead. https://medium.com/@martin_hotell/10-typescript-pro-tips-pat... this article point number 4

The article doesn't get into it, but Rust has an error-handling operator, `?`, that encapsulates the branch-and-return-on-error check. Your code in Rust would look like:

    fn foo() -> SomeResult {
        let result = bar()?;
        let result2 = baz()?;
        let result3 = bazz()?;
    }

The fundamental difference between Rust's approach and Java-style checked exceptions arises when those three functions have different error types. In Java, you would annotate the function with every possible exception that the function can throw. In Rust, a library (or module within a library) would normally design its own Result type to encompass every error that the library/module can throw, and use that type on every error-producing function (you could reproduce the Java approach by defining a new Result type for each function, but I've never seen anyone bother with that). The end result is that you avoid the precise bookkeeping that so annoys people about Java's checked exceptions, but you also tend to lose some precision with reading the code: from reading the type signature you know that a function with a custom error type has the potential to error, which is useful, and you know that the error must be at least one of the types in the error's definition, but it might not exhibit all of the error types that the custom error type can contain. Think of it like a spectrum: from not having any indication that that a function may error (e.g. JavaScript), to knowing that a function may error but not having any indication of how (Swift), to knowing a function may error with at least one of a known set of types (Rust), to knowing that a function may error with an exactly known set of types (Java with checked exceptions).

Go does indeed use the tedious approach. Rust and Zig have nicer syntax for it.

But personally, I prefer even Go's "tedious" approach to (unchecked) exceptions, simply because it's too easy to miss an error case otherwise.

I also find that knowing where errors occur is important information, so I don't really mind having it add an extra line or two. (But the more minimal Rust/Zig syntax is nicer.)

(This attitude comes from having once worked on a python server application, which involved a lot, "oh shit, that throws" whackamole.)

In Rust, your code would look like this:

  fn foo() -> Result<i32> {
      let result = bar()?;
      let result2 = baz()?;
      let result3 = bazz()?;
  }

(This wouldn't compile because you don't actually return anything in the success case, but I just kept the code the same. Additionally, I am assuming you are using some sort of crate that helps with error type mapping, because that's realistic, otherwise, it would be Result<i32, Error> where Error would be some sort of type mapping to SomeException's type.)

> How do people using Go and other languages that don't have exceptions solve this reduced readability problem?

We don't, we just make memes about it and move on.

>The problem with error code return is tediousness

Tediousness is only relevant at the time of writing the code, which is the least important part of programming. You read code 100x times as often as you write it, writeability is simply the wrong aspect to optimize for.

>How do people using Go and other languages that don't have exceptions solve this reduced readability problem?

Readability isn't reduced, it's enhanced - the control flow is explicit, there's no magic in the form of implicit returns.

Checked exceptions are evil because they can cause transitive API breakage in cases a function or method doesn’t catch because it can’t or shouldn’t handle the condition.

The Either monad is a very nice solution for this in my opinion, in Haskell it's just

  do bar
     baz
     bazz

with it immediately returning after the first error value it encounters or returning the actual result (this is also how Rust solves it, though they introduce specific syntactic sugar for it rather than an universal monadic sugar).

Rust has an operator for "re-throwing" error: question mark.

  fn foo() -> Result<int, SomeError> {
     let result = bar()?;
     let result2 = baz()?;
     let result3 = bazz()?;
     Ok(result + result2 + result3)
  }

It's still 100% more explicit about return types and errors, but has the same lightweight feel as in JS/Java/etc.

The problem with exceptions is they make it way too easy to not handle and error. At least with the first example you had to at least think about the error as you typed return err.

You're not supposed to catch exceptions. They are not for handling logic. They're there to make fatal errors across threads and modules be safe and robust.

To add on to what other commenters have pointed out with `?`, there's also the interesting [fehler crate](https://github.com/withoutboats/fehler), which lets you write code that _looks_ like it uses exceptions.

It wouldn't make the examples that already use `?` any clearer, but it does reduce noise around the happy path.

> How do people using Go and other languages that don't have exceptions solve this reduced readability problem?

Having a single clear return path with, e.g., monadic returns and pattern matching is more readable than exceptions (particularly, the signatures are more readable than with checked exceptions effectively splitting the type system into two separate components with distinct syntaxes).

OTOH Go (which has a very close equivalent of exceptions but idiomatically prefers using it's annoying multivalue return pattern in most public APIs) is pretty much the worst of all worlds.

There are roughly three kinds of exceptions.

The first is the set of exceptions that could potentially be caused by any basic instruction that are really more of a "the programmer screwed the code up, and our static type system isn't powerful enough to prove it can't happen." Think Java's RuntimeException, the basic processor signals in C/C++ (SIGSEGV, SIGFPE, SIGILL, SIGBUS), or Rust panics. For these exceptions, the standard handling behavior is to catch it at a very high level, log as much details as you can about what caused the exception, fail the task (e.g., return HTTP 500 error), and throw away the detritus. These exceptions should be as invisible to the user as possible, and ideally you want to spend a lot of time at the point the exception is thrown collecting as much information as possible for logging purposes (such as stack traces).

The second class is the exact opposite: you're doing a simple operation that is expected to fail. Such as opening a file (it might not exist) or querying a hashtable (the key might not exist). Errors here are almost always going to be handled immediately by the caller, and so collecting a lot of details about the error is not usually what you want to do. Using a simple error code for return is precisely what you want to do in this situation.

The final class of exceptions is perhaps the most common: you have failures that need to be communicated from point A in the system to point B somewhere distant. My prototypical example is a (recursive-descent) parser: if the lexer sees a token it doesn't understand, you want the entire lexer and parser call stack to propagate the error to the caller of the parse function. Sometimes with these errors, you want or need to attach more contextual information as they propagate: in a SAX-like parser, you might want to explain the path to the token that failed.

For the last error class, error-code handling is clearly too cumbersome for most use cases. The easy propagation of C++/Java-style exception helps, but unifying the underlying implementation with the first implementation may be unnecessarily penalizing speed. And the silent propagation turns out to be a disaster for both user maintainability and compiler optimization. That such an exception can be thrown needs to be a fundamental part of the type of the function. Java introduced checked exceptions to express this type correctly, but the way exceptions integrate with the rest of the type system has turned out to be less than satisfactory.

On top of these exception classes, there are two more important considerations. The first is the general need to recognize chaining of exceptions: you may need to explain the cause of a high-level exception in terms of a specific low-level exception. The second is that you may want to convert between the different classes--turning a file-not-found exception into a hard program crash, for example. (This is especially useful when writing exploratory code!)

In my opinion, none of the languages I'm familiar with have solved all of the issues with exceptions. Exceptions are hard to design right, and since they're so fundamental to how you express code, they're a feature that is baked so early in the process and is difficult or impossible to change as you discover problems with it. I do think that Rust's Result-versus-panic, with the ? syntax for Result propagation (as noted by several sibling comments) is a good starting point, but my feeling is that more work needs to be done on easing the burden of specifying exception types when you're plumbing together many stages and libraries.

>How do people using Go and other languages that don't have exceptions solve this reduced readability problem?

Rust has ? operator which converts "let x = foo()?" into "if foo returns Ok(value) assign value to x, otherwise make the function in which it is used return given error". Go doesn't care about readability.

Yes, this schizophrenic attitude drives me bonkers. Immature JS kids at my company love to make noises about Java’s verbosity yet spend hours debugging and troubleshooting most mundane errors because seemingly nothing is ever enforced by the JS interpreter.

My theory is that nowadays Java is unpopular mostly because it is their parents’ programming language. That’s reason enough for these twenty somethings to despise it without even knowing the first thing about it.

Author here. I used io-ts when the documentation is still on its root README.md. Apparently it has been moved to https://github.com/gcanti/io-ts/blob/master/index.md

I've been rolling io-ts into an app I inherited and have been porting to TypeScript. If you know a little Haskell/Scala type FP, the docs are plenty. I think the lib could definitely have a shallower learning curve for folks coming from Go though (what my back end devs write mostly).

Totally agree.

In cases where the error type matters, I like to return rather than throw the error.

    type Success = string
    type Result = Success | BadInputError | NotFoundError | IncalculableError

    const foo = (input: I): Result => {
      //...
   }

The joke is, OO language have sum types, albeit incredibly broken ones, because any set of classes that inherits from the same base has the base as a sum type.

You can surface this by implementing the visitor pattern.

Author here. Caught red-handed not running it on playground. Thanks for the correction.

> I’d generally prefer to use exceptions to indicate exclusively programmer errors

The idea that panic/exception means programmer errors worth to be noted. It think they should be intended for errors that is intended to be unrecoverable. Still, catching errors on runtime is not fun

Author has now fixed the example: https://news.ycombinator.com/item?id=24454455

I agree with Maybe not being that useful in TS but the point of an Either/Result type is that the caller is gonna handle it each branch differently. In your example the caller has no way to tell the difference between an error and the succesful return value.

I’ve seen and used the Maybe version of this a few times, I really like this Typescript feature. Using it for errors is clever :)

Author here, thanks for the input. Forgot to put it in my backlog :pepesad:

I think it’s best to stay language agnostic especially in 2020. I try to think data-in data-out and use the best tools available for clean execution.

Didn't mean to cherry-pick

I believe that programming language has the power to push its user to write in a certain way, not just a mere tool to convert idea to machine code.

What I learnt by writing Rust turns out to be useful when applied in other language.

Author here. Did this too. I found some quirks (rather irrelevant) while compiling using TypeScript 3.6-ish.

``` const { value, error } = result; if (error) return doSomething(); if (value) return doSomethingElse(); ```

^ You can't do this because value or error might be not an attribute of result

Nowadays I will just `npm install fp-ts` and use them.

Exceptions aren't typed though so you either have to decode it in some way or treat every exception the same.

Rick’s argument seems to be that we should have better tools in the language type system. If your language doesn’t give you those tools, these are still very useful types. In addition, the library maintenance issues he raises seem trivially solvable with languages that allow function polymorphism or have refactoring tools to me.

The author of a dynamically typed language thinks strongly typed constructs are bad? You don't say...

It is worth noting that you can throw anything you want. It doesnt' have to be new Error(). There are definitely some drawbacks to this, such as if the errors thrown by your dependencies are of type Error, but the upside is that as long as you are consistent, you get a much richer set of types available.

IMO this also works primarily because errors are very rarely thrown by native APIs, which instead encode failure into the return type. For this reason, you can typically have a reasonable level of control over what code can reasonably be expected to throw.

f(), g() and h() are decent alternatives.

Of course, the real solution is to come up with an reasonable example scenario with meaningful names.

Yep.

I dont think it matters

>code smells

This is one of the worst "ideas" ever in programming. It allows any programmer to shit on any other programmer's work in practically any arbitrary way they feel like.

Your idea of returning default is considered by others here to be a "code smell" - if you want to call it that.

Looks like using that term just doesn't give your idea any benefit the way you thought it would.

Honestly that sounds substantially worse in pretty much every way in nearly every situation. If an assumption of your program has broken, you almost always want to do something about it rather than simply silently producing garbage. Even in a less expressive language like C you'll still often use e.g. a negative return code to indicate failure.

How do I know if it errored or not? The default value is ambiguous. It either means that it's the correct result or that the function errored. Sure, the program might not crash right then and it will compile, but it's guaranteed to lead to confusion for both users and programmers who have to debug it.

This is worse in every possible way. If the default value was part of the domain of the function it would be impossible to distinguish an error from a legit answer without breaking encapsulation. If it wasn't, then you're handling errors like in C.. ugh

> 1 / 0 just returns 0, #yolo

No thanks.

I think monads are especially useful when the whole eco-system is build around it.

Using promises with callback APIs gets ugly quickly.

Using results with exception APIs also isnt much fun.

Rust shines here because it's the default way.

I can see the author's point, that a throw behaves awfully like a GOTO. It can add complexity and unpredictability to the code path, especially dealing with external modules.

On the other hand, there are situations in which throw/catch provides a simpler, even elegant way to handle errors.

So I'd agree with you that both are useful.

The author makes a good point though, and I will consider it next time whether returning errors may be more suitable, to be clear and explicit/verbose, without requiring the GOTO-like control flow.