Depends on the language, but when you have to use some metaprogramming gymnastics, then types are really hindering to develop something generically, if the language doesn't provide a fully developed type systems, which few systems have. For example higher-kinded types are quite essential, but not always given. Then I prefer dynamic typing and get this done fast without safety. But then I remember getting a lot of bugs in certain types of applications, maybe one fifth, or something.

Go is not statically typed, really. Consider using Haskell, if not Agda.

About "type-related programming bugs." I once took endeavour to write cycle-accurate MIPS CPU simulation in Haskell. Most of the errors I uncovered were easily preventable with the types - mark integers with their size in bits and you will never add instruction pointer to an unaligned offset. Haskell did not had proper types at the time but later I used that trick quite successfully.

With the types you can eliminate whole classes of logic errors. They just will not appear before end user.

Do type related programming bugs include null pointer errors? I also think this 2% stat is just complete bs. Anyway, this debate is over. Absolutely every top language designer has seen the merit of statically typed languages, if not for avoiding type errors then for making code refactorable.

For me it’s never been about type bugs but rather about being able to work comfortably with the code. Some of us don’t have amazing the greatest working memories; having the IDE offering support with types is a godsend. Python’s my prototyping language and I start adding types very early on, if not right from the start.

Safe and sane refactoring is impossible even in mid sized code-bases without static types.

Dynamic languages are strictly only viable for throwaway code, or very small programs (where small means something up to two pages of code max, or so).

And yet Ruby and Python dominate in the most valuable YC startups.

Either "safe and sane refactoring" isn't necessary to create value. Or you're just wrong.

Sure it's not necessary when you produce throwaway code.

Most startups do exactly this.

That's even a valid strategy: Concentrate on the business case only, redo the code when you get successful and have the money to rewrite everything. (Of course quite some companies misses of missed the right time to throw away everything and rewrite it. This results later on in a huge and very expensive PITA; some of the companies affected even started to build their own compilers and static checkers for the languages they use; just look who pays for static type checkers for Python or Ruby).

So the path to success is the following:

1. Write a bit of code (two pages max).

2. Become a unicorn.

3. Rewrite everything.

Either there's something missing between steps 1 and 2, or dynamic languages allow you to become a multi-billion dollar company just by writing two pages of code. I mean they are concise, but not that concise.

But it sounds like no amount of evidence will convince you. You have to invent weird terms like "sane refactoring" and "throwaway code" that do all the heavy lifting in your religion.

If you are presented with evidence that a lot of successful companies are doing refactoring with dynamic languages, you will say "it's not sane refactoring" (no true Scotsman) or say those companies are outliers (ignoring the fact they are overwhelming majority).

But all of that doesn't matter. Those companies are still more successful.

Really? About 30% of the bugs we find in our entirely-Golang codebase are something that is trivially solved by a more advanced type system, and it was even higher back when I worked on Python.

I have the opposite experience. Most of the bugs in my code are type-related issues, and once I fix those (usually with the help of the compiler, since I prefer statically-typed languages), my code usually runs correctly the first or second time. Throughout the 2022 AOC I only had 2 (out of 49) parts where I had a logic error that type checked but did not run properly, which I needed to debug. But in almost every part I had the compiler point out issues that I had to fix before the solutions would run at all.