Quite an unusual take. There are millions of developers who prefer TypeScript over JavaScript for any job, including self-founded products.
But even if they didn’t exist, it’s a non sequitur. There are very good reasons for type systems regardless of how projects are founded.
You might not realize that Go has a very limited and awkwardly designed static type system that is the sole reason reason people prefer it for certain tasks over Python, which has both a dynamic, and by now an optional static type system.
Your final point, that types make things more complex and harder to develop is also flawed. Type systems exist to decrease the mental overhead and unload it from the programmer onto the compiler.
They might require more work upfront, but make software more solid, easier to reason about and easier to change. If you’re building a one-off that you will never change then a type less language might be of interest to you.
But it’s short sighted to think that you will be able to write it once and keep it running forever. Only managers who don’t code believe fairy tales like that. In reality many people sit down on a codebase, they fix things, and add functionality. When they do, they want to avoid bugs, they want the compiler to help them, they want LSP, they want to avoid null pointer dereference, double free, they want to be safer, and more productive.
They’d rather spend a week upfront instead of a day so that every one of the later changes takes a day instead of a week.
Also, types are a spectrum. C++ has types, Objective-C has types. Those alone have enough success stories to fill tomes! But of course you’re talking about strong static type systems like Haskell, Ocaml, Scala or ML, so you should read up on Jane Street. Or Mercury. Blockchains like Cardano.
Personally I think the onus is on you to prove that types are _not_ useful. Many of us enjoy types.
Pretty much all successful indie games use typed languages. Of course, there is a mix with untyped scripts in there too. But many only depends on typed languages.
But even if they didn’t exist, it’s a non sequitur. There are very good reasons for type systems regardless of how projects are founded.
You might not realize that Go has a very limited and awkwardly designed static type system that is the sole reason reason people prefer it for certain tasks over Python, which has both a dynamic, and by now an optional static type system.
Your final point, that types make things more complex and harder to develop is also flawed. Type systems exist to decrease the mental overhead and unload it from the programmer onto the compiler.
They might require more work upfront, but make software more solid, easier to reason about and easier to change. If you’re building a one-off that you will never change then a type less language might be of interest to you.
But it’s short sighted to think that you will be able to write it once and keep it running forever. Only managers who don’t code believe fairy tales like that. In reality many people sit down on a codebase, they fix things, and add functionality. When they do, they want to avoid bugs, they want the compiler to help them, they want LSP, they want to avoid null pointer dereference, double free, they want to be safer, and more productive.
They’d rather spend a week upfront instead of a day so that every one of the later changes takes a day instead of a week.