Slashdot Mirror
ESR Sees Three Viable Alternatives To C (ibiblio.org)
An anonymous reader writes:
After 35 years of programming in C, Eric S. Raymond believes that we're finally seeing viable alternatives to the language. "We went thirty years -- most of my time in the field -- without any plausible C successor, nor any real vision of what a post-C technology platform for systems programming might look like. Now we have two such visions...and there is another."
"I have a friend working on a language he calls 'Cx' which is C with minimal changes for type safety; the goal of his project is explicitly to produce a code lifter that, with minimal human assistance, can pull up legacy C codebases. I won't name him so he doesn't get stuck in a situation where he might be overpromising, but the approach looks sound to me and I'm trying to get him more funding. So, now I can see three plausible paths out of C. Two years ago I couldn't see any. I repeat: this is huge... Go, or Rust, or Cx -- any way you slice it, C's hold is slipping."
Raymond's essay also includes a fascinating look back at the history of programming languages after 1982, when the major complied languages (FORTRAN, Pascal, and COBOL) "were either confined to legacy code, retreated to single-platform fortresses, or simply ran on inertia under increasing pressure from C around the edges of their domains.
"Then it stayed that way for nearly thirty years."
"I have a friend working on a language he calls 'Cx' which is C with minimal changes for type safety; the goal of his project is explicitly to produce a code lifter that, with minimal human assistance, can pull up legacy C codebases. I won't name him so he doesn't get stuck in a situation where he might be overpromising, but the approach looks sound to me and I'm trying to get him more funding. So, now I can see three plausible paths out of C. Two years ago I couldn't see any. I repeat: this is huge... Go, or Rust, or Cx -- any way you slice it, C's hold is slipping."
Raymond's essay also includes a fascinating look back at the history of programming languages after 1982, when the major complied languages (FORTRAN, Pascal, and COBOL) "were either confined to legacy code, retreated to single-platform fortresses, or simply ran on inertia under increasing pressure from C around the edges of their domains.
"Then it stayed that way for nearly thirty years."
C has critical flaws everywhere: insane preprocessor, no module system or namespaces, all kinds of obscure undefined behaviors, no way to express important safety properties like "pointer is never null", weak type system that can't express tagged unions or tell the difference between data and code pointers (https://lkml.org/lkml/2017/9/25/708), broken type syntax where it's impossible for humans to write complex types, security-bug-prone standard library APIs like sprintf and strcpy, standard library missing basic stuff like hash tables, inability to expose basic library features like ref-counted pointers and growable arrays ergonomically, ...
I could go on and on.
> Static code analysis and runtime checking (valgrind) pretty makes C's little issues a non-event now.
Just not true, even if you add in manual security audits as well. For example:
https://lwn.net/Articles/73545...
Have you seen how much crap is added to C++? It's a bloated, complex beast full of hacks to fix other hacks. C++ needs to die.
I live and breathe C++. Its a perfectly fine language. Except a few minor quirks, the language behaves quite nicely. Perhaps you are basing your experience from the STL nightmare that existed circa 2000. Even Microsofts STL implementation is now reasonably compliant with the standard, and the standard is quite good. If you are continuing to have trouble with the language, then I would submit that you are probably not a very good programmer, and the behavior of the language (which requires you to have a good grasp on how computers actually work), is probably mysterious to you, but each and every behavior of C++ is there for a very good reason. Other languages hide these ugly details from you, and the very act of hiding these details means that the language is sub-par because the devil is in those very same details. I will grant you, C++ has a steeper learning curve than most languages, but the performance of the code you can write in C++ is vastly superior to all languages except maybe C. There are constructs I can create with template metaprogramming that even C cannot match the performance of. Proper use of the STL allows you to minimize the need for memory management, but like any C derivative, the option of going all pointer-fu is there if you need it.
In all, C is a language for professionals, C++ is a language for experts. Everything else is for amateurs.
I wish I had a good sig, but all the good ones are copyrighted
I will grant you, C++ has a steeper learning curve than most languages, but the performance of the code you can write in C++ is vastly superior to all languages except maybe C. There are constructs I can create with template metaprogramming that even C cannot match the performance of. Proper use of the STL allows you to minimize the need for memory management, but like any C derivative, the option of going all pointer-fu is there if you need it.
In all, C is a language for professionals, C++ is a language for experts. Everything else is for amateurs.
I'm guessing that you are only referring to higher level languages by this comment. But just for the the record, Assembler gives you better performance than C and C++.
Look at Julia. It is similar to Go, Rust, Swift and the like in that it uses LLVM for generating the final machine code. It can be quite efficient. The language is designed for similar uses as Matlab - except it does not suck. I prefer Julia to Matlab for everything other then debugging - the Matlab debugger is great compared to what is available for Julia.
I write in C for embedded systems. Matlab generated C code is too bloated and inefficient. Especially for a DSP. I've been down that Matlab path with high hopes and it didn't work well. It's still a good idea to test the algorithm in Matlab.
and that is the memory management of C++ that isn't predictable for use in the kernel.
Bizarre. You can overload new and delete on a per-class basis. There's no C++ in the kernel because Linus is irrationally afraid of it - it's doubly absurd when you go & look at that code, and there's member functions, and virtual methods, and per-class allocation calls, all written in C.
No one writes C for embedded control systems, we let Simulink and Matlab handle that.
I work on embedded systems. I have been involved in dozens of projects. I have never, not once, seen Simulink or Matlab used in a final product.
The answer is here: https://bugs.chromium.org/p/ch...
The big change is that there is now, for all *NIX platforms, a stable C++ ABI. The HP Itanium ABI was adopted largely as-is by all *NIX systems (with the slight exception of 32-bit ARM, which does exceptions slightly differently and handles pointers to members differently because the low bit in instruction pointers is already in use for thumb interworking). Variations between archs don't matter too much, but changes within an architecture are problematic because they mean that you can't define long-term-stable interfaces in terms of C++. On Windows, for example, all public interfaces are either C or COM because the MS compiler changes ABI across Visual Studio versions. Apple was bitten by this, because they defined kernel (IOKit) interface in terms of the gcc 2.95 ABI and had a lot of pain to move everything to the Itanium ABI (largely motivated by the fact that clang never supported the old ABI).
On a related note, compilers are a lot better at optimising C++ now than they were 20 years ago. All of the companies that employ a lot of LLVM or GCC developers now have huge internal C++ codebases and care more about the performance of these than of their C code. This is a huge shift from 20 years ago, where C++ was a checklist feature for gcc (clang didn't exist) and no one really cared about C++ performance. 20 years ago, renaming a .c file to .cc and compiling it with gcc would often give you slower code. Now, it will give you exactly the same code and performance doesn't get worse as you use more C++ features. For example, both templates and lambdas rely on the inliner a lot and modern C/C++ compilers have tuned their inliners on this use case more than on common C idioms.
In terms of language features, there are a few big ones. The first is lambdas. These can be used in a lot of places where you'd use macros and generate the same code, but be a lot more readable. The other large feature is the addition of move semantics. This is very important for kernel-style code, where you want to have fine control over memory ownership. Things like the standard library unique_ptr template give you a trivial way of expressing unique ownership in the code, in a way that can be transferred between threads, and compiles down to no code but statically checks that you've followed the correct discipline.
There are a few other things that are pretty useful. Generalised constexpr means that you can write functions that should be evaluable at compile time and you can use a trivial template wrapper to force compile-time evaluation. This is very useful in code where you need to reason about run-time complexity, because you can guarantee that the compiler really will evaluate something at compile time or fail to compile.
For the kernel, the improvements to enums in C++11 can also be useful. You can define enums that are actually type safe (i.e. they're not just the equivalent of #defines of int values and assigning the wrong enum is actually an error) and which have a storage type other than int.
The Linux kernel has a really crappy way of handling memory orderings, which basically rely on having macros that map to the different memory barriers on Alpha and having programmers insert them in the right places, so it's not as well suited as something like FreeBSD to adopting C++11 atomics (FreeBSD provides functions that have almost identical semantics to the C++11 acquire-release model), but adopting it exposes a lot more opportunities for compiler optimisations. The current atomics are all implemented as asm volatile statements, which provide a full compiler barrier (the compiler may not move instructions from one side to the other, even if it would be safe to in the memory model). C11 also has support for this, but it's a really ugly copy and paste of the C++11 stuff to C11 and the standard ends up writing volatile in a bunch of places where it means _Atomic, so using them is painful.
Range-based for loops don't give you anything other
I am TheRaven on Soylent News