TypeScript support in Electron

I'm much more bothered by TS's lack of separate compilation (errors tend to cascade, but this is to be expected from a structural rather than nominal type system).

The killer app for type systems has always been code completion.

I have a feeling you're talking about an old version of typescript. Versions 2.2+ (currently 2.3.2) are sound (but not fully so, just like flow) with the right flag(s).

Here's the description of the "strict" compiler option that goes a long way to make your program more reliable :

"Enable all strict type checking options. Enabling --strict enables --noImplicitAny, --noImplicitThis, --alwaysStrict and --strictNullChecks."

Can confirm. This has been my experience.

I thought I remembered using require statements and getting errors from the typescript compiler that it couldn't find the (typescript definitions for the) file.

In the rare cases we find a library that doesn't have a typescript definition, we just do:

   declare var Thing : any;

In a global definition file.

Pro tip. We've got a lot of mixed js and ts at the moment and when you're really lazy you can take advantage of how every object is a dictionary in js and just do something like `window["notification"]` instead of window.notification, which resolves to an 'any' type in ts.

Obviously you should try and minimise that usage, but it's a useful trick to know.

>But in your TS example, the code would execute.

Incorrect. It's a type alias so it uses "type typeof" not "value typeof". It doesn't have the problem that the issue you linked to is about.

https://www.typescriptlang.org/play/#src=function%20getOptio...

Observe the JS output contains no `typeof` and that the type `Options` is considered to be the same as `{ num: number, str: string }` if you hover over it.

> A type system can never catch all bugs

True, but that doesn't mean we shouldn't try to improve the type system. We've already seen large improvements in the past in TypeScript and flow. For example, nullable types were not there in the beginning but were added to the type system because they are immensely useful. Making the type system sound would be another such improvement.

If you start with that premise, why not "A type system can never catch all bugs, therefore let's not use it at all"? Sounds stupid, doesn't it?

> The most important goal - if you value reliable programs - is that the code is intelligible to people.

The code that's running the airplane I'm sitting in, I don't give a fuck whether it's intelligible. Though I do care very much that it has been formally proven to be correct. Having a sound type system is pretty much a prerequisite for formal proofs.

Also, intelligible code and soundness are not exclusive. What makes you think that? I can write unreadable looking code in JavaScript and Haskell. And I can write beautiful, readable, concise code in both languages, too.

Reading from the comments here, I believe that people don't realize how bad the unsoundness is in Typescript:

    class Dog { name: String }
    class Engine { name: String }

    function start(ref: Engine) {
      if (!(ref instanceof Engine)) 
        throw Error("oops")
    }

    // Typescript does not complain
    start(new Dog())

This sample is due to Typescript doing "structural typing". According to its rules, if Engine and Dog both have the "name" property, then they must have the same behaviour as well. This is also inconsistent with the behaviour of classes in Javascript (e.g. see the behaviour of `instanceof`).

The biggest problem is that generics are what they call "bivariant", which is lingo for "completely fucked up". Here's a classic gotcha that caught people by surprise with Java's array since forever:

    class Animal { isAnimal: Boolean = true }
    class Dog extends Animal { isDog: Boolean = true}
    class Cat extends Animal { isCat: Boolean = true }

    const dogs: Dog[] = [ new Dog() ]
    const animals: Animal[] = dogs
    animals.push(new Cat)

    for (const dog of dogs) console.log(dog.isDog)
    //=> true
    //=> undefined

Well, it's unfair to pick on this, since they give a similar example in their own documentation, right? But this extends to inheritance as well, because input parameters in functions are not contravariant in Typescript:

    abstract class FlatMap<A> {
      abstract flatMap<B>(f: (a:A) => FlatMap<B>): FlatMap<B>
    }

    class Box<A> extends FlatMap<A> {
      flatMap<B>(f: (a: A) => Box<B>): Box<B> {
        throw new Error("Not implemented!")
      }
    }

It should be obvious to everybody why this is wrong:

    class AnotherBox<A> extends FlatMap<A> { ... }

    const box: FlatMap<number> = new Box<number>()
    box.flatMap(x => new AnotherBox<number>())

In case you're wondering, that interface is the beginning of the Monad pattern and the problem here is that monads are incompatible with each other. So in order to compose instances together, you do rely on the compiler to protect you. Think Promises being combined with Arrays, both of which are monadic types. Not going to work, is it?

In less expressive static language lacking higher kinded types, which you need to express such interfaces, there's a current trick that people do to work around it: https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-ki... ; This has been used in Elm and it's being used in Kotlin as well, see for example: https://github.com/FineCinnamon/Katz

But Typescript is on a whole new level of wrong, because you can't trust the compiler for correctness, so you can't trust it for protection, at all. You see, this is not pie in the sky academics, but actual code that can happen in your app, mistakes that the compiler should have prevented you from making. In the above case Typescript really is just documentation and just like documentation in many cases, it can be wrong documentation. To make this even more frustrating, Microsoft's other language, C#, does not have the problems that I enumerated.

And I know what people say - oh, this is still useful. Well, guess what, writing JSDoc + having Google Closure to validate is actually more useful, while not being non-standard ;-)

> and leads to languages that cease to value other things like simplicity

Simplicity is subjective. Some people think that TypeScript is overly complex compared to simply using JavaScript. Other people feel like Scala's type system doesn't go far enough.

I'd say that in a type system, what is "simple" is what you're used to and understand, and what's "complicated" is what you don't.

Now, friction is another story, and some type systems are very friction heavy (Hello Java!), while some very sound type systems are not (Elm). While Flow has issues/bugs and an extreme lack of proper tooling, the type system itself arguably has less friction than TS. If the implementation was on par (that is, you changed nothing to the type system at all, but just improved documentation, tooling and stability), I'd be able to get my programs in a better state faster, with less typing and catching more bugs.

Unfortunately that isn't the case, and in the last couple of releases, TypeScript at least got decent enough to use.

Not sure that applies like that. Typescript support is based on the Typescript language server, which uses their open source language server protocol, which is open for other editors to use (and indeed adopted by a bunch of them). So in theory other IDEs could support TS with the same level of VSC as long as they adopted the protocol, without the need for discussion TS functionality.

The core of Code is Monaco, an editor component already powering Visual Studio Online. They already had a decent and fast editor and merely needed to package it into an application. Trying to shove that into Atom probably wouldn't have worked out well.