6 ms·
I think this is not a serious question, but I'll bite. We're paying a hefty price for C in the form of buffer overflows, memory leaks, slow development, and oth
by beering 11y ago
I think this is not a serious question, but I'll bite. We're paying a hefty price for C in the form of buffer overflows, memory leaks, slow development, and other problems and will continue to do so as long as we run software written in C. If we instead switch to a language that doesn't have these problems, then we'll come out better in the long run.
- flashm 11y agoIt was slightly tongue in cheek - C is good at what it does, but I agree that there are plenty of good options going forward. I just don't think C will be 'replaced' across the board though, but I suppose that's obvious. Of the languages mentioned, I've only got experience with Go (which I use for APIs). Rust looks interesting though, I need to have a proper look at it.
- EliRivers 11y agoWe won't come out "better". We'll have made a trade-off. For some situations, it will have been a trade-off that benefits. For others, it will have been the wrong choice. Just use the right tool for the job given the circumstances.
- arihant 11y agoThese 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.
- jerven 11y agoC 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.
- z92 11y ago> 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.
- pjmlp 11y agoThere 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.
- jerven 11y ago> 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).