Hacker News Reader

Comment by lazyjones | Hacker News Reader

There's something fundamentally wrong with still using unsafe languages for system software.

C should have been buried decades ago, it's a toy language for small pieces of code on isolated systems (and yes, I've written larger programs in C myself, 20 years ago).

Nowdays, C should not even be considered safe for implementing interpreters and runtime systems for other languages. There are plenty of reasonably portable choices available (and no, don't use Java / anything JVM based).

It can't be terribly hard to reimplement "strings" and similar software in a modern language without such deficiencies (i.e. plenty of ways to shoot oneself in the foot and overwrite the stack etc.).

View on HN

The problem is, until now there has not been a very good systems programming language that allowed you to stay lean on memory without introducing any performance overhead. Rust is certainly a contender, thankfully.

So, there is a perfectly good reason C is still prevalent to this day, even if there are many security implications in doing so.

> The problem is, until now there has not been a very good systems programming language that allowed you to stay lean on memory without introducing any performance overhead. Rust is certainly a contender, thankfully.

We've only had Pascal and Modula-2 for what, 40-45 years?

>perfectly good reason C is still prevalent to this day

... it's not that and it's not good. It's just that security implications were largely ignored, people were lazy and innovation and making sound decisions (rather than popular ones) has never been strong in the OSS/Linux community (apart from the kernel itself).

http://www.lysator.liu.se/c/bwk-on-pascal.html

It's a hobby horse by this point, but it makes it clear that the Pascal of 30 years ago is not the Pascal of today. The same can be said of C.

These languages have evolved to be where they are today, mostly because hardware has evolved to be where it is today. Castigating past decisions as laziness really seems to be ignorant of this process, what it involved, and why it was necessary to make the decisions that we have up until now.

Engineering, on the whole, is the art of compromise.

Reading through some gstreamer code this weekend, I contend that "C of 30 years ago is not the C of today".

It is still all the most horribly insecure and obtuse passing of raw pointer manipulation and bitwise logic ever. The preprocessor is still hell on software. Every variable is named something like gst_hello_world_parser_box because when you write complex software in it you always get huge name conflicts.

It still thinks the best way to manage memory is to not manage it at all. People complained for so long about having to put your deletes in destructors in C++, too bad you have no such thing in C at all - you don't have classes, after all. Guess it has to go in the procedural function logic. Like 30 years ago.

> These languages have evolved to be where they are today, mostly because hardware has evolved to be where it is today.*

No. Pascal and Modula-2 were perfectly usable, safe systems programming capable languages 20 years ago. Pascal was widely used in commercial product development (DOS/Windows), Modula-2 was scarce, but taught at universities with high quality development environments available for many platforms and the Oberon OS was based on the language Oberon, which was heavily influenced by/derived from Modula-2.

Everything necessary to produce safe, maintainable, fast software was available back then, but lazy/uneducated/stubborn people used C instead and wrote crappy software we still have to use today. It's a shame really.

I'm sure Pascal was really the silver bullet and its failure had nothing to do with Pascal derivatives being academic, non-portable, not very expressive, and having numerous other issues.

I think your ad hominem comments about people who implemented in C are in poor taste and not based in reality.

I don't understand why we talk about Pascal at all, since Pascal is just as memory-unsafe as C.

No, because Pascal offers proper strings, bound checked arrays,open arrays, real enumerations, numeric ranges and reference parameters.

in one important practical aspect it isn't - strings are length+content in pascal, not null-delimited as in c. It's very important difference.

You read into buffers, not strings. You can easily have buffers overflows. Pascal arrays are bounds checked, but not when it matters: http://wiki.lazarus.freepascal.org/Secure_programming#Buffer....

The problems mentioned there (assigning to array elements with out-of-bounds indices) can be avoided by using range checks (-CR option for fpc). It's strange (and silly) that this is apparently off by default for fpc, but it's not a language feature of Pascal.

> April 2, 1981

USCD Pascal was created in 1978, Mesa in the mid-70s and Algol in 1968.

Most of the complaints don't apply to them.

> UCSD Pascal

bwk's point, then as now, was that once you deviated from Standard Pascal, you had to either bet on a specific horse in the non-standard Pascal race, or develop your own Pascal-like language with its own inherent defects, similar to but different from the defects of Standard Pascal and other Pascal-like languages. Your code would likely never interoperate with anyone else's Pascal variant.

C, which had one de facto standard implementation and less genetic drift (because the standards, first K&R and then ANSI and ISO, were never as terrible as Standard Pascal's definition), didn't suffer from this nearly as much.

Mesa didn't, either, but only because it was fairly obscure, and there sure were a lot of Foogols running around for a while, of which Pascal and its semi-clones formed only one family.

Nothing of this was relevant in 1981.

The first K&R was published in 1978, ANSI/ISO C in 1989.

In 1981 C only mattered if you had access to a UNIX system, there were hardly any K&R compliant compilers.

Anyone using C outside a UNIX system was also betting on a specific horse.

Which is one of reasons why ANSI C has so much undefined and unspecified behaviours defined, as the committee didn't want to rule out any implementation.

I wonder how big of a project would it be to port all of GNU/Linux to Rust.

Here's a start: https://news.ycombinator.com/item?id=7882211 https://github.com/uutils/coreutils/tree/master/src

I'd rather see it ported to Scheme.

And then see it fall into disrepair and disuse because it becomes unmaintainable.

LISP is 50 years old. If it was going to become useful for high performance software in large scale distributed teams of development, it would have happened already.

Wow, what an extraordinarily ignorant and obtuse remark. Way to go HN!

Please kindly explain where it falls down specifically. Very happy to be wrong should I be missing sometihng.

No no, you are mistaken. His reply is a special one. See, it not only refers to your reply, but it refers to itself as well! It's amazingly efficient, no need to respond to it any further!

I hope fundamental pieces of GNU/Linux system can start migrating to Rust without the FSF objecting to rutsc using LLVM.

I wonder if there'd be less friction to porting a BSD - FreeBSD already uses clang to build the kernel+userland, for instance.

You mean the myth that C was the first systems programming language, ignoring the fact that its designers just decided to ignore what was being done since the early 60's?

OK, how about this: C was the first portable, non-assembly language used for writing OS kernels. Is that true? And I mean portable in practice, not just in theory, and portable beyond one family of computers.

No. OS were already being written in BCPL, Algol, Algol W, Algol 68, PL/I, PL/M and many other languages, battling for a place in the podium of systems programming languages.

C was tied to UNIX, just as the others were tied to the OS of their vendor.

C only became portable after UNIX was available in a few American universities outside AT&T, some students decided to create workstations based on UNIX, while others started to develop C compilers, so that they could continue their work on other systems.

Didn't BCPL and Algol heavily influence C though? What features of BCPL or Algol or other, older languages that were ignored could have made C better?

BCPL not much. It was barely an high level assembler.

Now Algol, it had:

- Bounds checked arrays

- Reference parameters to functions/procedures

- Real strings (not the first version in 1960 though)

- Explicit conversions

Quote from Tony Hoare's ACM award article[1]:

"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."

[1]http://www.labouseur.com/projects/codeReckon/papers/The-Empe...

Multics was mostly written in PL/I. PL/I is certainly portable, though I don't think Multics itself was particularly portable.

BCPL was used to write several OS's that were ported, though while BCPL predates C, I'm not sure if any of the OS's written using it predates Unix.

I think you are overlooking OCaml & Haskell (which can both be used skillfully to approach performance of C).

Are there examples of either OCaml or Haskell being used for systems programming? I know that algorithmically they can achieve pretty close performance, but I don't think support is that great for low-level operations.

"Ivory" is a Haskell embedded domain specific language for writing safe C programs. One (very loose) way of thinking of it is that it compiles a restricted subset of Haskell to low level C.

http://ivorylang.org/

There is also 'Atom' which is an embedded DSL in Haskell for writing real-time embedded systems: http://en.wikipedia.org/wiki/Atom_(programming_language)

You might consider Mirage OS (http://www.openmirage.org/) to be systems programming.

It's hard to tell what you mean by "low-level operations." A lot of systems programming, particularly the GNU suite, just deals with manipulating files, sockets, and so on, and Haskell can do that just fine.

Example: http://www.haskell.org/haskellwiki/Simple_Unix_tools

Maybe you could have a look at "Unix system programming in OCaml"?

http://ocamlunix.forge.ocamlcore.org/

Haskell is great, but GHC's runtime system is 50000 lines of C.

Which is relatively inconsequential as long as there's a clear boundary between things that can be manipulated by a user and the C code.

It'd be better if it wasn't C at all, sure, but, from a security perspective I'd take a language with a C runtime over a language where code has to be carefully written in a memory-safe manner any day.

GCC is written in C/C++. I don't think any of the compilers are dogfooding their language because its supposed to be reusing infrastructure.

I'd hope an LLVM compiler for a language would eventually be dogfooded, though.

http://en.wikipedia.org/wiki/Bootstrapping_(compilers)

This is pretty much the first thing that everyone writes in their new programming language.

Whatever. One can always write unsafe code. No matter in what language. A really secure language is almost worthless because there's so much it can't do.

No, the problem comes from the other end. Strings should not be able to compromise a system. It only needs to read a user supplied file, and write to stdout. There's no reason for it to be allowed to exec a piece of code.

You seem to be arguing against yourself. If 'strings' were written in a safe language, compromising the system would be extremely unlikely. Or are you seriously arguing that languages that are safer than C aren't Turing complete?

There are plenty of memory-safe languages in which you can do nearly everything you'd do in C, and much, much safer. There's no reason whatsoever a program like 'strings' couldn't be written in a memory-safe language.

> If 'strings' were written in a safe language, compromising the system would be extremely unlikely.

Shellshock was a parsing bug, the memory safety of bash helped nothing.

Bugs are bugs. When you get an out of bounds exception that leaves your program in an inconsistent state somewhere halfway up the call stack in a code path with poor test coverage, "safe" is not the correct word.

The premise of this conversation is flawed: A language isn't "insecure" or "secure." It's placed at a certain point in a safety spectrum ranging from "Do anything with no safety" to "Safely heat the room and achieve nothing."

What I'm saying is not that you can't write software that can be abused in memory-safe languages. I'm saying that you're much less likely to have extremely serious code execution vulnerabilities if you write a program in Go instead of C.

> What I'm saying is not that you can't write software that can be abused in memory-safe languages. I'm saying that you're much less likely to have extremely serious code execution vulnerabilities if you write a program in Go instead of C.

What I'm saying is that "much" less likely is overstating the difference. Most bugs in C programs are not buffer overruns, and even the ones that are would still be bugs in Go or Rust, they would just be a different kind of bug which is still plausibly exploitable under real conditions.

This is not a silver bullet kind of situation. "Rewrite everything in Go" is not actually a fix -- it's replacing code with 30 years worth of bug reports and vulnerability testing with completely untested new code, at the cost of significant resources that could better be used to fix the remaining vulnerabilities.

I'm not even saying that all the existing code is perfect. Replacing OpenSSL with entirely new code would probably do more good than harm just because the existing code is so ugly. But that's the exception rather than the rule.

There are a ridiculous number of serious vulnerabilities in C code related to lack of bounds checking and manual memory management. This isn't really opinion so much as fact. I understand what you're saying, but you're also downplaying the seriousness of C bugs relative to <most other languages> bugs.

> Most bugs in C programs are not buffer overruns, and even the ones that are would still be bugs in Go or Rust, they would just be a different kind of bug which is still plausibly exploitable under real conditions.

I don't follow. What's the equivalent of forgetting to check the length of an input string before chugging it into a too-small array in Go?

> "Rewrite everything in Go" is not actually a fix

I never said that, though. I'm not suggesting we rewrite the GNU tools in Go. But if you were to write the GNU tools from scratch today, C would be a bad choice simply because it's so easy to slip up with devastating effects, and there aren't many advantages to using it for simple tools like 'strings'.

> There are a ridiculous number of serious vulnerabilities in C code related to lack of bounds checking and manual memory management. This isn't really opinion so much as fact. I understand what you're saying, but you're also downplaying the seriousness of C bugs relative to <most other languages> bugs.

I feel like "<most other languages> bugs" tend to get ignored because it's not popular to blame <language> for bugs unless <language> is C. For example an enormous number of high severity CVEs are SQL injection but I never hear anybody saying we should replace SQL with a binary interface that clearly distinguishes statements from data, even though that would make more difference in practice than replacing C with something else.

> I don't follow. What's the equivalent of forgetting to check the length of an input string before chugging it into a too-small array in Go?

In Go the program terminates, which is at best a denial of service vulnerability. If the program is anything in the nature of Fail2ban then just causing it to die is a serious problem. Meanwhile when it restarts it will have to somehow deal with whatever corrupted state the crash left behind, which depending on the context can provide the attacker with opportunities to do arbitrarily bad things by manipulating the state to be something the programmer never anticipated. Being able to induce a restart is a huge increase in attack surface.

Immediate program termination is the "take cyanide capsule" solution to serious bugs. It may be better than some of the alternatives but it's still very bad.

> For example an enormous number of high severity CVEs are SQL injection but I never hear anybody saying we should replace SQL with a binary interface that clearly distinguishes statements from data, even though that would make more difference in practice than replacing C with something else.

Using bind parameters instead of putting data directly in queries + escaping has been standard for a long time now. That is, instead of saying "make sure to escape everything", like "make sure to avoid any bugs in C code", we indeed prefer to switch to a technique which which doesn't act pathologically in the presence of small errors. In SQL's case it doesn't require replacing the whole language. It technically doesn't have to in C, either - you could have bounds checked C - but I guess once you give up the absolute-maximum-performance goal, people prefer to use different languages.

edit: Also, while program termination is not ideal, in many cases, such as this one (strings), it is basically a non-problem, and at worst, denial of service is still loads better than arbitrary code execution.

> I feel like "<most other languages> bugs" tend to get ignored because it's not popular to blame <language> for bugs unless <language> is C. For example an enormous number of high severity CVEs are SQL injection but I never hear anybody saying we should replace SQL with a binary interface that clearly distinguishes statements from data, even though that would make more difference in practice than replacing C with something else.

I don't even use SQL, but I've heard a similar mantra plenty enough times to internalize it.

"but one thing is clear: you should never, ever use concatenated SQL strings in your applications. Give me parameterized SQL, or give me death." ( http://blog.codinghorror.com/give-me-parameterized-sql-or-gi... )

This is an API level change, not a protocol level change - but an API change is the correct answer anyways. If you change the protocol and slap an API like the SQL injection prone ones on top of it, you'll have the same vulnerabilities no matter what the protocol.

For bonus points, use static analysis to catch and forbid query strings that can't be trivially proven static.

I see 3x more memory corruption CVEs alone, than SQLI CVEs. I'm not convinced that replacing SQL (or SQL APIs) would be higher impact than replacing C and C++. And since I actually use C and C++ in my daily bread and butter, they're significantly more relevant to me.

But SQLI may be significantly more relevant to you. If that's the case, by all means, focus on them more.

> If the program is anything in the nature of Fail2ban then just causing it to die is a serious problem

If that causes a serious problem, then the architecture is bad and unsuitable for solving that problem (remember: programs can also die because of OOM conditions, flakey hardware, admin errors. If this leaves a gaping security hole open for an attacker, or lead to DoS, then you need a better approach; fail2ban functionality should be in the process handling logins for example, not a separate entity watching logfiles, which might be broken too).

> Being able to induce a restart is a huge increase in attack surface.

Compared to what? Certainly not C code, where very common issues are easily exploitable for arbitrary code execution.

Program termination/exception is clearly preferable to arbitrary code execution.

Does Go force you to sanitize all user input?

Because I am sure if had ported bash to Go, you would still have the same issue with the broken parser. I am not sure if you would still have had heart bleed, but I know you wouldn't have had heart bleed if the openssl people had used the platform libc, instead of rolling their own, so I wouldn't consider heart bleed an issue with C, but an issue with the programmer.

Multiple factors are to blame. I agree this is dumb behavior here by strings, but if the ELF parsing code were to be written in a language like Rust, it's far less likely it would have a bug of this nature.

Rust... or pretty much any other language than C.

C is scary from a security perspective because it is both incredibly easy to write code that has subtle but very serious bugs leading to e.g. arbitrary code execution, and it is easy to exploit those vulnerabilities.

So what you're saying is that the bugs from a piece of software written 20 years ago (roughly) can be solved by writing the program in a language that hasn't had a stable release yet? Sure there are better alternatives now, but what widespread, well known, portable language was available in the mid 90's that this could have been written in?

Despite the volume of messages on this thread about securing C or replacing it with a safer language for systems implementation, I think your answer is the only practical one.

If you haven't seen it already, you might want to check out HiStar:

http://www.scs.stanford.edu/histar/

It's not 'allowed' to exec a piece of code. It parses code and the parser contains a bug that can be exploited to execute code.

Code that is unsafe in this way is impossible to write in most languages.

ATS is a definite contender too, especially once the high entry barrier issues are worked on a bit.

Counterpoint: All the rails security exploits, python pickling and sql injection issues.

It is common to blame C for being unsafe but the real issue seems to be trusting user input, without sanitising it first. You could use a typed language to enforce sanitising by having a special type for user input (whether read from a file or received from the system) and have the converters sanitise it.

Sure. I re-wrote strings a few years ago in C#, worked great. That was at Microsoft, and sadly the code can't be made public.

I've done most of my OS-level hacking in C and a limited subset of C++. I think it works well down there, where resources can't be "magic" and it's really important to know what's going on (and you often have to tell the optimizer "hands off").

At higher levels, it's lunacy to be using C. I sure wouldn't write a compiler in one, for instance.

> I re-wrote strings a few years ago in C#, worked great. That was at Microsoft, and sadly the code can't be made public.

You sure about that? If it was a re-implementation in non-cleanroom conditions, Microsoft likely don't have that right.

Even if that's not the case, I'm curious what commercial gain Microsoft believe they would have be keeping it private.

One wonders how much other code of public interest is hidden behind closed doors (and not just Microsoft's).

They have every right - even if they translated the source code to "strings" to C# line by line, they aren't distributing the result, and hence have no GPL obligations whatsoever. By the same token, if they did distribute it under something other than the GPL (which they would), and it were found to be a "derived work", they would be infringing copyright. However far-fetched, it's no surprise they play it safe.

It's very common for places to claim ownership of all code you write as an employee, both in and out of work. I don't know whether this would stand up in court, but nobody I've spoken to has tried to find out.

As for the provenance of the code, it's quite probable it was a clean-room reimplementation. Writing such tools isn't exactly rocket science. I wrote a PDB-oriented addr2line for VC++ a few years ago, and it didn't have any of the original addr2line code in it at all. In fact, I've never even looked at the addr2line code. I just ran addr2line --help and copied the command line options I saw there. I suspect a reimplementation of strings would be just as straightforward.

Yes, it was clean-room, along the lines of "I need a program to extract strings from binary files." I don't think I even looked at a man page for an existing implementation, so the options and functionality are almost certainly different from other implementations of strings.

This was driven by Microsoft's hostile policies towards running anything open source inside the company (you have to get special dispensation to install Linux, for instance). Actually looking at outside source code is a big no-no.

There has been at least one case of a contractor including GPL3 code in a project, and MS responded by (a) letting the contractor go, and (b) releasing the source for the product in question. [And no, it wasn't Windows]

Pretty much anything written inside a company is born secret. There are exceptions to this, but shipping "free" code (especially from a bureaucracy that is ultimately controlled by people who want to make money, and that includes not giving competitors any advantage at all) is a big political deal.

Compile times are important though and using low level language such as C can make a big difference.

I'll happily lose 5% compile performance in exchange for a safe compiler. Unfortunately, writing a compiler in a safe language isn't enough to make it a safe compiler.

Are you claiming that C is fast to compile? If compile speed mattered that much we'd all still be using Turbo Pascal/Borland Delphi, or perhaps more recently Go.

No, what I meant is that a compiler written in C is likely to be faster than a compler written in other language, which is a good reason to write a compiler in C.

Nah. What you usually want from a compiler is maintainability and correctness. There's also a grand tradition for dogfooding by writing the compiler for language X in language X. If you don't, then how do you know you're actually making progress?

Out of curiosity, what's the problem JVM-based languages as a safe choice? (I'm legitimately curious here.)

It's certainly not the right solution for everything, but there are plenty of cases where I'd think it could be an excellent choice. Most of Android (except the kernel) is written in Java, as an example.

The most popular implementation of the JVM itself is written in C++. But more importantly, Java has experienced a multitude of serious security bugs over the years.

I'm not a huge JVM fan, but the majority of the Java vulnerabilities are related to a very different threat model that many languages don't even purport to guard against: safely running code that you know may be directly written by an adversary. The Java SecurityManager is supposed to allow that by sandboxing code with limited permissions, but has had a number of bugs, some of which can be exploited to let malicious apps break out of the sandbox. That's bad for cases where you are actually relying on running potentially malicious code, like applets in browsers. But not too relevant to the case where you'd be considering whether to choose Java, C, or C++ for a desktop or server app. In that case, treating the app itself as potentially malicious is not a common threat model: people don't normally run C/C++ apps in a sandbox. Although I suppose with the rise of Docker that might start becoming plausible for certain apps, relying on some OS facilities rather than a VM to do the sandboxing.

There's already been multiple security vulnerabilities in Docker, and likely there will continue to be more in the future. Virtualization and sanboxing is hard!

>The most popular implementation of the JVM itself is written in C++.

The amount of C++code decreases with each release.

For example, the version 8 of the OpenJDK had quite a few code rewritten in Java, thanks to the work introduced with invokedynamic.

There are plans to eventually replace Hotspot with Graal and SubstrateVM, in some future version of the OpenJDK, thus reducing even more the C++ surface.

This is why project Sumatra is using Graal and now jRuby is also playing with it.

The vast majority of which where actually in parts of the C++/C code used to implement the most popular implementation of the JVM. Which is in C++ for historical reasons not because C++ is needed to implement a JVM.

And as other commenters note the amount of C++ decreases each release because its less and less useful to have any code in the JVM as C++.

In graal calls to the OS are going to more limited in surface area than in Hotspot C2.

For all reasons removing a class of errors e.g. buffer overflow leading to executable code is going to give more secure code.

Not that I think Java is a silver bullet that will solve all problems. I do think that a language like Java or Rust is a major improvement over C with minimal performance issues.

Garbage collection is an issue breaker for some systems software, you can't use the "fork and start a new process model" for utilities, and memory usage for small systems is going to be an issue too.

The problem is that "safer" languages just encourages programmers that don't really think carefully about what they're doing because of the "the language is safe, it'll protect me from everything" effect. "Simple" bugs get hidden, programmers are encouraged to create more complex systems as a result, and the bugs thus created become even more subtle and difficult to find.

Is it really so bloody hard to ensure that e.g. the fields of the executable header, if they're offsets, are actually valid values? I've written tools that work with PEs, many of them reading the entire file into a buffer first, and "make sure you're inside the file" was one of the points I always kept in mind.

I say we need to fix how programmers think, not the language, because the same mindset that leads to bugs like these in "unsafe" languages will also lead to (maybe less severe, maybe more severe but also more subtle) bugs in "safe" languages too.

> The problem is that "safer" languages just encourages programmers that don't really think carefully about what they're doing because of the "the language is safe, it'll protect me from everything" effect. "Simple" bugs get hidden, programmers are encouraged to create more complex systems as a result, and the bugs thus created become even more subtle and difficult to find.

Citation needed. The plethora of over overcomplicated C code is a strong argument against this claim.

The plethora of over overcomplicated C code is a strong argument against this claim.

There certainly is plenty of overly complicated C code, but I doubt there is more of it than there is the amount of overly complicated code written in some of the other popular "safe" languages: Java and JavaScript.

These unsubstantiated claims are pointless.

> I say we need to fix how programmers think, not the language

I agree, but unfortunately, changing the language or replacing it, is a lot easier than changing the way programmers think.

People create more complex systems because they no longer have to think about tedious bugs that will be caught by their compiler?

> (and no, don't use Java / anything JVM based).

Why not? There are meta-circular implementations of Java, with native code generation on their toolchains.

Even OpenJDK is going to get a AOT compiler as discussed on JVM Language Summit 2014.

What are your arguments against Java?

If you are disregarding Java when you are looking for portable options, then you are IMHO limiting yourself quite a bit and could be missing out on a good solution to your problem.

For software like "strings"? Startup times and memory footprint/performance due to JIT compilation / the JVM, as well as the notorious complexity and bugginess of the runtime. Just consider the frequent updates and incompatibilities you'd get with it - for example, we had plenty of Java-based remote management GUIs which wouldn't run on newer Java runtime versions. Maybe with the (limiting) static compilation options available for Java it'd make more sense.

Reply on news.ycombinator.com