4 ms·

I've developed with JS, PHP, and Ruby for about 5 years. Then I switch to statically type languages for the next 5 years (Scala then to Typescript). If I had to

I've developed with JS, PHP, and Ruby for about 5 years. Then I switch to statically type languages for the next 5 years (Scala then to Typescript). If I had to choose, I would choose static typing. For small projects, dynamically typed languages are fine. but as the project grows bigger, the static typing will help and will make thing simpler. As the project grows, refactoring will be an issue. Static typing will make it simpler to refactor. Tests are smaller. Reading the code will be easier since you know the contract of functions. Fewer runtime errors since most errors will be caught at compile time. Also, the stronger the type system it is, the more it will be caught at compile time. I don't think it slows me down that much. It's a little more typing, and there is compile time overhead. In some cases, you have to work your way around the type system. But at least with Scala, I am confident my code will work as intended as long as it compiles successfully. I spend less time debugging in runtime and writing tests. I think static typing might save time in the long run but not short run.

say-vagnes 6y ago
Hey, I've also made the trip from Scala to Typescript. We're talking ZIO and Shapeless wrangling. Twitter vs Scala futures. All that fun stuff (and I loved scala nonetheless). Would love to know how your journey was. At first I was super hesitant, but now I am actually floored at the power Typescript has. The ability to tell the compiler to simply "trust me" has enabled me to build many abstractions I'd battle for hours to do in Scala.
- mbo 6y ago
  Hey, same situation! As the resident rabid FP evangelist at work, people are often surprised by how much I like like TypeScript. Personally, I think structural typing systems are the path forward for functional languages, and that means accepting that Haskell needs to go to move on to a retirement home. I was pleasantly surprised by how well Scala did subtyping with ZIO's `Has` + variance annotations. Shame TypeScript is bivariant with function parameters.
  - kingdomcome50 6y ago
    I agree so hard
- meowzero 6y ago
  I haven't played with ZIO that much. I do like it though. It seems to make your Scala code much more functional. I'm 100% TypeScript now and miss Scala. I miss using monads. But since Typescript doesn't have for comprehensions, using any of the monad libs for TS (like fp-ts) is messier than plain old TS. Also, Typescript doesn't have pattern matching, thus ADTs are more painful in TS. But TS is a nice language. Instead of monads, they have stuff built into the language to make things easier and cleaner like null coalescing (compared to Option) and async/await (compared to using IO or Future). I can live with that. I've grown to like TS. I'm curious what abstractions you had easier time with in TS compared to Scala.
  - say-vagnes 6y ago
    A lot may have been simply my own inexpertise in Scala. But I remember it being much more of a fight, and subject to much more nuanced errors, to do anything interesting with generics or any more advanced typing. I would often stop, whereas at the same point in Typescript, I can just cast, and then see what actually happens at runtime. If I fail to be creative enough with my types, so long as I satisfy the type contract at some level, I can be wild wild west in the internals. I do miss the for comprehensions, but have built an abstraction that does the same thing for my purposes. It isn't quite as good, due to the whole monad thing, and me fitting it to the average Javascript programmer who won't want to learn functional programming all at once. So at its core it is pretty much async/await with sugar. I quite enjoy exploiting structural typing for unit testing purposes. Gone is the need to learn a mock framework and its DSL; just write plain ol' JS for the parts you are interested in, and tell the compiler to chill. ;) Long term, of course, you should probably just have doubles.

say-vagnes 6y ago

Hey, I've also made the trip from Scala to Typescript. We're talking ZIO and Shapeless wrangling. Twitter vs Scala futures. All that fun stuff (and I loved scala nonetheless). Would love to know how your journey was. At first I was super hesitant, but now I am actually floored at the power Typescript has. The ability to tell the compiler to simply "trust me" has enabled me to build many abstractions I'd battle for hours to do in Scala.

mbo 6y ago
Hey, same situation! As the resident rabid FP evangelist at work, people are often surprised by how much I like like TypeScript. Personally, I think structural typing systems are the path forward for functional languages, and that means accepting that Haskell needs to go to move on to a retirement home. I was pleasantly surprised by how well Scala did subtyping with ZIO's `Has` + variance annotations. Shame TypeScript is bivariant with function parameters.
- kingdomcome50 6y ago
  I agree so hard
meowzero 6y ago
I haven't played with ZIO that much. I do like it though. It seems to make your Scala code much more functional. I'm 100% TypeScript now and miss Scala. I miss using monads. But since Typescript doesn't have for comprehensions, using any of the monad libs for TS (like fp-ts) is messier than plain old TS. Also, Typescript doesn't have pattern matching, thus ADTs are more painful in TS. But TS is a nice language. Instead of monads, they have stuff built into the language to make things easier and cleaner like null coalescing (compared to Option) and async/await (compared to using IO or Future). I can live with that. I've grown to like TS. I'm curious what abstractions you had easier time with in TS compared to Scala.
- say-vagnes 6y ago
  A lot may have been simply my own inexpertise in Scala. But I remember it being much more of a fight, and subject to much more nuanced errors, to do anything interesting with generics or any more advanced typing. I would often stop, whereas at the same point in Typescript, I can just cast, and then see what actually happens at runtime. If I fail to be creative enough with my types, so long as I satisfy the type contract at some level, I can be wild wild west in the internals. I do miss the for comprehensions, but have built an abstraction that does the same thing for my purposes. It isn't quite as good, due to the whole monad thing, and me fitting it to the average Javascript programmer who won't want to learn functional programming all at once. So at its core it is pretty much async/await with sugar. I quite enjoy exploiting structural typing for unit testing purposes. Gone is the need to learn a mock framework and its DSL; just write plain ol' JS for the parts you are interested in, and tell the compiler to chill. ;) Long term, of course, you should probably just have doubles.