6 ms·

I recently started a new project. I started with kotlin and react. I was working on creating typings for redux, router, etc. Encountered a lot of issues. Moved

I recently started a new project. I started with kotlin and react. I was working on creating typings for redux, router, etc. Encountered a lot of issues. Moved to typescript, things were great till I went to add redux and router. There were typing issues being worked out in the recent development branch. A few weeks back. I love typescript. The IDE experience via visual studio is great. But I was burning a lot of time working on type libraries/definitions. I switched to flow. I miss visual studio code and some of the typescript features. But adding typing to a react project, especially with redux and immutable is great. The typing ecosystem of flow and typescript is truly impressive. With support for union types, strong structures. Really good inference. I'm just waiting for better pattern matching with active expressions. Please steal that from F#. This is also interesting for kotlin. https://github.com/Kotlin/ts2kt https://github.com/Kotlin/ts2kt

StreamBright 9y ago
Have you seen Reason yet? It has pattern matching. https://reasonml.github.io/docs/en/pattern-matching.html https://reasonml.github.io/docs/en/pattern-matching.html
- soulnothing 9y ago
 I haven't yet thank you. I like the ocaml influence.
 - bratsche 9y ago
 Since you mentioned F# above, have you seen Fable? http://fable.io/ http://fable.io/
 - thangngoc89 9y ago
 ReasonML is OCaml. The syntax is different but the semantic is the same, it uses the same OCaml compiler
- boubiyeah 9y ago
 That's pretty much the only thing I like from reason. it's still very goofy. (ReasonReact.stringToElement(string_of_int(count))) Compared to { count } in ReactTS... The interop with JS is pretty verbose too. The tooling... Doesn't work at all? :p It might get there eventually but it doesn't seem like facebook has more than 1 or 2 engineers working on it.
 - girvo 9y ago
 (se(count)) I’ve just built a tiny utils.re file that holds a couple of small modules, like the se function above. The built in reducerComponent with a completely flat pattern matching on the action types, values, arity and more is so lovely that I hate going back to regular React + Redux
 - boubiyeah 9y ago
 Can you post that util file as a gist?
 - girvo 9y ago
 https://gist.github.com/girvo/a20de20e0556ff161b04f6467d7d9ba1 https://gist.github.com/girvo/a20de20e0556ff161b04f6467d7d9b...
 - rhizome 9y ago
 (ReasonReact.stringToElement(string_of_int(count))) MV. Bold choice.
Karnickel 9y ago
I've been a heavy user of Flow for - two years now? I also occasionally use TypeScript. I don't contribute to the code (in the Flow case, I don't speak OCaml, I contributed a bit to the type library and the online docs; in the case of TS, I don't use it enough), but I write a bug report each time I find an issue. I've been looking at the issues list very often, mostly out of curiosity to see what the problems are that people have (both Flow and TS) and to see which project is better at solving problems. TypeScript seems to win hands down. Their ratio of closed tickets to open tickets is far better than that of Flow: - TypeScript: 2,515 open, 12,716 closed -- https://github.com/Microsoft/TypeScript/issues https://github.com/Microsoft/TypeScript/issues - Flow: 1,830 open, 2,467 closed -- https://github.com/facebook/flow/issues https://github.com/facebook/flow/issues I have to assume they mostly close issues after solving them - it is not unheard of that issues are closed merely because they've been lying around for a few months without any updates (definitely happens for Flow). I prefer the approach of Flow, but I think the actual developers are not present at all on Github, most answers come from other users. There are very few actual solutions to issues that are raised. The list of issues grows ever larger. Flow does make progress, and it's not even bad. Every 10-15 days we get a new release and I'd say the progress is quite okay. What went really well the last 12 months was IDE integration for Flow in the case of Jetbrains Webstorm (for TS the situation always looked good), as of now, latest Webstorm version, it's actually usable. I still get too many Flow server crashes though, which may be due to my platform (Windows 10), not sure. However, it's now automatically restarted most of the time. A TypeScript anecdote: I filed an issue that a "Member" closed as "works as intended" after a few comments back and forth (but it was clear right away that this would be the end). I filed it again - this time Anders Hejlsberg himself responded and acknowledged the issue (it was kind of fundamental and not just something unimportant), and it got fixed. So here too you need a bit of luck to get through to someone who actually understands the subject well enough (including knowing when they don't understand it, if that first guy had just stopped handling my issue it would have been fine). But that's the price of using a popular large project, so this is not a complaint - just an anecdote, okay? What I do get for myself after following the two type systems for well over two years is that there are LOTS of restrictions. Just read some of the issues in both Github repos, it's really interesting. I find the whole situation very unsatisfying. It is clear - when you actually use it heavily for a big project for a longer period - that a type system on top of Javascript is very difficult to maintain. LOTS of unsolved cases and issues. You definitely have to adapt and use only the subset of Javascript and the type system that works. I validate an object manually and I still have to do an "any" cast in Flow because Flow does not recognize that my `if` statement secures the type. Or I have to insert such `if` statements even though from the context it is perfectly clear what I get there. For example, any inner functions, e.g. when using map, filter, reduce, loses the type if you use a variable from the outer scope. Or you have to use a lot of additional `const` for object properties even though you don't change the object - but the type checker is not intelligent enough to recognize that. You definitely write different code - and while that may seem okay there are plenty of cases where it really is objectively unnecessary, but you have to do it to satisfy the type system. On the bright side, once you get your code all "type system ready" you really do find bugs - even if it's just a few. Also good is that I now get much better autocompletion suggestions in the IDE. There's a reason why I (as project head) still insist on us using Flow even though I say "WTF?" often enough. It does cost a significant amount of time though - a very significant amount. I've been willing to do it because of the kind of project, which is going to be a very low-level building block for later larger projects, so it is worth spending a lot more resources on getting it right compared to a project that's on a top layer, on which nothing else depends. Still, overall I have very mixed feelings and I see the type checkers (both TS or Flow, or any other that could be written) on top of a language that doesn't have types as a kludge that does not look like a long-term solution. There is too much friction between the language and the type system.
shados 9y ago
with either TypeScript or Flow, you can't go very far before hitting type definition hell. It just shifts where the hell is. Flow has better types out of the box for the Facebook ecosystem, and the flow-typed types, if they're available, are generally higher quality (unless it's for a lib that was made with TS in mind, like RxJS). TypeScript has massively more typedefs of highly varying quality, and there's more stuff written in TypeScript itself. However, so many of them are broken or are incompatible with strict mode (next person who says TS matches Flow because it has strict null can take the door, thx). Fortunately, TS makes it much easier to override broken type definitions. It's a real toss-up which one is better, but both are filled with tears and pain. That pain can (and is often) worth it, but it's absolutely not the slamdunk people around here make it out to be. Unless you REALLY like abusing the any type, in which case what was the point again?
- rtpg 9y ago
  I don't mean this dismissively but Typescript's type system is insanely flexible, and _should_ let you do basically anything you want. Especially when you look at union types, sum types, type guards, the `never` type.... As a bonus, if you are willing to generate type definitions from other sources (like your backend code) you can go super far. I do agree that the current `@types` solution without versioning isn't very great. Though I've found that for libraries without good definitions, hacking out a simple interface for the layer you use is good. Just doing interface SomeLib {}; declare var lib:SomeLib; and then filling in the errors can be pretty quick in most projects. It makes sense to use libraries, but writing up an interface definition for a library you use is usually quick enough. I'd love to hear about cases where type definitions really messed you up.
  - teniutza 9y ago
    I've had the same experience as you did. When there's no type definition available, starting from an empty object quickly resolves a lot of the issues. But that really depends on the complexity of library you're trying to declare. On the other side, I've also had cases when the type definitions were a pain. We have a web app and use .Net/TypeScript/React. We also use the commercial Kendo UI version. Since there's no versioning available (and the Kendo UI team doesn't seam keen on "type correctness"), we are (almost) always using a type definition file for another (newer) version of Kendo UI. We've had to "patch" the definitions on several occasions.
cel1ne 9y ago
Did you use IntelliJ IDEA for kotlin? If not you're missing a giant part of the experience and ease-of-use.

StreamBright 9y ago

Have you seen Reason yet? It has pattern matching. https://reasonml.github.io/docs/en/pattern-matching.html https://reasonml.github.io/docs/en/pattern-matching.html

soulnothing 9y ago
I haven't yet thank you. I like the ocaml influence.
- bratsche 9y ago
  Since you mentioned F# above, have you seen Fable? http://fable.io/ http://fable.io/
- thangngoc89 9y ago
  ReasonML is OCaml. The syntax is different but the semantic is the same, it uses the same OCaml compiler
boubiyeah 9y ago
That's pretty much the only thing I like from reason. it's still very goofy. (ReasonReact.stringToElement(string_of_int(count))) Compared to { count } in ReactTS... The interop with JS is pretty verbose too. The tooling... Doesn't work at all? :p It might get there eventually but it doesn't seem like facebook has more than 1 or 2 engineers working on it.
- girvo 9y ago
 (se(count)) I’ve just built a tiny utils.re file that holds a couple of small modules, like the se function above. The built in reducerComponent with a completely flat pattern matching on the action types, values, arity and more is so lovely that I hate going back to regular React + Redux
 - boubiyeah 9y ago
 Can you post that util file as a gist?
 - girvo 9y ago
 https://gist.github.com/girvo/a20de20e0556ff161b04f6467d7d9ba1 https://gist.github.com/girvo/a20de20e0556ff161b04f6467d7d9b...
- rhizome 9y ago
 (ReasonReact.stringToElement(string_of_int(count))) MV. Bold choice.

Karnickel 9y ago

I've been a heavy user of Flow for - two years now? I also occasionally use TypeScript. I don't contribute to the code (in the Flow case, I don't speak OCaml, I contributed a bit to the type library and the online docs; in the case of TS, I don't use it enough), but I write a bug report each time I find an issue. I've been looking at the issues list very often, mostly out of curiosity to see what the problems are that people have (both Flow and TS) and to see which project is better at solving problems. TypeScript seems to win hands down. Their ratio of closed tickets to open tickets is far better than that of Flow: - TypeScript: 2,515 open, 12,716 closed -- https://github.com/Microsoft/TypeScript/issues https://github.com/Microsoft/TypeScript/issues - Flow: 1,830 open, 2,467 closed -- https://github.com/facebook/flow/issues https://github.com/facebook/flow/issues I have to assume they mostly close issues after solving them - it is not unheard of that issues are closed merely because they've been lying around for a few months without any updates (definitely happens for Flow). I prefer the approach of Flow, but I think the actual developers are not present at all on Github, most answers come from other users. There are very few actual solutions to issues that are raised. The list of issues grows ever larger. Flow does make progress, and it's not even bad. Every 10-15 days we get a new release and I'd say the progress is quite okay. What went really well the last 12 months was IDE integration for Flow in the case of Jetbrains Webstorm (for TS the situation always looked good), as of now, latest Webstorm version, it's actually usable. I still get too many Flow server crashes though, which may be due to my platform (Windows 10), not sure. However, it's now automatically restarted most of the time. A TypeScript anecdote: I filed an issue that a "Member" closed as "works as intended" after a few comments back and forth (but it was clear right away that this would be the end). I filed it again - this time Anders Hejlsberg himself responded and acknowledged the issue (it was kind of fundamental and not just something unimportant), and it got fixed. So here too you need a bit of luck to get through to someone who actually understands the subject well enough (including knowing when they don't understand it, if that first guy had just stopped handling my issue it would have been fine). But that's the price of using a popular large project, so this is not a complaint - just an anecdote, okay? What I do get for myself after following the two type systems for well over two years is that there are LOTS of restrictions. Just read some of the issues in both Github repos, it's really interesting. I find the whole situation very unsatisfying. It is clear - when you actually use it heavily for a big project for a longer period - that a type system on top of Javascript is very difficult to maintain. LOTS of unsolved cases and issues. You definitely have to adapt and use only the subset of Javascript and the type system that works. I validate an object manually and I still have to do an "any" cast in Flow because Flow does not recognize that my `if` statement secures the type. Or I have to insert such `if` statements even though from the context it is perfectly clear what I get there. For example, any inner functions, e.g. when using map, filter, reduce, loses the type if you use a variable from the outer scope. Or you have to use a lot of additional `const` for object properties even though you don't change the object - but the type checker is not intelligent enough to recognize that. You definitely write different code - and while that may seem okay there are plenty of cases where it really is objectively unnecessary, but you have to do it to satisfy the type system. On the bright side, once you get your code all "type system ready" you really do find bugs - even if it's just a few. Also good is that I now get much better autocompletion suggestions in the IDE. There's a reason why I (as project head) still insist on us using Flow even though I say "WTF?" often enough. It does cost a significant amount of time though - a very significant amount. I've been willing to do it because of the kind of project, which is going to be a very low-level building block for later larger projects, so it is worth spending a lot more resources on getting it right compared to a project that's on a top layer, on which nothing else depends. Still, overall I have very mixed feelings and I see the type checkers (both TS or Flow, or any other that could be written) on top of a language that doesn't have types as a kludge that does not look like a long-term solution. There is too much friction between the language and the type system.

shados 9y ago

with either TypeScript or Flow, you can't go very far before hitting type definition hell. It just shifts where the hell is. Flow has better types out of the box for the Facebook ecosystem, and the flow-typed types, if they're available, are generally higher quality (unless it's for a lib that was made with TS in mind, like RxJS). TypeScript has massively more typedefs of highly varying quality, and there's more stuff written in TypeScript itself. However, so many of them are broken or are incompatible with strict mode (next person who says TS matches Flow because it has strict null can take the door, thx). Fortunately, TS makes it much easier to override broken type definitions. It's a real toss-up which one is better, but both are filled with tears and pain. That pain can (and is often) worth it, but it's absolutely not the slamdunk people around here make it out to be. Unless you REALLY like abusing the any type, in which case what was the point again?

rtpg 9y ago
I don't mean this dismissively but Typescript's type system is insanely flexible, and _should_ let you do basically anything you want. Especially when you look at union types, sum types, type guards, the `never` type.... As a bonus, if you are willing to generate type definitions from other sources (like your backend code) you can go super far. I do agree that the current `@types` solution without versioning isn't very great. Though I've found that for libraries without good definitions, hacking out a simple interface for the layer you use is good. Just doing interface SomeLib {}; declare var lib:SomeLib; and then filling in the errors can be pretty quick in most projects. It makes sense to use libraries, but writing up an interface definition for a library you use is usually quick enough. I'd love to hear about cases where type definitions really messed you up.
- teniutza 9y ago
  I've had the same experience as you did. When there's no type definition available, starting from an empty object quickly resolves a lot of the issues. But that really depends on the complexity of library you're trying to declare. On the other side, I've also had cases when the type definitions were a pain. We have a web app and use .Net/TypeScript/React. We also use the commercial Kendo UI version. Since there's no versioning available (and the Kendo UI team doesn't seam keen on "type correctness"), we are (almost) always using a type definition file for another (newer) version of Kendo UI. We've had to "patch" the definitions on several occasions.

cel1ne 9y ago

Did you use IntelliJ IDEA for kotlin? If not you're missing a giant part of the experience and ease-of-use.