5 ms·

I used to think thay I'd like working with advanced type systems with their "If it compiles, it works" guarantee. However, I recently spent some time working o

by jatins 5y ago

I used to think thay I'd like working with advanced type systems with their "If it compiles, it works" guarantee. However, I recently spent some time working on a TS codebase with libraries like GraphQL Nexus and that changed my mind. The errors become impenetrable pretty quickly. I'd say a "good enough" type system like Go's is probably better for most teams. Advanced types come with a power that I wouldn't trust most devs, including myself, with.

whateveracct 5y ago
> Advanced types come with a power that I wouldn't trust most devs, including myself, with. It's sad that TS has turned people off an entire paradigm despite it being a terrible representative of said paradigm.
mdtusz 5y ago
I may be biased from my past experience, but graphql tends to make codebases a nightmare if you aren't the one that initially set up the system and abstractions - it's (IMO) unnecessarily complex and blurs so many boundaries with a pretty poor tradeoff when compared to "normal" APIs. After Rust, I think typescript is my favourite language to write these days because of how expressive the type system is - my only complaint is that there's no clean way to bind an interface implementation to a pure data shape like you can in rust and you're forced to either use classes or some sort of DIY binding to an object prototype. As long as types are kept simple (i.e. avoid weird type tricks unless you actually need them) debugging is usually fairly straightforward assuming you have appropriate tooling setup with your editor/ide. My biggest gripe with Go is that I find myself wanting more expressivity - not just to minimize boilerplate, but to constrain the data flows and how parts of the code are allowed to fit together.
- lucian1900 5y ago
  And nulls. It’s frustrating that Go programs crash so often with code the compiler allowed.
- ervine 5y ago
  > blurs so many boundaries with a pretty poor tradeoff when compared to "normal" APIs. I'd love to hear more on this, I've been feeling this way for a while when using graphql-code-generator and apollo-client with react. It feels like there's no layer between data coming into the view from the backend. Because the queries / mutations are strongly typed with typescript, we end up passing the shape of the request around as a Type, so anytime we want to change our queries, we end up having to touch a lot of application code, instead of having a nice layer between that would handle the transformation. This is exacerbated by the use of apollo-client's `useQuery` and `useMutation` hooks, which really seem to encourage you to make the requests directly from your views. At first this all feels amazing, but once the codebase is large enough, I am really start to feel like not having a data transformation layer between the requests and the views is insanity, but everything in the documentation and ecosystem seems to encourage you to do it the way I described above. This may not be at all what you meant, but I'd love to hear your thoughts, I haven't seen anyone else really talk about this.
jamil7 5y ago
> I used to think thay I'd like working with advanced type systems with their "If it compiles, it works" guarantee. I think honestly TS is a poor representation of this guarantee, it's extremely easy to trick the compiler and it often doesn't offer you the guarantees you think it does. Because of JS being so widespread TS has become a lot of people's interpretation of this idea. It's not to say it's a bad language and can't help a lot on larger JS projects but I think it shouldn't be put into this category of languages.
lifthrasiir 5y ago
> advanced type systems This word is unfortunately overloaded; it can mean either more expressive power or more guarantee, of which TypeScript has the former. TypeScript in particular has a very complex type-level evaluation with less guarantee than conventional strong type systems.
kubb 5y ago
This is until you work in Go for some time like me and you find things that are unnecessarily unsafe or difficult because of the insufficient type system. Even worse if it won't bug you when you're coding but it will crash in production. Typescript is complicated because it was bolted onto Javascript and has to cover its use cases. A leap from "Typescript is complicated" to "most teams should use Go" is too far fetched. These languages aren't even in the same domain.
Latty 5y ago
You might want to check out Elm. It offers that "if it compiles, it works" guarantee, but does so much more simply and with excellent errors. You do pay for that in terms of having to write some boilerplate and not having some nice abstractions, but it does mean you don't have that issue of impenetrable errors.
- jamil7 5y ago
  I feel building a few apps in Elm some years ago had a big impact on my programming style. I never used it professionally but was excellent as a learning experience. Similar to how people describe using something like Haskell but with less upfront cost.
Zababa 5y ago
The thing is, Typescript is forced to make compromises because one of their goal is to "type the existing Javascript world". Depending on what you consider an "advanced" type system, OCaml and the likes (Hindley-Milner types systems) can be considered as advanced (for example compared to Go) but are way easier to understand and use than TS. I remember that one of the arguments of Rescript (a descendant of OCaml made to be compiled to JS) was that their type system covers most of the cases with little mental overhead, and for the rest you have the usual escape hatches. However TS won in the JS ecosystem and now it's hard to avoid its complexity sometimes. Complex types systems also tend to attract people that tend to built towers of abstractions and complexity because they can. It's a bit like pattern abuse in the OO land.
- benrbray 5y ago
  I constantly find myself wishing for something in between Haskell and TS. I want Haskell pattern matching and typeclasses with TypeScript's records / structural types. Haskell's language extensions are nice but not strictly necessary.
  - Zababa 5y ago
    I think Purescript would fit the bill: https://www.purescript.org/ https://www.purescript.org/

by jatins 5y ago

whateveracct 5y ago

> Advanced types come with a power that I wouldn't trust most devs, including myself, with. It's sad that TS has turned people off an entire paradigm despite it being a terrible representative of said paradigm.

mdtusz 5y ago

I may be biased from my past experience, but graphql tends to make codebases a nightmare if you aren't the one that initially set up the system and abstractions - it's (IMO) unnecessarily complex and blurs so many boundaries with a pretty poor tradeoff when compared to "normal" APIs. After Rust, I think typescript is my favourite language to write these days because of how expressive the type system is - my only complaint is that there's no clean way to bind an interface implementation to a pure data shape like you can in rust and you're forced to either use classes or some sort of DIY binding to an object prototype. As long as types are kept simple (i.e. avoid weird type tricks unless you actually need them) debugging is usually fairly straightforward assuming you have appropriate tooling setup with your editor/ide. My biggest gripe with Go is that I find myself wanting more expressivity - not just to minimize boilerplate, but to constrain the data flows and how parts of the code are allowed to fit together.

lucian1900 5y ago
And nulls. It’s frustrating that Go programs crash so often with code the compiler allowed.
ervine 5y ago
> blurs so many boundaries with a pretty poor tradeoff when compared to "normal" APIs. I'd love to hear more on this, I've been feeling this way for a while when using graphql-code-generator and apollo-client with react. It feels like there's no layer between data coming into the view from the backend. Because the queries / mutations are strongly typed with typescript, we end up passing the shape of the request around as a Type, so anytime we want to change our queries, we end up having to touch a lot of application code, instead of having a nice layer between that would handle the transformation. This is exacerbated by the use of apollo-client's `useQuery` and `useMutation` hooks, which really seem to encourage you to make the requests directly from your views. At first this all feels amazing, but once the codebase is large enough, I am really start to feel like not having a data transformation layer between the requests and the views is insanity, but everything in the documentation and ecosystem seems to encourage you to do it the way I described above. This may not be at all what you meant, but I'd love to hear your thoughts, I haven't seen anyone else really talk about this.

jamil7 5y ago

> I used to think thay I'd like working with advanced type systems with their "If it compiles, it works" guarantee. I think honestly TS is a poor representation of this guarantee, it's extremely easy to trick the compiler and it often doesn't offer you the guarantees you think it does. Because of JS being so widespread TS has become a lot of people's interpretation of this idea. It's not to say it's a bad language and can't help a lot on larger JS projects but I think it shouldn't be put into this category of languages.

lifthrasiir 5y ago

> advanced type systems This word is unfortunately overloaded; it can mean either more expressive power or more guarantee, of which TypeScript has the former. TypeScript in particular has a very complex type-level evaluation with less guarantee than conventional strong type systems.

kubb 5y ago

This is until you work in Go for some time like me and you find things that are unnecessarily unsafe or difficult because of the insufficient type system. Even worse if it won't bug you when you're coding but it will crash in production. Typescript is complicated because it was bolted onto Javascript and has to cover its use cases. A leap from "Typescript is complicated" to "most teams should use Go" is too far fetched. These languages aren't even in the same domain.

Latty 5y ago

You might want to check out Elm. It offers that "if it compiles, it works" guarantee, but does so much more simply and with excellent errors. You do pay for that in terms of having to write some boilerplate and not having some nice abstractions, but it does mean you don't have that issue of impenetrable errors.

jamil7 5y ago
I feel building a few apps in Elm some years ago had a big impact on my programming style. I never used it professionally but was excellent as a learning experience. Similar to how people describe using something like Haskell but with less upfront cost.

Zababa 5y ago

The thing is, Typescript is forced to make compromises because one of their goal is to "type the existing Javascript world". Depending on what you consider an "advanced" type system, OCaml and the likes (Hindley-Milner types systems) can be considered as advanced (for example compared to Go) but are way easier to understand and use than TS. I remember that one of the arguments of Rescript (a descendant of OCaml made to be compiled to JS) was that their type system covers most of the cases with little mental overhead, and for the rest you have the usual escape hatches. However TS won in the JS ecosystem and now it's hard to avoid its complexity sometimes. Complex types systems also tend to attract people that tend to built towers of abstractions and complexity because they can. It's a bit like pattern abuse in the OO land.

benrbray 5y ago
I constantly find myself wishing for something in between Haskell and TS. I want Haskell pattern matching and typeclasses with TypeScript's records / structural types. Haskell's language extensions are nice but not strictly necessary.
- Zababa 5y ago
  I think Purescript would fit the bill: https://www.purescript.org/ https://www.purescript.org/