[J_McQuade]

Having used Scala and TypeScript a lot for work over the last ~5 years, I think I'm going to say static typing. It's lunacy. Computers mostly don't work in types, my brain usually doesn't work in types, and only a small subset of the problems I work on really work in types.

The amount of modern languages that think they can solve everything in the type system boggles my mind.

[giraffe_lady]

I've come to believe through experience that hindley milner and its derivatives are the sweet spot. I shouldn't have to tell the compiler the types, and I shouldn't be attempting to implement business solutions in the type system. It should just know what is already there and tell me it when it can't reconcile that with what I'm adding, because that indicates a problem with my reasoning. The constraints this places on the language semantics end up being neutral-to-positive as well.

[octopoc]

I was going to say the opposite—even my side projects almost immediately hit the point where I’m spending more time fixing bugs that the compiler would have found than I spend time wrestling with static types.

I’m building something in Python right now and the lack of static types is just painful.

That being said, Scala and typescript have really powerful (maybe too powerful?) type systems.

[wink]

It all depends what libraries you are using and if they are properly documented and thought through.

I half remember a recent problem in the AWS TypeScript CDK. I don't know what exactly the Type was, but it was like: You get a SomeFoo from (their) API1 and a BarFoo from (their) API2 - they are called nearly the same, they expose basically the same fields, and you are only interested in one of the fields but there are zero convenience functions and you somehow have to convert between these 2 interfaces for no discernable reason and all you want is a `new BarFoo(someFoo.value)` but value is private. That's when you lose all hope because it's functionally identical to just pass `{"value":someFoo.value}` :)

[const_cast]

I work in PHP, I would say about 90% of all bugs are type errors.

Even if they're not type errors, if I sit back and think about what the root cause is, it's the type system and dynamic typing.

Addressing an array at null? Type error! Referring to a key that doesn't exist? Believe it or not - not a logic error, that's a type error! If we uses objects or structs that's not possible, but arrays are basically structs with dynamic member ;(

Anything around empty()? Type error. Arithmetic errors? Almost always type errors! Using postfix logic operators? Believe it or not, type error! Anything around DateTime? Usually a type error!

[rorylaitila]

Yeah I agree with this. My mind is type-oriented, but they are not a panacea. The biggest issue arises when the existing type is too wide/narrow or askew of the requirements. It can be difficult to morph the program into the new necessary types while maintaining backwards compatibility and not confusing the codebase. For this reason, I like gradual typing the most. Start with wide permissive types, narrow where I can.

I feel the allure of over typing most in typescript, because it is so flexible to make really complicated types. I see the mistakes most often when JS libraries move from JS to TS. They go overboard with the typing. The code becomes gibberish.

[mejutoco]

Not trying to convince you, although I disagree completely. I only want to share how I think about it in case it resonates. I am over simplifying but bear with me.

It is impossible how to know if a program will halt without running it, in general terms (Halting problem).

One way to think about the type system is as a less expressive language that is guaranteed to halt. So, it has the pro that we can check properties of the system without running it (IMHO, that is amazing), but it also has the con that it is less expressive (I know, or think I know sometimes, some property holds but you need to express it using the the system) which can be frustrating.

[sn9]

What problems do you work on?