Starting a startup with typed code x none typed code

It doesn't matter. All that you need to focus on is building a product that users want.

For (almost) every language that exists, there's at least one startup using it that succeeded.

The argument of speed is not realistic. Time matters, that's true, but not to *that* extent.

Maybe the only factor that matters is how familiar you are with language (so that you can easily build your prototype/MVP) and how popular the language is so that you can easily recruit when the time comes.

It's a matter of speed. If you can get good at types in a short period of time, that will probably make you go faster in the longterm because you won't have a certain category of bugs. But if not, then just use JavaScript. You can always convert JS to TS later.

In fact you can use TS now, but write JS. It will just work. Then as you begin to feel more comfortable with features of TS, you can begin using them.

If you write JS, you are supposed to write a bunch of tests to catch possible regressions that TS's type system would catch for you at compile time. But tests are always a tradeoff; they take a little longer today to write for being able to move faster and more confidently later (this assumes you're writing good tests. Bad tests are generally worse than no tests).

It depends on what you are comfortable and familiar with and what your business related goals and deadlines are.

TypeScript in the long run is better as it will help ensure that the data flowing through your application is consistent, however, there is an upfront cost to learning to work with types that is not trivial. It will initially slow things down as you grapple with the stricter syntax and the tooling around it. For POCs if you are not an experienced programmer, this will likely add a lot of friction. Keep in mind though that when your application reaches a certain level of complexity, the cost of not having TS starts to exceed the cost of using TS. A good rule of thumb I go by is to try to pick up 1 new technology per project/sub-project. Hope this helps!

If you're not a good programmer, I would suggest that you find a technical cofounder and concentrate on whatever your skills are in. If you have no other skills, I would suggest you go learn some and come back in a few years.

But, since you asked, I have been programming professionally much longer than most HN users have been alive, and based on that experience, I have concluded that, all else being equal, languages with sophisticated static typing are superior to dynamically typed languages. Note the word "sophisticated": that specifically excludes, e.g., Java, which there's no good reason to start a new project in in 2021 anyway.

Use TypeScript. It'll actually make you faster. It relieves you from remembering things because your IDE will give absolutely fantastic contextual information (documentation, arguments, etc.)

This is a false equivalency that I see pop up pretty often. Like Use Types or Go Fast? Why are those the only options? Why does using types make you slower? If you're a slow typist then I suppose writing the types can take a little longer. Why is the comparison not Go Fast or Write Tests? A test suite with reasonable coverage is many times the amount of code that adding types takes.

Here's a great tool, https://quicktype.io/typescript . You can paste in JSON objects and it will spit out useful type definitions for your objects. The reality is that types exist in JavaScript and any other untyped language, they're just implicit. You have to read the code to know what they are. Then to help yourself or people who work with you, you will start writing examples either in the docs or in tests, and now you've informally specified your types. Or you don't do either then every time you or anyone else goes to edit a piece of code you have to read, understand, manually find all places you used that code and make sure you didn't break anything.

The purpose of a static type system is to find bugs, or issues with your code without even running it. The compiler will let you know if you make a change to the code which breaks the type you set. It can do a lot of the above mentioned work completely automatically.

You end up saving a lot of time not repeating work. One time working in python I had a problem that took me an hour to figure out. I had to look through a bunch of project code, then library code, and then I figured out that I just had put in the wrong shape of data. In a typed language it would have take me 30 seconds. The compiler would have complained and told me how I was wrong and then I would have fixed and moved on. At that moment I said "I'm getting too old for this shit", and then have never looked back from working with typed languages.

Secondly, TypeScript is not Java/C/C++. TypeScript has type inference and expressive type system. This means that you do not need to manually write the type for every single variable. Most you can omit because TypeScript is clever enough to figure it out.

Secondly, Structural typing is exactly how duck typing works in JavaScript and Python. Unlike those older languages you don't need to build huge class based hierarchies to make types that work in many situations. Define a minimal interface that you need for a function. Any object that has those properties will type check and work.

Check out Effective TypeScript, or Programming TypeScript. As a seasoned node developer I assure you that if you ever have teammates, types will help them contribute to a code base faster and with more confidence.

You need to slow down to move fast. Use typescript.

Use whichever invalidates your startup hypotheses faster.