Hacker News new | past | comments | ask | show | jobs | submit login

Dynamic languages with no compile time checking of fields, assertions, etc. seem inherently very dangerous to me for anything security critical or cryptographic.

Sure you can write secure and correct code in them, but what happens years later when others (including yourself after you've forgotten what you wrote!) have come and made various edits, changes, refactors, etc.

This is generally where dynamic languages crash and burn, but it's particularly dangerous with stuff like authentication where a bug can be disastrous.




How is that relevant to the article being discussed?


> Dynamic languages with no compile time checking of fields, assertions, etc. seem inherently very dangerous to me for anything security critical or cryptographic.

You don't seem to realize, but runtime checking and assertions is an equivalent thing, it's literally an empty claim. But dynamism actually allows more in terms of security, because you can track a lot of things at runtime implicitly and bail if anything doesn't satisfy some property. For example: taint checking https://en.wikipedia.org/wiki/Taint_checking

> Sure you can write secure and correct code in them, but what happens years later when others (including yourself after you've forgotten what you wrote!) have come and made various edits, changes, refactors, etc.

That's what test coverage is for. But your claims are wrong and ignorant either way. We have empirical evidence that less code means less bugs and that more expressive dynamic languages means less code for the same functionality and therefore less bugs too.


Can you cite any reason for this belief? All comparisons of dynamic languages vs statically-typed languages have found 0 or extremely minor effects on correctness.


How would you implement security for the web then?


Indeed it is much better to implement it in a language such as C or C++ that has historically had almost no security issues and has very few pitfalls.


Please don't attack arguments the parent comment didn't make.


Or said another way (from the HN guidelines):

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.


Of course, because security issues and language pitfalls have no bearing on cryptographic implementations.


"Dynamic languages have issues" does not say "all other languages are good".


He is saying dynamic languages crash and burn in this context. Specifying "dynamic" does strongly suggest non-dynamic languages do not crash and burn in this context.


C's weak type system proves my point.

Safer code can be written in C++ IF you take advantage of its type system to implement safety features, but the language doesn't force you to do this so there is much insecure C++ code around.

Go, Rust, Java, C#, Haskell, etc. are examples of relatively safe languages with type systems that mostly keep the foot guns in the foot gun cabinet.


> with type systems that mostly keep the foot guns in the foot gun cabinet

They don't compared to dynamic languages. Those type systems are only an improvement compared to C and C++, not to dynamic languages.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

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

Search: