[replwoacause]

I've used untyped languages extensively, and even built my own, and the errors I get at runtime are almost never type-based, and that's even more true now that LLMs can pump out code. For all the additional ceremony types add, I can't say I've personally realized their benefit.

[rspeele]

> the errors I get at runtime are almost never type-based

That surprises me, but everyone's experiences are different. I've been in the statically typed language space for so long and enjoyed it so much, I find it pretty irritating to go back to Python (my long-ago favorite) but many people are in the exact opposite frame of mind. I'm curious: what kinds of errors do you classify as a type-based error? I think that varies from person to person.

For example, null references. A C programmer would say dereferencing a null is not a type-based error, because it's not feasible to encode non-nullable pointers in the C type system. A Haskell programmer would say it is a type-based error because Haskell makes it difficult not to encode this in the type system, you really have to go out of your way to create a runtime null dereference error.

A C# or TypeScript programmer could answer differently depending on who you ask, because both of those languages make it possible to leverage the typechecker to prevent null-deref at compile time, but neither one makes it required (you can turn those checks off or make them warnings if you like), so it depends on the programmer's build settings and how much typechecking they personally have chosen to use.

[Paracompact]

> I find it pretty irritating to go back to Python (my long-ago favorite) but many people are in the exact opposite frame of mind.

As someone who works exclusively in typed languages for formal methods, what is it you find lacking about modern Python + PyLance? IMO there's still a tiny verbosity issue, and there's no real replacement for fancier polymorphism or (G)ADTs, but I'm very satisfied with it for most things. In particular, null checks are trivial.

[rspeele]

It has been about 10 years since Python was a daily driver for me and at that time I wrote it the old fashioned way with no type hints and no static checking, just like grandma used to make. The times I have needed to dig back into it have involved working on old code, so I haven't kept up with modern tooling.

However, in principle any dynamically typed language can be tolerable to me if it can be turned into a statically typed language ;)

But I think I'd still prefer the ergonomics of a language designed that way from the start vs having bolt-ons. My favorite language for the past several years has been F# and I think ML-family languages in general strike a great balance of being able to write terse code when you want to, and being able to model a domain really well with types when you want to.

[kensai]

This reminds me of the analogy of the smoking grandpa. I had a grandpa that was chainsmoking his whole life and managed to reach 90 and died of other causes. This does not mean smoking is "relatively safe".

[waffletower]

This analogy is absolutely absurd and inappropriate on multiple levels. It reflects a parochial mindset that can't fathom contexts where dynamic type systems can be advantageous, such as a breadth of data processing applications. My favorite irony is how dynamic languages excel at concise translation between opposing type systems -- a very common data processing scenario.

[kensai]

You expand my comment to uses I had not envisioned. It was simply an analogy to correct the analogy of the OP comment.

[abustamam]

I've been working with typescript for the past ten or so years.

A couple of years ago I did some contract work for a client who used Javascript.

I did some basic smoke testing to understand the state of the app and I was able to get lots of fun type errors on the server and client at runtime just by QAing the damn thing.

[aeonfox]

I've definitely found LLM code to be syntactically/semantically correct in one-shot pretty much all the time. It's usually the functional specification/behaviour that's found wanting.

Typing probably makes sense where memory-correctness needs to be enforced (e.g. Rust), and inferring those semantics require a much wider context. But memory-correctness isn't really something that afflicts BEAM languages.

[citizenpaul]

I thought a big part of the reason for type systems was a sort of self documentation/contract? Especially if you need to work on an unfamiliar system with bad documentation. Also what about system boundaries? I prefer typed languages personally.

[galaxyLogic]

The benefit is not only about "documenting the contracts" but documenting the contracts in a way that we can trust those contracts can not be violated when the program is running.

That is a very good thing to help us reason about the program, we have invariants we know must hold true if the program does not stop in a type-error.

[dnautics]

when i was programming elixir by hand i was making typing errors about 1 every half year or so. none took production down, most were caught and corrected quickly from logs. now im doing mostly llm elixir, almost all typing errors are caught in integration tests and only one has made it to prod.