Here's why dynamic languages are slow and how to fix it

npcontemplation.blogspot.com

4 points·ynd··3 comments

This is true, but there are a couple of points missing: firstly, many real-world programs are bound by factors other than the CPU, i.e. waiting for I/O or network events. In this case, benchmark speed differences between static and dynamic (or compiled and interpreted) are irrelevant. Secondly, the point of static typing is not merely for performance, but (hopefully) to catch some errors at compile time.

> Secondly, the point of static typing is not merely for performance, but (hopefully) to catch some errors at compile time.

The relevant question isn't so much when they're caught but how much it costs to fix them.

Has anyone seriously looked at whether or not the relevant hope is justified? I'm pretty sure that it isn't in any useful sense. Yes, static typing does trigger compiler errors, blocking further development until they're fixed, but those sorts of errors get caught when they're relevant in dynamic languages. When they're relevant right away, it's unclear that compile-time is cheaper. When they're relevant later, "blocking further development until" looks like a bad thing.

My expensive bugs are not caught by static type systems.

nice. I had never questioned the value of catching the errors early.

thanks

Reply on news.ycombinator.com