Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Implying that typing does not prevent bugs is the strangest programming meme I’ve ever heard, and its proponents push it so hard that I wonder if there’s somewhere I can sign up to be paid for it. We rarely are able to directly compare the cost/benefit of strict typings vs loose typings, but with JS vs TS you get a pretty direct comparison, and it is absolutely unsurprising that TS is eating the JS world; it does prevent bugs, it does improve productivity. Tests do too when done correctly, but both together are better than either individually.

When you go further, you can see that the core innovation of Rust is basically adding ownership to the type system and therefore making typing even stronger. Strong typing is a win for less bugs. Full stop.



I too do not understand how anyone can complain about typing if they have used a statically-typed language for any real projects.

Your TypeScript versus JavaScript comparison is about as good as you can get. Many people I've met who think duck typing is the preferred way to go do so because they learned to program on JavaScript. That is more familiar to them, TypeScript is an extra burden to getting work done, and therefore is bad.

I am working on a large project that uses TS (Angular) on the front-end and I can't possibly imagine doing that in plain JavaScript. The lost hours to simple, avoidable bugs would be too great.


Personally I interpreted the parent as pointing out that C does not offer strict typing.


Strict typing afaik isn't really a formally defined, imo.

As you know C is statically typed and generally said to be "weakly typed" as well but you can make a strong argument that just about any language is "strong" or "weak" -ly typed based on a dozen or so characteristics. I think it makes more sense to treat it as a spectrum where some languages are "stronger" than others. Which is different than in the case of "static typing" which you either have or don't.


Oh come on, I was taught the difference between strong and weak typing with C (weak) and Pascal (strong) as the examples 30 years ago. You can cast a C entity to something else and NO ONE ELSE KNOWS.

Then THINGS happen.

BAD things.


While Pascal is indeed strong typing and C is weak typing, casting is allowed on both at compile time and introducing bugs this way is not going to be stopped by compiler. Here is what a compile will behave in C vs Pascal:

C code:

int i = 1; char s = "1";

{

if (i == s) //<--- this will be allowed by compiler in C because C is weak typing, and will comeback later to bite you at runtime

{

//bla bla

}

}

Pascal code:

var

i : integer = 1;

s : string = '1';

begin

if i = s then begin //<--- this will not be allowed by compiler in Pascal because Pascal is strong typing

//bla bla

end;

end.


i think op meant that it’s strange to want strong typing and opt for C at the same time (because C is far less strongly typed than other more modern languages i suppose). Not that strong typing isn’t a good thing.


I implied that he chose C for strong typing, which is not. C is weak typing. You want strong typing, you go with Pascal instead for example, that's a strong typing language.


I'm sure typing prevents some bugs. But if I'm looking at the bugs we find in the JS projects I work on, only a very few would have been avoided with typing. The vast majority of bugs are about unsound business logic, wrongly understood requirements, etc.


That’s because the thousands of errors were manually fixed before committing.

I’ve programmed professionally in both Haskell (strongly statically typed) and Racket (dynamically typed). The number of bugs I encountered at runtime with Haskell was very close to 0 per 1000 lines of code. For Racket on the other hand, I would get maybe 5-15 per 1000 lines. Most of these were easy to catch and never made it into production, so it really only wasted my time instead of making the app unstable. But there would be a few very stupid bugs that would have been easily caught with static typing on the unhappy/rare path that wouldn’t be found until weeks or months later.

Nowadays, I try to avoid all jobs that use languages with dynamic typing on production software simply for the reason that they make me anxious and upset. Maybe everyone else is just so much better than me that they never produce typing relating bugs, but I kinda doubt it.


If you have a super duper type system you can use it to prevent lots of bugs in business logic, and you can use it to do a lot of work for you - as a solver. There are levels of value in typing - bug finding, but then also communicating what you are up to to other people using / reading the code (including you in < 6 weeks time!)


> TS is eating the JS world

Definitely another reason to stick to C. In C you don't have to change to another language or another framework, or yet another design principle, or whatever hype that is being followed by a horde of idiots that think they're incredibly smart.

C is still C. I love that so much. No endless discussions about type safety. And yes, with C I can shoot myself in the foot, which is great because I like sharp tools that can cut. Tell me of a cook who prefers a blunt knife. But at least, I'm the one doing it in contrast to web development where you use hundreds of amateur libraries that kill you in a snap, without you ever finding out what actually happened.


You're going to get buried for the odd knife metaphor :/

Even if we ran with it, like, would a cook use a knife with a sharp handle because it's "more sharp"??

I get what you mean though: C is pretty liberating. It gets out of your way and let's you be pretty precise about what you want it to do. In return you have to... well, be precise. If you have a bug it feels like you just need to get better. If a language makes too many promises and fails you, it feels like it let you down.

But I feel that way about Java vs. Scala, so what do I know.


The problem with C isn’t you shooting yourself in the foot. The problem is that off-by-one errors and buffer overruns that are trivially easy to produce in C turn into security bugs that affect your users.

If you don’t have any users, fine, but no one writing a nontrivial program for use by other people should be doing it in straight C at this point if it’s at all possible to avoid.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: