A Successor of C++?

[lpetrich]

Several programming languages have successors that build on them, successors that eliminate or get around awkward features of them:

Language	Successor
C	C++
Java	Kotlin
JavaScript	TypeScript
Objective-C	Swift
C++	?

What might succeed C++? Here are several recently-devised C and C++ alternatives:

• Home - D Programming Language
• The V Programming Language
• The Go Programming Language
• Home Zig Programming Language
• Nim Programming Language
• The Beef Programming Language
• JaiPrimer/JaiPrimer.md at master · BSVino/JaiPrimer · GitHub
• Rust Programming Language

Here is the newest one:

GitHub - carbon-language/carbon-lang: Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)

Project status

Carbon Language is currently an experimental project. There is no working compiler or toolchain. You can see the demo interpreter for Carbon on compiler-explorer.com.

We want to better understand whether we can build a language that meets our successor language criteria, and whether the resulting language can gather a critical mass of interest within the larger C++ industry and community.

Google's engineers have created other programming languages, like Dart and Go.

Google’s New Programming Language is Called Carbon | by Aniket | Geek Culture | Jul, 2022 | Medium

What Is Carbon Programming Language By Google? | Level Up Coding
noting this introduction to Carbon:
Carbon Language: An experimental successor to C++ - Chandler Carruth - CppNorth 2022 - YouTube

CC mentioned some difficulties:

• Technical debt. Necessary choices that made C++ great are becoming a burden. C++ accumulated decades of technical debt.
• Prioritization of backward compatibility. More and more features have been added, rather than removed or replaced. While backward compatibility is important, it comes at a cost. It adds and prevents fixing the technical debt.

Not only with plain C, but also with earlier C++.

Also with the governance of C++ -- a big cumbersome standards body.

Shadow cast over future of Google's C++ replacement

n the past, languages such as D and Objective-C have made some improvements over C++ -- but the huge C++ code base makes it a challenge to replace, Cornwall said. Rust is not an ideal C++ replacement because it is not source-code compatible with C++ and doesn't have classes -- a defining idea in object-oriented programming -- but it does support modern features such as more secure memory allocations that make it safer than C++, he said.

A new programming language that might be successor to C++

Before Carruth introduced us to Carbon, another programming language called Rust was seen as the successor to C++. This was primarily because of its syntactic similarities to C++, as it provides increased speed and better memory safety. However, this is open to discussion since many developers found Rust too difficult to learn as it introduced a lot of novel concepts too.

Besides the steep learning curve, converting major projects’ current C++ codebases to Rust is challenging. Further, according to the developers of Carbon, the design of Rust itself acts as a significant barrier to adoption and migration from C++. On the other hand, Carbon aims to convert the C++ codebases in a much better way than Rust.

For a C++ developer, it won’t be difficult to learn Carbon. In fact, Carbon is said to have a gentle learning curve. While many felt using Rust was similar to learning a new programming language.

 

[Jarhyn]

Several programming languages have successors that build on them, successors that eliminate or get around awkward features of them:

Language	Successor
C	C++
Java	Kotlin
JavaScript	TypeScript
Objective-C	Swift
C++	?

What might succeed C++? Here are several recently-devised C and C++ alternatives:

• Home - D Programming Language
• The V Programming Language
• The Go Programming Language
• Home Zig Programming Language
• Nim Programming Language
• The Beef Programming Language
• JaiPrimer/JaiPrimer.md at master · BSVino/JaiPrimer · GitHub
• Rust Programming Language

Here is the newest one:

GitHub - carbon-language/carbon-lang: Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)

Project status

Carbon Language is currently an experimental project. There is no working compiler or toolchain. You can see the demo interpreter for Carbon on compiler-explorer.com.

We want to better understand whether we can build a language that meets our successor language criteria, and whether the resulting language can gather a critical mass of interest within the larger C++ industry and community.

Google's engineers have created other programming languages, like Dart and Go.

Google’s New Programming Language is Called Carbon | by Aniket | Geek Culture | Jul, 2022 | Medium

What Is Carbon Programming Language By Google? | Level Up Coding
noting this introduction to Carbon:
Carbon Language: An experimental successor to C++ - Chandler Carruth - CppNorth 2022 - YouTube

CC mentioned some difficulties:

• Technical debt. Necessary choices that made C++ great are becoming a burden. C++ accumulated decades of technical debt.
• Prioritization of backward compatibility. More and more features have been added, rather than removed or replaced. While backward compatibility is important, it comes at a cost. It adds and prevents fixing the technical debt.

Not only with plain C, but also with earlier C++.

Also with the governance of C++ -- a big cumbersome standards body.

Shadow cast over future of Google's C++ replacement

n the past, languages such as D and Objective-C have made some improvements over C++ -- but the huge C++ code base makes it a challenge to replace, Cornwall said. Rust is not an ideal C++ replacement because it is not source-code compatible with C++ and doesn't have classes -- a defining idea in object-oriented programming -- but it does support modern features such as more secure memory allocations that make it safer than C++, he said.

A new programming language that might be successor to C++

Before Carruth introduced us to Carbon, another programming language called Rust was seen as the successor to C++. This was primarily because of its syntactic similarities to C++, as it provides increased speed and better memory safety. However, this is open to discussion since many developers found Rust too difficult to learn as it introduced a lot of novel concepts too.

Besides the steep learning curve, converting major projects’ current C++ codebases to Rust is challenging. Further, according to the developers of Carbon, the design of Rust itself acts as a significant barrier to adoption and migration from C++. On the other hand, Carbon aims to convert the C++ codebases in a much better way than Rust.

For a C++ developer, it won’t be difficult to learn Carbon. In fact, Carbon is said to have a gentle learning curve. While many felt using Rust was similar to learning a new programming language.

The thing is, C++ is "hard" because there are things it doesn't hold your hand on, but doesn't tie your hands on anything either.

I'm not sure many things can challenge C++ effectively owing to the fact that sometimes, programmers want to have direct access to memory primitives and low level structures.

As it is, it's not that C++ is in any way a successor to C. One language adds things to the other, but C is widely employed in low-overhead embedded code and other bare-metal and lightweight safety critical applications.

 

[Loren Pechtel]

I'm not sure many things can challenge C++ effectively owing to the fact that sometimes, programmers want to have direct access to memory primitives and low level structures.

As it is, it's not that C++ is in any way a successor to C. One language adds things to the other, but C is widely employed in low-overhead embedded code and other bare-metal and lightweight safety critical applications.

Yeah, sometimes you need the hardware. Things like drivers generally have to be in a language at that level.

As for C++ being a successor to C, simply look at it's name! C++ means to take C, increment it (make it better), but return (use) the original.

 

[Jarhyn]

I'm not sure many things can challenge C++ effectively owing to the fact that sometimes, programmers want to have direct access to memory primitives and low level structures.

As it is, it's not that C++ is in any way a successor to C. One language adds things to the other, but C is widely employed in low-overhead embedded code and other bare-metal and lightweight safety critical applications.

Yeah, sometimes you need the hardware. Things like drivers generally have to be in a language at that level.

As for C++ being a successor to C, simply look at it's name! C++ means to take C, increment it (make it better), but return (use) the original.

As I said, it has more, but it also has less, in ways.

As it is there's a fair bit of codebase I touch that's broken out into compiler directives with assembly operations in them.

Knowing exactly where things are is nice.

*And neurotically completionist

 

[steve_bank]

One thing C++ was designed to do was limit the damage unrestricted C could do. Unrestricted pointers for ome

Objects serve to prevent outside corruption f ata and code in the object and vice versa. Large C code became impossible to debug and maintain. C++ makes large projects by multiple coders to be integrated and maintained. Minimizing side effects.

I am long out of touch with Windows but it does not allow the direct access to the memory map that DOS did.

For embedded apps C is the common tool.

At the first company I worked at in the early 80s when a software engineer left his code had to be rewritten from scratch. In those days it was not unheard of when a programmer left a cmpany he was given a yearly retainer to support the code because nobody else coud figure it out.

Later in the 80s on a project I had somebody wring C code fr me. When he left I had to rewrite from scratch myself.

 

[Jarhyn]

One thing C++ was designed to do was limit the damage unrestricted C could do. Unrestricted pointers for ome

Objects serve to prevent outside corruption f ata and code in the object and vice versa. Large C code became impossible to debug and maintain. C++ makes large projects by multiple coders to be integrated and maintained. Minimizing side effects.

I am long out of touch with Windows but it does not allow the direct access to the memory map that DOS did.

For embedded apps C is the common tool.

At the first company I worked at in the early 80s when a software engineer left his code had to be rewritten from scratch. In those days it was not unheard of when a programmer left a cmpany he was given a yearly retainer to support the code because nobody else coud figure it out.

Later in the 80s on a project I had somebody wring C code fr me. When he left I had to rewrite from scratch myself.

I would wonder what you call that on a resume, being able to just... Understand someone else's C code.

 

[steve_bank]

One thing C++ was designed to do was limit the damage unrestricted C could do. Unrestricted pointers for ome

Objects serve to prevent outside corruption f ata and code in the object and vice versa. Large C code became impossible to debug and maintain. C++ makes large projects by multiple coders to be integrated and maintained. Minimizing side effects.

I am long out of touch with Windows but it does not allow the direct access to the memory map that DOS did.

For embedded apps C is the common tool.

At the first company I worked at in the early 80s when a software engineer left his code had to be rewritten from scratch. In those days it was not unheard of when a programmer left a cmpany he was given a yearly retainer to support the code because nobody else coud figure it out.

Later in the 80s on a project I had somebody wring C code fr me. When he left I had to rewrite from scratch myself.

I would wonder what you call that on a resume, being able to just... Understand someone else's C code.

You are a real trip.

C++, IOW object orinted programming, was devised to deal with maintenance and integration problems. If you have wrtten anything beyond straightforward code all by yurself nbody else has to deal with you woud undertsand thatt.

What came out of the software mess was software developemnndrds. Documentation and revision control. Resuablilty.

Back in the 80s someone wold start project and others would add to the point where it became a monster. In the 80s therer were monser programs written in Basic including GW Basic that came with the MSDOS ditribution.

In the 80s when I was in Portland the Beaverton telephone company downloaded a sw update. It crashed. It turned out somebody at the manufacturer deleted code that appeared to do nothing. Fence the comany policy became thos shall add but not remove.

Yes being able to debug problems on code you did not write is part of the skill set. A bug appears and you add a patch, jump here jump there. In comrehesible to anyone else but you. Debuggers and tools that would automatically map code flow came along.

Not well known is AIDA which is used in aerospace. It is OOP and more restrictive than C++. The goal being high reliability. Readability meaning minimizing the chance of bugs surfacing past release which was another reason for C++.

In the 80s I had a roommate who was a COBOL programmer for a large company. He was on a rotating night call with a pager. If something crashed in the midle of the night he had to go in and fix it.

Ada (programming language) - Wikipedia

en.wikipedia.org

ISO standards. There are others like DOD, aerospace, and ANSI.

Software Quality Standards – ISO 5055 | CISQ - Consortium for Information & Software Quality

Software development teams can use code quality standards to evaluate the structural quality of systems ahead of each release. By applying standards earlier in the software development lifecycle, a codebase can be carried over to other products, developed further, or open sourced with greater...

www.it-cisq.org

 

[Jarhyn]

The fact is, Steve, I build my career primarily around understanding other people's code.

Sometimes it's not C code but raw assembly.

Either way, C code has a place, and I would hazard to say being able to maintain C code someone else wrote rather than chucking it, is a major skill.

 

[Loren Pechtel]

The fact is, Steve, I build my career primarily around understanding other people's code.

Sometimes it's not C code but raw assembly.

Either way, C code has a place, and I would hazard to say being able to maintain C code someone else wrote rather than chucking it, is a major skill.

Yeah. Talking to the hardware you need C, loathsome as it is.

 

[steve_bank]

The fact is, Steve, I build my career primarily around understanding other people's code.

Sometimes it's not C code but raw assembly.

Either way, C code has a place, and I would hazard to say being able to maintain C code someone else wrote rather than chucking it, is a major skill.

There is the one and only holy C. Thou shalt not have any false languages.

Of course C has its place and OOP is not for everything.

You apprently asked about career advice.. Or maybe you were just being snarky.

There are extensions like C#

The OP is more generally is there somethng beyond OOP? I expect AI and neural nets have specific structures and methodologies which are not OOP.

 

[Loren Pechtel]

The fact is, Steve, I build my career primarily around understanding other people's code.

Sometimes it's not C code but raw assembly.

Either way, C code has a place, and I would hazard to say being able to maintain C code someone else wrote rather than chucking it, is a major skill.

There is the one and only holy C. Thou shalt not have any false languages.

C is half a language.

 

[steve_bank]

Infidels will burn in Pascal Hell!!!!

When I was fluent I could type code a lot faster and it took a lot less lines than any other language. The features of C++ and using OOP made the projects I did a lot easier.

I designed and wrote code for test and measurement systems. Custom hardware, motion control, and instruments on the GPIB bus. The first one I did I used Quick Basic. The next was C. The 3rd I started in C and shifted to C++ after reading up on it. Borland compilers.

I defined a set of objects I needed, wrote code for therm, tested them individually, then put them in an object library. Then I built the higher level functionty using the objectIf I made a chnage to an object I recompiled the object and rebuilt he project with zero risk of unintended side effects.

You can do something similar in C, but it is not as robust as code size and complexity grows. OOP and C++ makes it much easier to add to and modify code without chasing side effects.

I dealt with latge data sets and calibration tables. Being able to protect data in an object was a big benifit. No chnae of an errant pointer corrupting data. Run time spawing f objects was a plus.

 

[Swammerdami]

I wrote a LOT of code back in the day, and still do, though now just for fun. I LOVED C but detested C++. My objection was less to the features of C++ than to some of the philosophy that seemed to go along with it. I also disagreed with the idea that adding a feature to a language necessarily made the language better. Dennis Ritchie has a memorable quote agreeing with me on that, but I'm too lazy to try Googling for the quote.

I produced some code (C or assembly) that I'm proud of and some that makes me sick to look at; but almost all my programming was single-man efforts. An exception was when I consulted for a large software project that had fallen behind schedule. I've wanted to see a thread "Great Fiascos in Software" where I could outline that ridiculous project. (Most of the coding was in C, but that was the least of their problems.)

 

[Jarhyn]

The fact is, Steve, I build my career primarily around understanding other people's code.

Sometimes it's not C code but raw assembly.

Either way, C code has a place, and I would hazard to say being able to maintain C code someone else wrote rather than chucking it, is a major skill.

Yeah. Talking to the hardware you need C, loathsome as it is.

Right now I'm sitting on a PIC33 codebase with a full scheduled homebrew RTOS in C.

The biggest hurdle to approaching it was the way my then-bosses talked about it being unapproachable.

I did not find it unapproachable once I actually approached it however, and have debugged through most parts of it, including the serial device driver layer, which was also written by my predecessor along with the OS.

C is like the... I suppose you'd call it chemical physics of programming. It's not quite down in the assembly of particles/nuclear physics, or the truth tables and state diagrams of QM, but it's also not as unresolved as macrophysics of C++, either, or the lay couch potato physics of "modern programming languages", or the "plumbing" of AI*.

More, I think the thing that keeps people from internalizing the knowledge that they can is everyone convincing them that they can't.

In many respects putting together a DC motor system isn't much different than putting together an ICE, it's just that the power trains shove electrons through wires instead of through axles and belts, but a lot of competent mechanics lose their shit when you switch from teeth on a gear to coils on a wire, even though they operate on the same principles of leverage! As an example of how people lose their shit at system type boundaries.



*It's taking masses of neurons of whatever type manages to work well and connecting them on interfaces. It's like hooking up and measuring pipes. I was able to forget, for a while, the majority of math in actually operating a neuron! It amazes me sometimes that I've explored that entire universe of stack between assemblies to modern AI deployment.

 

[Loren Pechtel]

Infidels will burn in Pascal Hell!!!!

When I was fluent I could type code a lot faster and it took a lot less lines than any other language. The features of C++ and using OOP made the projects I did a lot easier.

Yeah, I used Turbo Pascal/Delphi for a long time and loved it. However, the quality deteriorated and for me the last straw was when they took so long to come out with a 64-bit compiler. They looked at the number of users who needed it and put it at a low priority--but what they really did is they told us that we could not count on them.

These days I use C#. By now it has almost everything that Delphi had and it's garbage collected so there's a lot less hassle with tracking allocations. While it doesn't support procedural code you can accomplish the same thing with static declarations. (And in reality procedural code has it's place even now. There are a lot of basic library functions that gain nothing from objects.)

 

[Loren Pechtel]

The fact is, Steve, I build my career primarily around understanding other people's code.

Sometimes it's not C code but raw assembly.

Either way, C code has a place, and I would hazard to say being able to maintain C code someone else wrote rather than chucking it, is a major skill.

Yeah. Talking to the hardware you need C, loathsome as it is.

Right now I'm sitting on a PIC33 codebase with a full scheduled homebrew RTOS in C.

The biggest hurdle to approaching it was the way my then-bosses talked about it being unapproachable.

I did not find it unapproachable once I actually approached it however, and have debugged through most parts of it, including the serial device driver layer, which was also written by my predecessor along with the OS.

C is like the... I suppose you'd call it chemical physics of programming. It's not quite down in the assembly of particles/nuclear physics, or the truth tables and state diagrams of QM, but it's also not as unresolved as macrophysics of C++, either, or the lay couch potato physics of "modern programming languages", or the "plumbing" of AI*.

More, I think the thing that keeps people from internalizing the knowledge that they can is everyone convincing them that they can't.

In many respects putting together a DC motor system isn't much different than putting together an ICE, it's just that the power trains shove electrons through wires instead of through axles and belts, but a lot of competent mechanics lose their shit when you switch from teeth on a gear to coils on a wire, even though they operate on the same principles of leverage! As an example of how people lose their shit at system type boundaries.



*It's taking masses of neurons of whatever type manages to work well and connecting them on interfaces. It's like hooking up and measuring pipes. I was able to forget, for a while, the majority of math in actually operating a neuron! It amazes me sometimes that I've explored that entire universe of stack between assemblies to modern AI deployment.

While it's possible to write sane C the language really discourages it. And while I can see the benefit of arrays as pointers it causes an awful lot more pain than gain. C needs fundamental array and string types.

 

[steve_bank]

I heard C called a glorified assembler. You can directly access processor registers. Depending on the app you can use it like an assembler.

You can create string arrays, but it may take a little work.

In C all variables and function locations are pointers. That was one of problems C++ addresses. In a large project with multiple coders someone can declare a pointer to a function in the code and directly access code and data in a function. C++ will not sallow any external pointers to private data and functions in an object.

When you run the compiler a symbol table is created with variables and functions as offsets from the start of the code. For absolute code like an embedded application the linker and loader assigns absolute memory locations starting at the address you specify. For relocatable code like a Windows app the OS looks at the symbol table and assigns a staring memory location when loaded into memory.

It can be instructive to look at the symbol table and the assembly language code.

Compilers should let you see the symbol table.

There have been a number of PIC OSs. I think there is a small Linux that fits into some of their 32 bit devices.

 

[lpetrich]

C is not designed for explicit CPU-register access, as far as I know. But it is nevertheless low-level about memory access, with its use of pointers. Most other high-level languages hide their pointers and throw exceptions for out-of-range array accesses.

But pointers are useful for low-level work, like OS kernels, low-level utilities, and device drivers. Most device interfaces are accessed by giving them their own memory addresses, and then reading from and writing to those addresses. Those addresses are specified in pointers, of course.

C++ is built on top of C, and C++'s Standard Template Library is designed to hide the pointers that it uses. Though the STL's abstractions are well-designed, using them can be awkward.

Consider the "vector" class. It is a resizable array that handles reallocation behind the scenes and that deallocates array memory when it goes out of scope. Hidden pointers and automatic deallocation are in the other STL container classes, and they avoid stale pointers and memory leaks.

Let's consider a list of ints, vector<int>numlist

One adds to it with numlist.push_back(newnum), finds out how many are in it with numlist.size(), reallocates with numlist.resize(), and accesses with numlist[index] (no bounds checking) or numlist.at(index) (bounds checking). So this class offers a speed/safety tradeoff.

Let's try adding up some numbers. Here's how one does it in plain C:

int sum = 0;
for (int i = 0; i < numlistlen; i++)
   sum += numlist[i];

One needs an array, numlist, and its length, numlistlen.

One can carry this over into C++ very easily:

int sum = 0;
size_t numlistlen = numlist.size();
for (int i = 0; i < numlistlen; i++)
   sum += numlist[i];

An alternative, one that can generalize to other types of containers, uses iterators:

int sum = 0;
for (vector<int>::iterator iter = numlist.begin(); iter != numlist.end(); iter++)
   sum += *iter;

The iterator has a complicated data type, but recent versions of C++ permit type inference with the keyword "auto". If the compiler can catch mismatched types, then it can infer types.

int sum = 0;
for (auto iter = numlist.begin(); iter != numlist.end(); iter++)
   sum += *iter;

A further addition is a kind of foreach:

int sum = 0;
for (auto num: numlist)
   sum += num;

This version copies each number into "num", something not very desirable for some data types. To avoid that, one can call by reference, another way to hide pointers.

int sum = 0;
for (auto &num: numlist)
   sum += num;

But call by reference means that something can alter "num", so we get around that with the const keyword:

int sum = 0;
for (const auto &num: numlist)
   sum += num;

Yes, one can use "const" in C++ for something found at run time and not just compile time.

I note that Rust essentially assumes "const" unless one specifies otherwise, with its "mut" keyword (mutable).

 

[lpetrich]

As to value vs. reference, plain C does all function calls by value. This is OK for input of lightweight data, like integers or floats or characters, but not for heavyweight data or when one wants to return a modified value in an arg.

For that, C++ offers call by reference, with &, thus hiding a pointer. Thus, instead of transmitting a pointer, int *num, one does int &num, and if one has some heavyweight object that one does not want changed, something like const int &num.

Many features of C++ are designed to hide pointers, and also to avoid using the preprocessor. Declaring something const makes it unnecessary to define constants with the preprocessor, and template functions and classes also make a lot of preprocessor use unnecessary,. C++ also offers the keyword "inline", to specify inserting a function's code into its caller, something that offers the sort of speedup that one can get with a preprocessor function. All this C++ preprocessor banishment offers an additional nice feature: type safety.

C++ mostly uses static typing, something that may be annoying when coding, but something that enables catching a lot of bugs at compile time rather than run time.

That static typing is why Microsoft created TypeScript - a sort of type-safe front end for JavaScript.

 

[lpetrich]

A new feature of C++ is "concepts" -- something like Rust type traits. This is a further extension of the template system, and one can specify whether some type is a kind of integer, whether it supports comparisons, etc.

From what I've seen of Carbon, it supports concepts / type traits and generics (templates under another name), and its pointers are completely hidden. But if Carbon is to be completely compatible with C++, then it ought to have a Rust-like "unsafe" option, an option which would allow use of pointers beyond transmitting their values.