In some ways, C and C++ run the world. You'd never know it from all the hype about other programming languages, such as Python and Go, but the vast majority of high-performance mass-market desktop applications and operating systems are written in C++, and the vast majority of embedded applications are written in C. We're not talking about smartphone apps or web applications: these have special languages, such as Java and Kotlin for Android and Objective-C and Swift for iOS. They only use C/C++ for inner loops that have a crying need for speed, and for libraries shared across operating systems.
C and C++ have dominated systems programming for so long, it's difficult to imagine them being displaced. Yet many experts are saying it is time for them to go, and for programmers to embrace better alternatives. Microsoft Azure CTO Mark Russinovich recently made waves when he suggested that C and C++ developers should move to Rust instead. "The industry should declare those languages as deprecated," Russinovich tweeted.
Many developers are exploring Rust as a production-ready alternative to C/C++, and there are other options on the horizon. In this article, we'll consider the merits and readiness of the three most cited C/C++ language alternatives: Rust, Carbon, and cppfront. First, let's take a look back through the history and some of the pain points of C/C++.
[...] The Rust-lang homepage declares three major reasons to choose Rust: performance, reliability, and productivity. Rust was designed to be fast, safe, and easy to use, with the overarching goal of empowering everyone to build reliable and efficient software.
As far as performance goes, Rust is both fast and memory-efficient: with no runtime or garbage collector, it can power performance-critical services, run on embedded devices, and easily integrate with other languages. On the reliability side, Rust's rich type system and ownership model guarantee memory safety and thread safety—which developers can use to eliminate many classes of bugs at compile-time. For productivity, Rust boasts great documentation, a friendly compiler with useful error messages, and top-notch tooling—an integrated package manager and build tool, smart multi-editor support with auto-completion and type inspections, an auto-formatter, and more.
[...] The stated goals of the Carbon language project are: performance-critical software; software and language evolution; code that is easy to read, understand, and write; practical safety and testing mechanisms; fast and scalable development; modern OS platforms, hardware architectures, and environments; and interoperability with and migration from existing C++ code.
[...] Herb Sutter has served for a decade as chair of the ISO C++ standards committee. He is a software architect at Microsoft, where he's led the language extensions design of C++/CLI, C++/CX, C++ AMP, and other technologies. With Cpp2 and cppfront, Sutter says his "goal is to explore whether there's a way we can evolve C++ itself to become 10 times simpler, safer, and more toolable." He explains:
If we had an alternate C++ syntax, it would give us a "bubble of new code that doesn't exist today" where we could make arbitrary improvements (e.g., change defaults, remove unsafe parts, make the language context-free and order-independent, and generally apply 30 years' worth of learnings), free of backward source compatibility constraints.
[...] Rust, Carbon, and Cppfront all show promise as C++ alternatives. For Carbon, we're probably looking at a five-year development cycle until it's released for production. Cppfront might be available for production sooner, and Rust is already there.
All three languages are (or will be) interoperable with C++ at a binary level. That implies that all three languages could allow you to make gradual improvements to existing C++ programs by adding new non-C++ modules.
Related Stories
Techno-optimist and a free-speech advocate Daniel Lemire asks:
In an earlier blog post, I reported that the memory usage of a small byte array in Java (e.g., an array containing 4 bytes) was about 24 bytes. In other words: allocating small blocks of memory has substantial overhead.
What happens in C++?
To find out, I can try to allocate one million 4-byte arrays and look at the total memory usage of the process. Of course, the memory usage of the process will include some overhead unrelated to the 4-byte arrays, but we expect that such overhead will be relatively small.
Results are: GCC 8, Linux x86 - 32 bytes, LLVM 14, Apple aarch64 - 16 bytes. GitHub link to code he used.
Previously: Beyond C++: The promise of Rust, Carbon, and Cppfront
A long-standing coding choice has seen an unexpected rise in popularity, according to one tracker of programming languages:
Software-testing firm Tiobe, which maintains a monthly tracker of the popularity of the vast array of programming languages available to software developers, has picked C++ as its programming language of 2022.
Despite it being placed third in Tiobe's January 2023 index, the popularity of C++ rose faster than all other languages last year, up by 4.26% compared with January 2022, the company said.
Runners-up this year were C, the second most popular language, which grew in popularity by 3.82%, and Python, the top language, which grew by 2.78%. Having fallen from third, Java is now in fourth place, growing 1.55%.
[...] [Tiobe CEO Paul] Jensen also notes that C++ rival Rust entered the top 20 again (being ranked at number 26 one year ago), but says that "this time it seems to be for real", suggesting it could now hold a stable position in the top 20.
Rust's profile shot up during the past year after it was officially adopted for the Linux kernel version 6.1, clearing its way for drivers to be written in Rust.
Previously:
Ironically: It's Time to Stop Using C and C++ for New Projects, Says Microsoft Azure CTO
(Score: 1, Insightful) by Anonymous Coward on Thursday November 17 2022, @08:02AM (1 child)
... that is, so hard to find the C/C++ programmers to maintain the existing code base that getting one comes with a premium salary.
(Score: 5, Interesting) by JoeMerchant on Thursday November 17 2022, @12:00PM
Pssst... If you aren't a vulnerable young graduate, and have C++ skills, you can actually already demand premium salary. The trick is to walk away when they don't offer enough money.
The flip side of that situation is: once you have been making $150k+ for a few years, the $50k sweatshops can smell it in your LinkedIn job history and similar, and they won't hire you even if you would accept $50k. They usually say it's because they are afraid you will find a higher paying job and leave them, but with their typical 6 month turnover I think it's more that they don't want to start paying their programmers real money because it would upset the whole social hierarchy in the company. Pay programmers real money, programmer turnover slows down and productivity and quality go up, fewer programmers are required but the ones you have start to acquire seniority and power in their positions, maybe enough product knowledge to go out and launch a competing company, potentially even poached some or all of the sales staff. Bugs are less frequent so the whole support and upgrade dynamic with the customer base changes... It's a slippery slope and the only thing worse for manager / owners than hiring someone smarter than themselves is having that smarter person end up knowing more about their business and products than themselves.
All in all, even if the salary and benefits were exactly the same, you would rather work for the companies that pay more... It's just a better environment all around. But... Those better jobs can be harder to find since turnover is more in the range of 6+ years rather than 6- months.
My experience is my own, but in my experience the better employers have used C++ rather than the flavor of the day, probably due to that low turnover and long project life cycles. The best employers don't tell their software engineers what language they should use, they ask.
🌻🌻 [google.com]
(Score: 5, Interesting) by inertnet on Thursday November 17 2022, @08:38AM (7 children)
I've been reading the Rust docs recently and I'm impressed with the way it prevents you from coding many types of bugs at compile time. At 66 I'm not going to switch anymore, but if I did have a significant amount of coding years ahead of me, I'd switch to Rust in a heartbeat.
(Score: 5, Interesting) by Unixnut on Thursday November 17 2022, @11:27AM (6 children)
Really? I had a go at Rust recently and was less than impressed with some of the design decisions, and the ecosystem as a whole.
Probably the most egregious for me is the whole idea that you end each line with a semicolon, except the one that you want to be the return value.
I mean, you take one of the most common mistakes in semicolon delimited languages (missing semicolon), and you make it a valid statement.
So now if you forget the semicolon on a line, you don't get a syntax error. It is a valid statement, so not only do you not get an error at all, your program may well compile and run fine, but give the wrong output under certain circumstances.
You've gone and made a simple and easy to fix syntax error into a long winded debugging session to find out your software sometimes returns wrong output, why your software is giving wrong output, debugging until you realise it is a missing semicolon somewhere, and then trawling through the code to find the offending line.
Yeah, no thanks. Might give Go a try instead, hopefully that is better designed, but on the other hand maybe I should learn C++, as someone above mentioned, in future there may be lots of work maintaining old C++ code bases.
(Score: 5, Interesting) by JoeMerchant on Thursday November 17 2022, @12:19PM (2 children)
I can get used to quirks like weird semicolon rules, hell I have almost gotten used to meaningful indentation in Python (though I will NEVER grow to like it and believe that it needs special editor support to color the left margin of each indent group), but the real thing for me is the ecosystem.
Again with C++ vs Python, the Python libraries are written in C++/C so, defacto, anything you can do in Python you can do in C++. The reverse is far from true, and often I will find that the Python implementation of a particular feature, while simple to use, is not terribly powerful, lacking in options, and not always free of bugs, either. Things like thread support are often buggy (especially in the garbage collector, go figure...). So, if you are content playing in the safe and validated sandbox, then Python can be fine, but it does lack power that can translate into an inability to do things that are straightforward in C. And IMO, I would rather just program in C++ than spend my time and effort expanding the Python sandbox with some multiple language amalgamation.
With great power comes great responsibility. If you can't run with the big dogs, get happy staying on the porch.
🌻🌻 [google.com]
(Score: 2) by Thexalon on Thursday November 17 2022, @01:33PM (1 child)
It kinda is: Python comes with a C interface that allows you to write C code that will interact with Python. So if you're running into that sort of problem, you can do that 1 thing in C, and write the rest of your stuff in Python if you like.
The other thing that comes up often with this sort of thing is that if you're trying to do, say, pointer arithmetic, no you can't do that in Python ... because the thinking is that it's dangerous and not really necessary most of the time.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by JoeMerchant on Thursday November 17 2022, @03:50PM
In the Pi Pico environment, the established (community documented and supported) Python expansion process often involves direct memory set / memory read commands, reminiscent of POKE and PEEK in BASIC.
If using Thonny as the IDE to make Python applications for the Pi Pico, where is that C interface?
🌻🌻 [google.com]
(Score: 3, Interesting) by inertnet on Thursday November 17 2022, @01:55PM (1 child)
Actually, your objection is one of the reasons I decided not to switch, because it would give me too much irritation to get used to that behavior. Although you will be warned if you forget your return value. A precompiler statement that would require you to always specify return statements would be a good addition to Rust, because that would allow more people to get used to the language easier.
Go is a much easier language to learn in my opinion. It has its peculiarities, but they're not difficult to get used to.
(Score: 2) by HiThere on Thursday November 17 2022, @02:19PM
Interesting. The thing that I didn't like about Rust was the inadequate libraries. That will be fixed over time, but it's got a long way to go. But with Go what I found intolerable was it's rules for where the code should go to be compiled. C++ was a LOT easier.
OTOH, I do most of my programming in Python because of the speed of development, and since a lot of it is I/O bound there isn't much speed of execution difference.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Insightful) by dwilson on Friday November 18 2022, @01:35AM
Not a word of a lie, I read the quoted bit and thought, 'what the hell is he on about?'. Then I went and looked at src/main.c for a program I took over maintainership for some years back and have regularly been updating since.
..every line ends in a semi-colon. Of course it does, it's C. I knew that's how C works. I've known that for twenty years. I've been doing it so long I no longer think about it, to the point I read you talking about it and wondered what the hell you were talking about.
Not at all relevant to the discussion at hand, but it does make me marvel at the human brain and what it's capable. Sort of like the story of the dancing bear, it's not how well it dances that's amazing, it's that it can dance at all.
- D
(Score: 3, Interesting) by PiMuNu on Thursday November 17 2022, @09:57AM (17 children)
Anyone out there who can comment (and is not tied up in vested interests)?
Also, what about existing code bases in C/C++? Can they be migrated easily?
(Score: 2) by JoeMerchant on Thursday November 17 2022, @12:28PM (4 children)
I believe there was an article about a M$ C++ to Rust auto translation product. One logical question about such a translator is: does it translate the bugs too? How can it tell the difference between a bug and a feature?
🌻🌻 [google.com]
(Score: 2) by krishnoid on Friday November 18 2022, @02:59AM (3 children)
You can use a Github Copilot Labs [dev.to] feature to do the translation and see what it comes up with. In any case, it shouldn't (?) be able to translate stack-unsafe code from C++ to Rust because, well, Rust.
(Score: 2) by JoeMerchant on Friday November 18 2022, @03:37AM (2 children)
One might argue that any C++ code that a Rust auto-translator actually works on doesn't benefit from being translated to Rust.
🌻🌻 [google.com]
(Score: 3, Insightful) by krishnoid on Friday November 18 2022, @04:51AM (1 child)
One use case would be moving it to a language like Rust where it's impossible (?) to write memory-unsafe code even if you're not a great programmer in the first place, and can lean on the compiler/build system more to prevent those classes of issues. Haven't we been waiting decades for the tools to prevent (or at least advise against) security vulnerabilities/memory allocation failure vectors from being put into the code in the first place?
(Score: 3, Insightful) by JoeMerchant on Friday November 18 2022, @10:55AM
I do strongly prefer the advice mode rather than making some unsafe (and many more safe) things impossible to do within the framework.
I still feel that a well developed API over a well developed language and compiler is a preferable solution to the fresh sheet of paper approach.
Sometimes the old dogs can learn new tricks, but they have learned from the cats: what's the point, this isn't for me.
For the inexperienced programmers, give them compiler warnings. Maybe give certifications in pointer arithmetic without which those warnings become errors... We already have blame tracking, when a warned issue is found to be an error for a given programmer, create a report of all their recent past uses of that structure (still in production code) for review. If nothing else it would be excellent incentive to reduce un and under used code in the production codebase.
🌻🌻 [google.com]
(Score: 2) by Rich on Thursday November 17 2022, @01:48PM (10 children)
Background: I maintain a MacApp 3.1-like C++ framework and have, after ViewEdit, AdLib and IcePick dissolved in the internet's binary entropy, written a corresponding View Editor, which can still work on 'view' (3.0) resources (and in the meantime, with ResEdit having the same fate, ALRT/DLOG/DITL and MENU/CMNU, too...). Because the knowledge disappears from the internet: These are all GUI definitions from ancient days where "Mac OS" was still called "System". Just yesterday I have delivered its ARM 64-bit version to my customer. This is used to keep a very mature C++ codebase alive. The reason behind all this is that it's much easier to maintain a stable platform for the software suite, than to bring the software to a new (and possibly moving) platform with such product lifetimes. Let alone bringing all this to a new language.
In addition, Rust has no traditional inheritance model, avoids NULL pointers, has no exceptions, and furthermore assumes all memory allocations succeed (all programs crash on a failed allocation in an out-of-memory situation). The type safety model also forces (I have no actual experience with it) a design that it can verify as safe, which might not align with existing logic flow. I would also be worried (gut feeling only, no experience) that real-life mixing of C/C++ and Rust can create situations where Rust is no longer able to properly do its lifetime calculations when C/C++ is somewhere in-between.
Bottom line: From experience, I don't think an easy migration from C++ to Rust is possible with a codebase in classic C++ style. Rust seems to be great for small embedded stuff (think Arduino!), it might be somewhat suitable for system programming, but I think it's unsuitable for an object-oriented, document-based desktop software.
Conspiracy theory: The Rust propaganda is orchestrated by Microsoft to gain ground on low-level territory to eventually push Windows-dependent C# on top of that.
(Score: 2) by RamiK on Thursday November 17 2022, @02:31PM (6 children)
Rust and the rust-in-linux push came from Mozilla and Google: https://thenewstack.io/rust-in-the-linux-kernel/ [thenewstack.io]
compiling...
(Score: 3, Funny) by Rich on Thursday November 17 2022, @02:46PM (5 children)
Yeah, but Mozilla are still the bitch of anyone with money to pay for their pretty offices.
But I saw M$ also have Herb Sutter of C++ fame on their payroll.
Conspiracy theory: They pay him to come up with such complicated and confusing stuff that C++ users despair and want to switch away. ;)
(Score: 2) by RamiK on Thursday November 17 2022, @03:11PM (4 children)
They'll need to payoff literally every major company in the industry... Look, here, EuroRust was only two weeks ago so this is fairly representative of the scale of adoption going on right now and what's driving it: https://www.youtube.com/watch?v=ubXvKRbULuo [youtube.com]
compiling...
(Score: 2) by Rich on Thursday November 17 2022, @03:54PM (3 children)
Well, it's an advertisement campaign for Rust run by a company called "Mainmatter" (formerly called "simplabs"). That said, there must be a massive push behind it to get the infrastructure into place for production readiness. This is certainly driven by particular interests with deep pockets. If the merit of a language would matter, we'd all be writing in Vala now, with an LLVM backend, and the GNOME tribe having to rely on some Vala object system rather than the other way 'round.
(Score: 2) by RamiK on Thursday November 17 2022, @07:20PM (2 children)
It's an industry convention panel with developers who work with the language telling you first hand account on how they came across Rust and how it got adopted in their workplaces. The sponsors for the convention is listed on their site: https://eurorust.eu/ [eurorust.eu]
It's obviously positive and serves as promotion for both the panelists, sponsors and the panelists but you could say that about anything.
Vala isn't safe so it solves nothing of worth to the companies picking up Rust.
Besides, Gnome's raison d'etre was graphics-in-C so Vala is already pushing it.
compiling...
(Score: 2) by Rich on Thursday November 17 2022, @08:23PM (1 child)
I have to stand corrected. They have no array bounds checks and one needs to rely on stuff like ArrayList. Not much of a practical issue, but allowing unsafe access without safeguards formally brings them back into C++ territory.
Gnome's raison d'etre was that Qt hat an unacceptable license. And to have Icaza poison the well with Midnight Commander, Gnumeric, and Evolution which brought in the worst Microsoft-isms this side of Clippy and the Ribbon.
(Score: 2) by RamiK on Thursday November 17 2022, @10:06PM
Qt was released under GPLv2 since 2000 so you can only say it was a license thing for about 2 years. Regardless, they could have just used FLTK or TK for that matter which were available under free licensed.
But to be fair, you're right that the C-vs-C++ isn't really it. The real reason it was personal feuds and rivalries and need-in-house... Still, that too wasn't a 20 years worth thing so out of all the reasons why the world needs both Qt and Gnome around, the only reason I can come up with is that it's a C-vs-C++ thing.
compiling...
(Score: 5, Interesting) by PiMuNu on Thursday November 17 2022, @02:31PM (2 children)
> all programs crash on a failed allocation in an out-of-memory situation
> no traditional inheritance model
> has no exceptions
Migration aside, that all raises warnings for me. These sort of things are pretty basic functionality. In particular, not handling bad memory allocation breaks the "this thing sorts out all the C++ memory issues" that Rust is supposed to deliver.
> Conspiracy theory
One wonders what they have on Torvalds... I think his canary died a few years back, right?
(Score: 2) by Rich on Thursday November 17 2022, @03:07PM
Reminds me of the wise saying on a note for the cardio classes in my gym: "When your heart stops beating, you no longer have back pain."
Rust just promises a zero overhead solution for the "leaky & dangly" pointer issues. Manual allocation can leak and dangle, Ref counting has handling overhead and can leak cycles, Garbage collection has interruption overhead that breaks real-time. Rust tries to auto-infer the lifetime of things, with some extra annotations.
The out-of-memory behaviour is more a thing of the missing exceptions. Swift was the original hipster language, they started without exceptions, too, but eventually had to give in and add them.
(Score: 2) by isj on Thursday November 17 2022, @06:06PM
That raised my eyebrows. It's a simple error-handling technique that can work for some programs, eg command-line programs, or programs that run in a HA setup. But having working on must-not-fail programs for 15 years I dislike that Rust doesn't even give you another option.
(Score: 5, Insightful) by SomeRandomGeek on Thursday November 17 2022, @05:38PM
I've written a few small things in Rust, although not professionally.
The main thing to remember about Rust is that, like C and C++, it is a low level language. So, you are going to have to deal with annoying low level stuff like dangling pointers and memory leaks. Where Rust differs from C and C++ is that it checks these things at compile time. So, that annoying memory leak you could never quite figure out: Your Rust program won't even compile until you fix it. For example, in C/C++ it is common to pass pointers as function arguments and have comments specifying whether the caller or callee is responsible for freeing the pointer. And if you get it wrong memory leaks, or gets freed twice. In Rust, you have to tell the compiler whether the caller or callee is responsible for freeing the pointer, and it won't compile until that pointer gets freed exactly once.
This tends to drive opposite reactions from people who try to use it. For people who don't code C/C++ or who do it poorly, there are all these extra restrictions, making it much harder to do anything. For people who do code C/C++, they have all the same restrictions as before, so no change there. But now they have tooling support at compile time instead of having to figure it all out at run time.
(Score: 5, Funny) by Rich on Thursday November 17 2022, @02:39PM (1 child)
These hipster languages all start functions with "fn" and designate the result with an arrow "->". Also common to them is a wild aggregation of ASCII special characters to mark up declarations and they inevitably use curly braces to document they want the market power of C. They clearly come from the same mindset.
I'm fear that these all solve the wrong problems, and that we could get away with a careful overhaul of C itself - including a good set of coherent libraries that comes with the compiler.
(Score: 3, Insightful) by PiMuNu on Thursday November 17 2022, @03:14PM
std::shared_ptr and std::dynamic_cast seem to fix most of the problems that Rust wants to fix - without having to rewrite the existing code base. In fact we learn Rust can't support std::dynamic_cast because there is no inheritance model!
(Score: 5, Touché) by turgid on Thursday November 17 2022, @03:22PM (2 children)
All languages aspire to Lisp. Cut out the middle man, I say.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by istartedi on Thursday November 17 2022, @07:13PM (1 child)
Yes and no. Rust aspires to "systems programming" that can go "close to the metal". Requiring things like call/cc in that environment is performance suicide. So is dynamic typing, although I'm sure there's a type annotated Lisp out there somewhere it goes against the spirit of the language. Linus even rejected C++ in the kernel for the comparatively benign problem of exceptions and stack unwinding. Even advanced incremental garbage collectors probably don't belong in a kernel.
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by hendrikboom on Saturday November 19 2022, @02:21AM
Yes, there is a type-annotated dialect of Lisp: Typed [racket-lang.org] Racket?/a>. [racket-lang.org]
It's a variant of Scheme.
(Score: -1, Flamebait) by Anonymous Coward on Thursday November 17 2022, @05:17PM
Rust is for people not skilled enough to code in a proper language. It allows them to find work other than janitorial.
(Score: 0, Offtopic) by Anonymous Coward on Thursday November 17 2022, @08:12PM (1 child)
The people who say "everyone should program in <insert flavour of the week> instead of C" always seem to miss the actual reason C is used everywhere.
C is used everywhere for one simple reason: C compilers are everywhere. C compilers are everywhere for another simple reason: C is easy to implement (and, thanks to the network effect, C compilers are more desirable to have than other languages that are easy to imlement). Pretty much without exception, if a chip is programmable then there is a C compiler that targets it.
If you want to write software that can be ported to anything, you pretty much have no other choice. It has to be C.
In my day job, literally none of the computers I write programs for have Rust compilers. They all have C compilers. The Rust guys need to fix that first before they can reasonably start suggesting that we should all stop programming in C and start programming in Rust.
(Score: 2, Touché) by DrXenos on Thursday November 17 2022, @11:57PM
The article is about C++, not C. They are two different languages.