Hacker News new | ask | show | jobs
by nine_k 4112 days ago
The implementation language has a lot of implications.

* I'm extra wary installing anything written in e.g. PHP: it has a higher chance to be remotely crackable.

* I plan for more CPU and expect higher latency if something I need to run is written in e.g. Ruby.

* I plan for extra RAM and JVM tweaking for things written in Java (or Scala).

* I expect extra setup hassles for things written using Node.

Upsides are easy to see, too.

* I expect that it will be especially easy to read and alter code of something written in especially readable languages like Python, or Ruby, or Go.

* I expect that it will be dead easy to deploy something written in something that gives you a static binary, like Go or C or Haskell.

* I expect that things written in a compiled language like Java, or C, or C#, or Go, etc will run pretty fast.

* I expect that a program written in C has good chances to be optimized for low/efficient resource usage and thus could run well on a low-power device.

* I expect that something written in an elaborate statically-typed language like OCaml or Haskell is not prone to crashing with null-pointer exceptions or memory corruption.

1 comments

> e.g. PHP: it has a higher chance to be remotely crackable

No language war/php sucks discussion, but this isn't even remotely true :/

Or at least, we can see that Ruby can have stupid security holes too, for example[0].

[0] http://sakurity.com/blog/2015/03/15/authy_bypass.html ("How "../sms" could bypass Authy 2 Factor Authentication".)

PHP itself might be fine, but it is very widely used, and thus very thoroughly attacked. Unfortunately, a lot of sloppy code still historically exists in PHP. PHP itself is not inherently unsafe, of course.

By the same token, if I deploy a network-facing app that invokes a lot of C code (as opposed to e.g. bytecode), I must be aware of a higher probability of stack smashing, buffer overruns, etc, and plan a deployment accordingly.