4 ms·
Dynamic languages with no compile time checking of fields, assertions, etc. seem inherently very dangerous to me for anything security critical or cryptographic
by api 7y ago
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.
- onlydeadheroes 7y agoIndeed 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.
- detaro 7y agoPlease don't attack arguments the parent comment didn't make.
- onlydeadheroes 7y agoOf course, because security issues and language pitfalls have no bearing on cryptographic implementations.
- detaro 7y ago"Dynamic languages have issues" does not say "all other languages are good".
- wayneftw 7y agoIn this context, where the commenter is replying to an article about a dynamic language and their comment recommends non-dynamic languages? Yeah it kinda does say something like that. Anyway, could you please not speak to people here as if you’re a moderator and leave moderation to the staff? Thanks a bunch!
- onlydeadheroes 7y agoHe 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.
- jsjohnst 7y agoOr 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.
- api 7y agoC'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.
- zzzcpan 7y ago> 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.
- icebraining 7y agoHow is that relevant to the article being discussed?
- StreamBright 7y agoHow would you implement security for the web then?
- zzzcpan 7y ago> 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 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.
- simiones 7y agoCan 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.