Flow vs. Typescript

Post by RX14 » Mon, Jun 06, 2016, 10:03 AM UTC

cageface wrote: post #48

Hurtak wrote: post #30

Earlier quoted context omitted.

> - if people enter or leave your team frequently: yes Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one

The learning curve on something like TS for people already conversant in JS is pretty shallow. I think the time invested learning it will pay for itself very quickly on any non-trival project. I wish I had something similar for all the Ruby code I write.

Post by realharo » Mon, Jun 06, 2016, 10:10 AM UTC

chvid wrote: post #41

I am the only one who is happy to code without static typing? Enjoying fast compilation, small, fast editors, flexibility. I don't really make stuff like marry(a, b) and then call it with a banana and an apple by accident. Sure I make plenty of mistakes when I am coding but only very few could have been caught by a static type check. Take one of the examples in the slides: let obj: string; obj = 'yo'; // Error: Type…

    // let's pretend the values are not dummy values, etc.
    function getWeather(encodedWeatherString) {
        return { temperature: 50, windDirection: 'east' }
    }
    
    function getWeatherFromUrl(url) {
        return { temperature: 20, windDirection: 'east' }
    }

    function getWeatherFromUrl(url) {
        return { temperature: 20, windDirection: 'east', time: new Date() }
    }
    
    function displayWeather(weather) {
        return "It was " + weather.temperature + " on " + dayOfWeek(weather.time.getDay())
    }

Post by k__ » Mon, Jun 06, 2016, 10:10 AM UTC

itsyogesh wrote: post #65

bsimpson wrote: post #61

Earlier quoted context omitted.

I talked with Lee Byron about the differences and if there's hope for convergence at React Europe. He said: - the biggest difference is nullability (you have to explicitly set TypeScript to treat all types as non-nullable by default to get behavior similar to Flow's default). - Flow uses nominal typing (similar to functional languages); whereas, TypeScript uses structural typing (similar to Java). To be honest, I don…

I know I sound a little ignorant, but could you elaborate a little on nullability. I mean is it the same as checking whether an assignment is null or not? P.S. I haven't used either typescript or flow.

Post by k__ » Mon, Jun 06, 2016, 10:11 AM UTC

benjoffe wrote: post #63

k__ wrote: post #58

Earlier quoted context omitted.

Most static type systems really suck and I can fully understand why dynamic-coders don't like them. It often feels like they are holding you back more than they help. I also got such a moment with TypeScript. const a = A() a.b = new SubtypeOfB() a.b.attributeOfSubtypeOfB = 123 //error Because a.b is type B and not SubtypeOfB and so doesn't have the attribute of SubtypeOfB, but a.b gets its typing from A, which can't…

You can also use 'type assertions' to minimise restructuring, eg, the following is the same number of lines as your first example (and compiles to identical code): const a = A() a.b = new SubtypeOfB() ( a.b).attributeOfSubtypeOfB = 123 //works

Post by catnaroek » Mon, Jun 06, 2016, 10:33 AM UTC

bsimpson wrote: post #61

msoad wrote: post #22

Both differences in this presentation are addressed in TypeScript 2.0 https://github.com/Microsoft/TypeScript/wiki/Roadmap#20

I talked with Lee Byron about the differences and if there's hope for convergence at React Europe. He said: - the biggest difference is nullability (you have to explicitly set TypeScript to treat all types as non-nullable by default to get behavior similar to Flow's default). - Flow uses nominal typing (similar to functional languages); whereas, TypeScript uses structural typing (similar to Java). To be honest, I don…