> I find Haskell a joy to use, and I cringe at having to use languages like Java and Go, which are a minefield of error-prone programming patterns (like using products instead of sums to represent "result or error"). Generally speaking, my Haskell code is shorter, less buggy, and more reusable than my Go code, so I'm not sure what you mean by "cumbersome".
I just want you to realize that you are in the extreme minority here, but just from a common-sense POV, if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you. I just want to build something quickly without much hoopla (hence the massive popularity of very weakly-typed languages like JS and Python).
FWIW, I think that generics are a mistake in Go, but I was just trying to counter the point that language designers don't think long and hard about type-theoretic features. I think the main issue with generics, wasn't so much an inept "we don't know how to do this," but rather "is this worth the code complexity?" and "is this worth the added compile times?" -- both of which were main selling points of Go.
> I just want you to realize that you are in the extreme minority here
I'm in the minority because I've spent an unusual amount of time investing in my understanding of programming languages and their features, not because I have some fringe unjustified opinion.
> if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you.
With this comment you've lost your credibility in my mind. No one actually goes through this train of thought. I don't wonder about recursive enumerability whenever I start a project. I just use tools that help me build high quality software, such as principled static type systems.
> I'm in the minority because I've spent an unusual amount of time investing in my understanding of programming languages and their features, not because I have some fringe unjustified opinion.
I was just making a statement of fact. You're probably a very good programmer (as most type nerds, to coin a new term, tend to be), but still in the minority. Most programmers are not very good, and even good ones sometimes want to build things fast. (Where type ambiguity or even incorectness is accepted as a viable trade-off.)
This is why I stopped prototyping in Java, for example. JS just let me "do stuff" without thinking about it too hard. Lower code quality? Of course; but it let me try out more ideas in the same amount of time. Should you use JavaScript to write the operating system of a pacemaker? Probably not.
IMO there is also 'culture' to various programming languages in their styles, standard libraries and so on. I think Java as language is actually fine, it's all the crap that surrounds it that makes it more unproductive or not. I find my self even once I get past 2000 lines that using something like python is less productive than a statically typed language.
> I just want you to realize that you are in the extreme minority here
Considering how much people love and use Rust, Typescript and typechecking in Python, I don't think your point about people prefering JS and Python is that strong. There is one thing that's sure: people hate typing Car car = new Car(). var car = new Car()? That's already better. Python and JS got popular in reaction to Java/C#/C++, which were painful to use. Even Go now has type inference, which helps a lot. Now in 2022 it's not the same as 2005. You can have static types and a fast time to market. Before thinking about dynamic vs static, we should first try to see what the best dynamic and static typing schemes we can come up with.
> if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you
That's a bit of a strawman. If I'm prototyping a project, the last thing I want to care about is the weird API design that the author of that library I need came up with, instead of just implementing a common interface. Python and JS both have iterators for a reason. People in the functional world talk about monads all the time for a reason too: it's a general interface that allows you to write code fast. Nullable code is the same as async code, is the same as iteration (well, mapping) code, is the same as parsing code.
> Considering how much people love and use Rust, Typescript and typechecking in Python, I don't think your point about people prefering JS and Python is that strong.
I do think there's been a "type renaissance" in the past 5 or so years, after we all dove headfirst into JS and Python and broke the whole internet.
Yeah, I agree. I think part of it is due to embracing better type systems. For example TS and Go are structurally typed, which was a rarity before. Type inference is everywhere now. Sum types are usable in Java, TS, Rust. All of these languages are better than 2005 Java. Maybe we'll have a comeback of dynamic languages in the next 5-15 years, and if that's the case I'd love to see what people will come up with.
> > just from a common-sense POV, if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you.
Then don't. It's not like Haskell forces you to, that's a myth about Haskell. You can get away with strings and integers everywhere if you so fancy.
There is just no common-sense in thinking that computer assisted programming is slower than unassisted.
I just want you to realize that you are in the extreme minority here, but just from a common-sense POV, if I'm prototyping a project, looking for product-market fit, the last thing I want to care about is that my typeability is recursively enumerable or what-have-you. I just want to build something quickly without much hoopla (hence the massive popularity of very weakly-typed languages like JS and Python).
FWIW, I think that generics are a mistake in Go, but I was just trying to counter the point that language designers don't think long and hard about type-theoretic features. I think the main issue with generics, wasn't so much an inept "we don't know how to do this," but rather "is this worth the code complexity?" and "is this worth the added compile times?" -- both of which were main selling points of Go.