Hacker News Reader

> then we should use strongly typed languages that prevent these bugs

So Typescript then? The most common recurring bugs on my team is front-end devs not knowing the shape or property names of types written by other devs (backend, other font-end, themselves a month ago). If we moved to Typescript they would get those little spellcheck-like underlines pointing out these errors before they attempt to commit, rather than customer's pointing it out.

Sounds like an argument against untrusted input, I just want Typescript so at least my own team becomes trusted input.

> Type checking bugs are most definitely not the most common ones

This is not a facetious question, so bear with me: what is a "type checking bug"?

Do you mean "a bug in language L that would have been caught by the typechecker T, if only L had it"?

That's the only meaning I can think of that makes sense [1] (ok, thought of another one [2]). But what does it mean that "most bugs" aren't of that kind? Is it that "most bugs are of a kind that cannot be caught by any conceivable typechecker"?

--

[1] We can safely disregard the other possible interpretation of "a type checking bug is a bug in the typechecker itself" ;)

[2] Maybe "this expected a list but I passed it an integer instead"? I do occasionally trip over those with Python, but I think most typecheckers are more advanced than that, and can check for more interesting classes of bugs.

Forgive me if I didn't use the right terminology too. What I mean by type checking bugs are the kinds of bugs shown in the article: I have an argument that should be a number but someone accidentally uses it with a string instead.

That's the most basic bug that typed languages catch. But for me, those are extremely simplistic. I don't need a type checker to know that. If you follow the code path you already know the types you're dealing with.

What strongly typed languages can provide are types with constraints. E.g. an age is not only a number, but a valid number greater than zero (maybe with an upper bound?) that is attached to a person. That kind of strong guarantee will definitely catch runtime bugs if you pass in some other numeric value that is not a representation of an age.

Languages like TypeScript can't do that. Take the example below. It compiles as if there's nothing wrong:

  type Age = number

  type Person = {
    age: Age
  }

  const person = { age: 10 } as Person
  const someRandomNumber = 10

  function printAge(age: Age) {
    return console.log(age)
  }

  printAge(person.age)
  printAge(someRandomNumber)

This is the kind of bug that a good type system would be extremely helpful with. In my entire career it's definitely a lot more common than passing a string by mistake. This can be extended for having a type that differentiates an `Email` from a `ValidEmail`, an `ActiveUser` from an `User` and so on. Those are, in my view, where a type system can truly help us catch bugs. But even if you have a type system that supports that, nothing stops someone from simply using `number` instead of `Age`.

In any case, that's why I don't think it's as clear cut as people put it. Yes, in very rare occasions TS will tell me I accidentally allowed something that can be undefined pass (excluding the many times it gets it wrong). However that doesn't come for free and that is what makes absolutist claims for either side unhelpful.

TypeScript is intentionally _structurally_ typed (except for enums). The example you describe would only be caught by a _nominally_ typed language (think Java).

Structural typing is great when programming functionally (i.e. with immutability) when the most important thing is the shape of inputs and outputs of functions, instead of named objects (like Person) and properties. In a functional program, for example, "printAge" would likely be called something like "print" or "printNumber" since that is what it is doing to its input _value_.

I think a lot of the misunderstanding I've seen recently around TypeScript (like from the Rails creator) comes from the misuse of TypeScript - if you use TypeScript in an object-oriented way, its going to be significantly less helpful.

>if you use TypeScript in an object-oriented way

I don't follow this one. I've never seen anyone use TypeScript with an OO approach aside from, ironically, the .NET folks.

The code I wrote has nothing OO with it and we can already see the issues. The majority of TS I've ever worked with was written for React and it still would benefit greatly from nominal types as you call them (thanks I didn't know that terminology).

I don't see everyone misusing TS. For me, it's simply a very limited language as far as typed languages go. As a result, it's a shame that it's what is being touted as a good example of why you should use typed languages.

First, Angular uses classes, and React supports class-based components.

Then, if you have converted lots of Javascript into Typescript, you have probably found several type-related bugs.

On one hand, this makes you (me) trust Typescript more, and feel safer knowing that your types are correct.

Later, you discover that a few of the declared types are wrong! You also still get "this" wrong in callbacks.

You could say that Typescript lets you try to get your types right, but you have to do the heavy lifting yourself.

That hasn’t been my experience. ReScript and Elm are much better compared to the fragile types I’ve encountered with Typescript (where I needed to write code to do the type checking). Happy if you’ve found something that works for you though.

For such problems we use the Opaque type from the nifty type-fest package. We use it for all of our id types (which are usually numbers) so we can't accidentally mix them.

In your example it would be:

    type Age = Opaque<number, "Age">

And then you wouldn't be able to pass a random number to printAge

> Again, that's not what research shows. Type checking bugs are most definitely not the most common ones and typing doesn't really help with runtime bugs unless it's a strongly typed language.

Can you point to that research?

This was the last one I read: http://danluu.com/empirical-pl/

If there's more, I hope people reply here with it!

Discussed a bit in past threads:

The evidence behind strong claims about static vs. dynamic languages - https://news.ycombinator.com/item?id=16287083 - Feb 2018 (1 comment)

The empirical evidence that types affect productivity and correctness - https://news.ycombinator.com/item?id=8594769 - Nov 2014 (25 comments)

As per your link is, it is not so much that "The research out there found no meaningful difference between both styles", but more than the research out there is utter garbage.

Which is what I would expect: a proper research on the topic would be terribly expensive, requiring multiple teams reimplementing complex projects in different languages and separate distinct expert panels evaluating development and results.

Yeah, which is a shame. Because I truly wanted to be confident that the costs of these don't outweigh the benefits.

Regardless if it's no meaningful difference or no good research, the point remains: we simply don't know, so these discussions are about opinions for either side, not facts.

No, the point does not remain that “research” “shows” anything. Seems there is agreement that ‘meaningful experiments have never been done because it is too complex and expensive’ so there is no significant research data.

But the basic argument is that a programming approach — having a compiler and a type system is not a “style” btw — that employs development time tools to reduce the burden of runtime operational tools, afford greater application of a wider set of optimization techniques at runtime, and also add to the information bandwidth of source code via type annotations is reasonably expected to be more rigorous than the other approach.

Fair point. If there was good research showing no difference, it would be equally pointless to argue either side is right, but it wouldn't be mere opinions, like they are today.

As for the move between runtime to development time tools, it still misses the cost of it.

We could move all our code to Haskell and have absolute guarantees for a lot of the common found bugs, but we don't because it's costly. And I don't mean rewrite cost, I mean the cost of its own complexities.

Nobody argues that typed languages aren't more rigorous, but that's not the only variable we care about.

Rigor is not the only variable, agreed. The issue (again) is that the other variables are many and they are non-linear in the main. (For example, the variable of ‘competence of development organization’ is not smoothly distributed. Our field is not a “smooth” domain it is ‘chunky’.)

So where does that leave us? Opinions are one option - comparative views to other ‘industrial’ age type of activities may be informative.

I propose to you that “we moderns” live in a typed world. It is not strongly typed but it is typed. One could argue that that is a side-effect of physical world artifacts produced at scale. I would be interested in hearing the argument as to why that near universal phenomena* does not apply to software, in your opinion.

(* Industrial production at scale and emergence of standards)

Maybe my point got lost within the threads but I never said types aren't useful or that we should reject them at all. After all, what you said is true. Whether we want it or not, everything is "typed" in one way or another.

My issue is a practical one. Using limited typed languages like TS has several drawbacks for little benefit. Using a strongly typed language like Haskell would add a ton of greatly needed rigor and correctness, but it's also not without huge drawbacks. Same goes for dynamic languages.

It's not a question of whether or not we should model our software based on our worldly types, it's about how strict we should be about it and the benefits and drawbacks that come within this spectrum. For that reason I argue there's no single general answer to this and claiming there is one is nonsense.

Yeah this is the unfortunate reality of software engineering methodology research. As a field we simply don't have strong and reliable research demonstrating what makes teams more productive or software more reliable. And we don't even seem to have new methodological ideas on the horizon to come save us.

There is this comparison of student projects in different languages https://thume.ca/2019/04/29/comparing-compilers-in-rust-hask...

> typing doesn't really help with runtime bugs unless it's a strongly typed language

I’m skeptical of this research. Typescript prevents runtime bugs for me day in day out. It also allows me to produce much more elegant and flexible solutions which would be infeasible in plain JavaScript. When people say there is no significant benefit compared to JavaScript it almost feels like I must be on a different planet or something. I would love to see what kind of code these people are working with, or how they’re attempting to leverage the type system.

Would you still favor Typescript if it was an actual static language: such that a type problem not caught by Typescript potentially corrupted memory and crashed the browser or Node.js instance?

> such that a type problem not caught by Typescript potentially corrupted memory

What does this have to do with static types? High-level languages, typed or untyped, are generally memory-safe. They'd need a very good excuse not to be. If Haskell isn't a "real" statically typed language, nothing is.

A True Scotsman's statically typed language is not safe if the type system is defeated; then it's up to the programmer to ensure safety.

TypeScript is not this; it's a type checking layer over a dynamic language.

> Again, that's not what research shows. Type checking bugs are most definitely not the most common ones

It's likely not the most common bug family to reach production or to be published on github so it will be visible to researchers doing their studies (survivorship bias…), but they are definitely the most common bug I'm facing when using an untyped language, and the majority of developers shares this sentiment.

Of course you'd argue that personal feeling isn't science, but studies falling to survivorship bias aren't good science either…

Not all of that research was done with public code. But they had other flaws.

I should have prefaced that with "IMO". That particular sentence comes from my experience/career, so YMMV.

When I'm reading code, I know what types I'm dealing with. Even more so if I'm creating that code. But then again, I worked with dynamic languages for a long time and this could be a skill I picked up because of it.

> When I'm reading code, I know what types I'm dealing with. Even more so if I'm creating that code.

Even when dealing with third-party code, or joining an existing project?

That's the first thing you do: read/learn the data structures you're working with. As Linus said once:

> Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Of course I still have to read and learn that. But that's the same with or without a typed language. Whether your data is an unstructured hash or a carefully typed structure, you need to know it.

Way too many people rely on ctrl+space based programming, figuring out everything as they go. One aspect that dynamic typed languages forces into us (at least it does to me), is to learn the data structure and relationships more thoroughly.

That's great unless you are working with a codebase that spans decades and tens of millions of lines of code. At that point if for every assignment you are tracing through your data types manually - you are out of a job.

Also, if I am using an API another team is providing - I don't want to have to go and trace through their code.

And that's assuming you even have access to said source code. In many cases, you just receive a semi-documented JSON object and a prayer.

Anecdotal story: We recently went through an effort to introduce strict-type checking for our typescript backend. As part of that effort, we introduced concrete types for every API accessible across a service boundary, which caught 6 mismatches between the documentation and the implementation (e.g. return Promise<bool> vs Promise<Instance>) and several hundred issues with missing null or type checks that would result in an "InternalServerError" instead of a meaningful error message.

We started rolling the strict version out this week, and we can already see a meaningful improvement in the sentry logs.

> Type checking bugs are most definitely not the most common ones and typing doesn't really help with runtime bugs unless it's a strongly typed language.

TypeScript actually performed quite well in the last academic study I read on this debate (like 6 years ago).

The real problem with web APIs is that there is always some lossy conversion between type systems as we cross boundaries. So we can't really make some sort of closed system assumption. A typical web app may interact with dozens of API services, some run by third parties. And maybe you can trust their API docs, but maybe not really, and they're subject to updates anyways, so you always have to be on your toes.

Even internally, you can't really control all the type info from end to end. Even the most monolithic systems will have some sort of abstraction leak when going from JSON -> Object -> Relational storage. Even largely monolithic systems will typically break off some functionality (like email sending, websockets handling, etc) as a separate service. The boundary creates a co-evolving connection between separate services run by separate teams, with separate upgrade cycles, even without full microservices buy in. And that creates potential runtime type errors when mapping between these layers.

Even if you've somehow plugged all those leaky abstractions and your tight type system has handled all the edge cases and is provably correct: the user will teach you otherwise on the UI layer. User input can vary wildly, and everything from device capabilities to personal disabilities to network throttling to authentication to using weird ISO characters to file sizes to strange input devices and legacy systems with their own quirks, will completely throw you off at some point.

So no matter how type safe your language is, you'll always have to deal with the untyped and unpredictable user layer. And the reason why JS has been so successful there is because of how flexible it is. It's not as painful to make quick tweaks with JS as it is with a type system like Rust's, for example.

JS, for all its quirks, made a good amount of trade-offs for its target platform.

Type errors are almost always the easiest types of errors to fix. What really will get you is debugging interdependent systems and services, and that pesky user layer. But people will spend extraordinary amounts of time maintaining complex type systems just so their OCD can be satisfied about believing, that at least for a moment, if their program compiles...that all is right with the world for that brief moment just before you deploy to production.

Oh were that the case. I do think types are essential for mission and life critical systems, but testing is even more essential for those cases, so everything should already be thoroughly covered. For consumer apps, however, is it worth the cost in velocity?