Hacker News Reader

Comment by technomancy | Hacker News Reader

Maybe it isn't fair, but every time I see "...written in X" tacked on the end of the tag line, I assume it's a very immature product. If the implementation language is that high on the list of things potential users might be interested in, it's usually a sign that they've got a ways to go.

View on HN

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.

> 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.

I had the same reaction. I associate it with weekend projects people post on HN -- "Minecraft written in Elm" or the like.

The claims about it being automatically cross-platform because of Go were also pretty dubious. Most languages are cross-platform until you write code that isn't (or use a dependency that isn't).

More like "So far, it's cross platform on all the platforms I have compiled it on".

Go compiles easily to platform-specific binaries, unlike some other languages which either require a lot of provisioning or middleware to run cross-platform.

Saying that the project is "automatically cross-platform" is just shorthand for saying "no additional configuration is needed to run on platforms supported by the Go compiler"

I wrote up an essay of the three key things that every Git server should have, features that if are missing cause users to decided to look around for alternatives. And you are right, "Written in X" is not on that list.

http://benjamin-meyer.blogspot.com/2014/10/so-you-want-to-bu...

I can't believe you convinced me to click on that link. Could you introduce more paragraphs and/or bullet points and then get back to me?

It has more paragraphs than meets the eye, but for some reason the middle chunk of the article stops double-spacing and starts doing (very small!) indents for paragraphs instead. Some sort of formatting issue.

Some really nasty markup. Whatever CMS that's generated by, it's using BRs to simulate paragraphs and isn't doing a very good job of it.

Its Google's Blogger

As a potential user I find the information on the technology used to be pretty helpful, actually. It sets up my hopes for an app that is lighter on the resources than the Ruby on Rails based GitLab, with maybe easier installation process as well.

Install of gitlab is pretty easy with the Omnibus install method and manual install is certainly doable. It runs ok here with 1G RAM on an Atom processor.

Everything's doable, but that is not the point. I once had a client - a one person shop kind of deal - who asked me to install a ticketing software on the same account they hosted their website from. They liked Redmine, another RoR app, so I set it up for them and suddenly everything went down, because the CPU and memory usage went above of what their plan offered. They decided it's not beneficial for them to pay for a better plan, so instead we went with a PHP based solution. So yeah, in some cases technology can be as much - if not more - important, as the list of provided features.

Reply on news.ycombinator.com