Comment by arihant | Hacker News Reader

Comment by arihant | Hacker News Reader

Parent Full thread

These aren't problems of the language. These are a result of having a design choice of full programmer control.

Having automatic cars is convenient and has its uses. But the argument that not using a manual cars will cause less road accidents is misinformed. It looks like that because common sense dictates that as it's easier to drive, more people will drive it easier. But usually the result is that now you have people on road who could not drive a stick!

Some things are meant to be written in lowest level possible. Programming languages are tools and it helps us to have tools for entire spectrum of abstractions. Electronic screwdrivers haven't replaced manual ones in 2 decades. That's not how tools work.

As far as direct comparisons go, these isn't any indication that raising the level of abstraction actually helps with more secure, bug-free code. Compare Java code written (in FOSS setting) with C code written in last 15 years. I bet you'd find C code more secure, more fast, more faster to refactor than a lot of Java code. So if Java was a systems language, would the world be better off if it replaced C? Probably no. Which shows that it's our infatuation with new shiny toys (languages like Go) that's driving our opinion rather than evidence.

C is like running around with scissors in your hand because it allows you to cut paper faster when needed.

Yes, its true but it is also likely to cost your eyes.

Java FOSS code is often faster, more secure, and a lot easier to reason about than equivalent C code. This is not really a language thing but a standard library thing.

The use of char array with a null termination for human readable strings is a terrible 'C' ism. And glibc standard String struct would have saved us all a lot of (security) issues.

The second is a community thing. Java uses defined behaviour to drive optimisation. C tends to use undefined behaviour to drinve optimisatio. The C case really trips programmers up.

Most of these things are not actual technical but more social issues. Computers don't care, it is us humans who do.

> Java FOSS code is often faster, more secure

But uses significantly more memory and requires a VM.

The VM probably is written in C, too.

There are AOT compilers for Java, some of them actually written in Java.

The reference JVM uses a mix of Java and C++, with code being migrated from C++ to Java and replaced with intrisics in each release.

Java 9 will bring Graal/Truffle plugins, which are a JIT compiler framework, written in Java.

> But uses significantly more memory and requires a VM. Do they really use more memory for equivalent code. e.g. Is jetty that much worse than apache? I don't really think so.

Even if the intrinsic memory consumption of a java object is more than one for a C struct that does not mean it will in practice actually use more memory, or that it has too be that way due to unassailable theoretical grounds. See Realtime java for an example.

> The VM probably is written in C, too. Historical reasons only. It could have been fortran or pascal. Its not that C is magical in its low level. There are a whole bunch of other options as well. C was easy to get and it came with the OS for many developers when computers became more accessible due to lower costs in the late 70's and 80's. C is slow is not an uncommon opinion among fortran programmers, for good reasons. In practice the C++ parts of the different JVMs are getting smaller each release. And there have been JVMs that are written in Java with a bootstrap interpreter in ASM. As an OS with just java and assembly. After all, the language is turing complete...

Don't take me wrong Java is not some promised land without issues, its got plenty of those. I am just refuting the idea that just because it written in C it is fast claim.

GCC/XLC/ICC are not magic, neither is HotSpot or Vuze or J9 or any other JVM system.

In many ways C and Java are alike, crap languages introduced in a time when other, better alternatives where available. Only saved by industry adoption and decades of engineering work to make them fly.

Rust is so interesting as it has industry attention and is also academically interesting as bringing something new to the programming world. (at least I am not aware of any pl with the borrow checker concept worked out).

Java isn't exactly a big step up. Compare instead old C code to Haskell or OCaml. I am pretty sure the latter comes out a lot better with respect to serious bugs.

Also I have real world experience with working with the same type of code in two different languages and seeing a clear difference. I've rewritten a lot of Objective-C code to Swift e.g. Objective-C as a language is much like C with similar problems as C. Just doing a straight conversion the Swift compiler picked up a lot of problems from my Objective-C code I had never discovered otherwise.

Lots of other people write about similar experience of getting significant bug reduction from moving to a much more type safe language like Swift.

Actually serious bug detection and prevention is not bad in C either. Most C code uses very well accepted design patterns which is very readable to a seasoned C programmer. Haskell and OCaml are better at easy reasoning of correctness of a program. Serious C bugs are around performance and security, not correctness.

The thing is, what a C programmer would consider a serious bug pertaining to performance and security, would not be fixable by Haskell being a better syntax. Ultimately it's the compiler that would bear the onus. Now generic compilers would always have performance issues and can't make everyone happy. That's the real problem here. It's easy to fix serious bugs (from perspective of systems programmers) in C than to fix them in Haskell. You have no control over compiled code or how it's going to turn out. The so called weirdness of C arises from the fact that non-seasoned C programmer do not understand why a C programmer is doing something. A weird C syntax usually is a signal to the compiler to write instruction code in a certain way.

It's not about correctness that a lot of C programmers are worried about. Well, at least not more than other languages. What we're worried about is what happens when rubber hits the road. It's very hard to do that from the driver's seat. Even Go, which tries to be closer to metal has issues around this. Things like Go, Obj-C, Swift are great where you simply want performance of machine code. But that's not the major argument to use C.

You seem to be talking about a very specific area. As I've eluded to earlier, there are clearly jobs where C is best suited, but C is hardly the best choice in most of the areas it is used. People are still doing GUI programming in C. That is a really poor fit for the language.

C isn't automatically easier to achieve high performance. Depends on what sort of problems we are talking about. If I remember correctly CouchDB was written in C/C++ originally and they switched to Erlang and got both much less code and higher performance.

But in something like a game engine were you want to be able to control memory layout and allocation C/C++ is a benefit. But Rust/Swift/Go allows you to do much of the same to various degrees.

At my work people write codecs and stuff and C is clearly a benefit due to its closeness to the metal. And as you say, yes they do write odd code at times because they know a lot about how the C compiler translates various constructs to assembly code. But this is specialist work. Most C coding doesn't involve this type of coding.

I think I just have to agree to disagree with you about correctness though. I had several years of C experience when I first tried Standard ML, and I manage to get a sorting algorithm correct on first try in SML, something I've never done in C. There will always be some stupid off by one type of error.

People have conducted studies of these sort of things and tend to measure better results for functional languages. One notable property of C programs is also that for any group of C programmers there is a huge variation in performance of the programs they write. The top C developers beat anybody. But average C programs are often slower than even average Python programs.

Full programmer control and preventing bugs, security holes and so on are not fundamentally opposed. It's not like most programmers go to work trying to make sure their software has a certain number of buffer overflows in it. It just turns out that preventing that in C is really, really hard.

To take the car analogy further, whether your car is manual or automatic, seat belts and airbags are valuable. Neither of them compromises a driver's full control of their car.

Reply on news.ycombinator.com