I hate feeling limited by a programming language. I want the language to adapt to how I conceptualize the problem, instead of being forced to adapt to how the language can conceptualize the problem. and statically typed languages feel really limiting to me. like you can only do the things that you can explain to the type system, and I feel like the type system is either:

• kinda dumb and very limited on purpose (C#, C)
• so complex that you basically have to learn a whole new branch of advanced math to understand how to use it properly (Rust, Haskell)

although on the other hand, I wonder if folks who are used to statically typed languages find dynamically typed languages to be scary because they let you get away with so much bullshit lol

@kasdeya You either get lots of defensive code to guard against unwanted type coercion in dynamic typed languages or complex casting to make the compiler do what want it to do with your data in static typed languages.

@kasdeya my general feeling is that if I can’t explain what I’m doing to Rust/Swift/Haskell, then I probably haven’t understood it well enough myself.

I don’t find dynamic languages scary, I find they fall apart when the code gets too big for me to understand the whole, when more than just me is working in the code, or when I want to do a refactoring. Without static types it’s far too easy for an edge case to sit there broken indefinitely.

@kasdeya I say this as someone who loves Ruby; I’ll still choose Ruby for small projects due to that “low barrier to expression”. I’m just much more cautious than I used to be about the limitations that that creates with respect to scale.

I do wonder about things like Crystal, though. Is that “just enough” types to help it scale, without creating undue burdens on small code?

@kasdeya i can actually verify your last point. i got so used to statically typed languages that whenever i use a dynamically typed language i get scared by not knowing what anything is

@kasdeya Anyway, Rust’s improved a lot over the years, and better improved borrow checking and improved tooling (live feedback from rust-analyzer is invaluable for quickly finding out about things the compiler is gonna hate) I mostly don’t find myself fighting rustc any more. I could happily do most of the stuff I use Ruby for in Rust, without feeling constrained by the language. I do find that it makes me think a bit too hard about performance concerns though.

@hearts omgg that is exactly how I feel in a statically typed language lol. I get so disoriented and lost so quickly - it almost feels like I have to learn how to write code all over again, from scratch

@OneSadCookie I really like using type annotations when I write code in a dynamically typed language, and then using a typechecker/LSP to make sure that I’m not making any type errors. and I honestly feel a little naked without that kind of type-checking at this point

but, maybe 1% of the time I’ll be writing a function/method and have no idea how to express it in terms of a type annotation. and I’ll have to do something almost like algebra in my head trying to figure out what the annotation would be. it’s not that I don’t understand what types the code will use but just that I don’t know how to express it if that makes sense. that happens a lot when I need to use type parameters

also, sometimes I’ll be writing a very simple function and just immediately know that giving it a type annotation is going to be impossible or very close to impossible lol. for example I wrote a partial() function in TypeScript and gave up pretty quickly on giving it a type annotation

so I really like having the escape hatch of just not including a type parameter, or using Any in places that I don’t know how to express

I wonder if Rust could handle a partial() function at all, and if so how you would explain that to the type system. Rust seems able to handle just about anything that you throw at it but I feel like you might need to use some deep magic for that to work. I bet Haskell’s version would be very simple though

@hearts @kasdeya it usually puts a type hint at declaration (unless it's a temp variable that is used only once within the next 5 lines)
usually IDEs can infer from the hint

@kasdeya i’ve actually seen both sides of this. i used to only use dynamically typed languages, and felt the same way. then i forced myself to learn java at one point and then just haven’t been able to switch back since. honestly i think it’s just a matter of what feels more familiar

@kasdeya This is one of my main reasons most of my work is in TypeScript these days — it's got a really solid type system, and when I absolutely have to do something I can't express in the type system, it's pretty easy to suppress.

I worked in Java for about a decade and spent so much time fighting against the type system. I wanted to do things like "I want a class in this shape, not an instance of the class", or better intersection types without acrobatics, or generics over unboxed scalars, etc.

I've been doing TS for almost as long now, and there's much less fighting. I'll occasionally run into some gnarly stuff — like I'd love to be able to do type exclusions without ternary conditionals — but rarely.

I also just can't get down with the nominal typing of Java. Now that I'm used to structural typing of TS, I don't think I could ever go back.

I can't handle the untyped madness that is Python. I feel like it strips away my sanity on the rare occasions I have to use it. "wtf is that parameter even?"

@kasdeya I mean, Rust and Swift both have this built-in, in a sense — eg. in Swift `{ (s: String) in Int(s, radix: 2) }` is exactly what you want. The signature is only necessary because that parameter to https://developer.apple.com/documentation/swift/int/init(_:radix:) is generic. Or in Rust, `|s| { i64::from_str_radix(s, 2) }`, no generics to worry about.

Though I agree that if you wanted to do this *without* relying on the compiler's type inference for closures, you'd be in for a really rough time.

@kasdeya "I want the language to adapt to how I conceptualize the problem, instead of being forced to adapt to how the language can conceptualize the problem."

this is extremely literally why i am a grad student in PLs right now. i agree extremely hard with this.

(now, we diverge pretty quickly on our personal preferences, but we're coming at it from the same place!!)

@0x7700e6 @kasdeya i fear type hints because they were wrong like twice and now i just permanently live in paranoia of the ide lying to me

@hearts @kasdeya unfortunately. linters like pylint detect this

@kasdeya maybe its inexperience but i feel like i can learn from typed languages, most of my experience with python has been defensive bullshit where it doesnt have type hints and looking through shit to figure out what type its supposed to have otherwise and i feel like i lose so much time to that it makes me bwe

@kasdeya as someone who cut their teeth learning C++ and Java, working with JS's sheet disregard for types entirely taught me to be a more defensive programmer.

Then I found Typescript, and all the pre-compilation type definitions combined with the flexibility of runtime dynamism and non-typal restrictions brought me back into this world of being able to know what the code will end up being able to access and manipulate, while also being able to know that the code I write will be able to handle much more due to how generic the typing/structure handling is done.

Ngl, I don't care much for strictly typed languages anymore, I used to question why anyone would want JS on the server. I get it now.