Hacker News Reader

Comment by titzer | Hacker News Reader

While I know and respect many people who have worked on C++ and contributed to it, we need to move on from it. The gaslighting from certain vocal proponents of C++ has been a major stumbling block for the industry as a whole to move on to using memory safe languages in critical software layers.

It was never a good idea to use a performance-oriented language for software that should have had its highest priority as security, and it will be remembered in the long tail of history in the same way that asbestos is: a hazardous material that took us a long time to rid ourselves of.

View on HN

I think JF's recent CppNow talk was excellent in this regard.

Particularly his wording: dereliction of duty

https://youtu.be/Gh79wcGJdTg?si=sDUart8rXTCzERA_

> While I know and respect many people who have worked on C++ and contributed to it, we need to move on from it.

This has largely happened already. Java is in fact a memory safe language which has replaced a whole lot of C++ code since the late 1990s. It's only in a few highly performance-oriented areas where the debate ("should we be replacing C++ with a memory safe language?") is still undecided.

Java may be memory safe, but errors in highly expressive functionality like Java serialization and expression parsers have been responsible for some of the most impactful vulnerabilities in recent memory.

CVE-2017-5638 was famously exploited to gain access to Equifax's network and cause a massive data breach. Log4Shell is continuing to cause problems in all kinds of networks due to the extremely widespread use of the Log4j library. Java is definitely an upgrade over C/C++, but there are definitely still security risks.

When we eliminate 70% of CVE, it doesn't mean the remaining 30% shouldn't be taken care of.

So then memory safety isn't the end-all be-all for security anyways. What do you suggest we use instead?

Ada?

Ada/SPARK

Coq

That is not the case in my experience. There are still plenty of C++ codebases that don't need the extra performance over something like Java or care about GC pauses.

C++ continues to be popular because it's a powerful language and can easily integrate with a ton of libraries, and most people don't care much about security.

> we need to move on from it

Agree. However, we need to solve the problem from the supply side (create more and better Rusts, Gos, Zigs, etc. so that people choose to use them), not from the demand side (shame people into adopting Rust).

I think there is a significant portion of developers that want to leave C++ for a better language, but for different reasons may not be satisfied with Rust or Go, so they just stay on C++.

What's wrong with Python, Java, C#, etc? Conversely, while better at avoiding footguns than C, Zig doesn't provide quite the same memory safety - although to be fair, better is still worth it.

Security is not the only dimension that matters, resource efficiency and scalability matter too. A big driver in the use of C++ is that it is more efficient than Python, Java, etc by an integer factor in real workloads. No one wants to increase data center sizes by 4x (or more) to run the same workload. Being that wasteful isn't environmentally friendly.

> No one wants to increase data center sizes by 4x (or more) to run the same workload

1000 C++ servers vs. 100,000 Python servers is a big reason to avoid Python.

Some performance critical software cannot afford garbage collection.

Which is why Apple put GC in Objective C and then removed to and Swift does reference counting.

To keep iPhone apps responsive, they saw problems with apps using GC.

Not at all.

They removed tracing GC from Objective-C, because it was a failure when dealing with C semantics.

Automating retain/release calls was a much easier and safer approach, hence plan B.

In any case, reference counting is a GC algorithm.

I am certain that one of the reasons Swift uses reference counting is to achieve more predictable performance and to avoid the GC pauses that plague Java etc.

Another may be that it simplifies the runtime for system code such as kernels and device drivers.

It's not just that, reference counting is friendlier to non-uniform memory access, which is what you have on a system with swap and/or memory compression. In compacting GC, the compacting part can help here, but the GC part doesn't.

But people do use GC on their phones, insofar as they like to use web browsers.

Swift uses reference counting, because it interoperates with the Objective-C runtime, duh.

.NET interop with COM is a good example of how mixing a tracing GC with a reference counted runtime requires an higher engineering budget that Swift team most likely wasn't willing to spend resources on.

It has been proven multiple times that reference counting is slower and has performance issues when dealing with large graphs, and also stop-the-world issues when cascade deletions occur.

If only pro-RC folks would bother to read CS papers and benchmarks.

More like peak memory use is higher with GC than RC and they wanted to avoid having to put twice the RAM in iPhones.

I really don't see what issues there are with rust that could be addressed by another language without compromise on the performance and memory safety axes.

I can think of two reasons for people not moving: 1. inertia, aka "not going out of comfort zone to learn new things" ("learning" includes understanding why things are different, not merely knowing they are). This won't be addressed by another new language that people will also need to learn.

2. Existing codebases won't magically turn from C++ to Rust. Legacy is actually a good reason to still be using C++ today, but another language also won't address this, as the fundamental issue is you can't change the existing code to be safer without effort.

In both cases, time and effort on the language best positioned to replace C++ (Rust) will alleviate these issues. In particular this effort could be spent to fully close the feature gap with C++ (specialization, more expressive consts, ...) and improving Rust/C++ interoperability.

No need to "shame" people, but finding a way to replace C++ use by Rust use is how we will solve the problem.

There are definitely other ways to solve memory safety than the Rust approach. Check out Koka, Project Verona, Hylo and Vale.

All of those are currently at the research project stage, so Rust is really the only game in town to replace C++ at the moment.

There's too much friction for Rust to be the solution, unless there are drastic changes in the near future. None of Vulkan, Metal, GTK, Qt, Cocoa, Android, iOS, or Wayland have official Rust support, and maintaining the boundary is a non-trivial task.

My gut feeling is that a different language with less friction will gain more traction.

"None of <list of enormous ancient systems> have official support for <new language>"

I think that is a reductive dismissal of a real problem. Rust is intended as a C++ replacement, but interfacing to existing C and C++ code can be very messy, it’s not just simple language bindings. What I’m suggesting is that the work needs to be spread out or it’s not likely to happen.

C is fairly effortless, but I agree C++ could be better.

But hardly any languages integrate with C++ very well. Have you ever used SWIG? (Shudder...)

I do agree it would be nice if it could. The cxx crate is ok but we could do a lot more.

Maybe something like SWIG but based on LLVM so it actually works properly.

As long as the Rust community doesn’t fuck up Rust, it looks like that transition, and more importantly the broad recognition of its necessity and feasibility, is well underway.

not picking on it specifically but I just recently saw that flatpak is written in C as well despite the fact that it was released just eight years ago. Red Hat is one of the companies that also has a strange C addiction for almost anything.

There's pretty much no reason to not use a memory safe, performant language like Go at this point for infrastructure-ish software.

Red Hat should switch to Zig.

But Red Hat and Rust just Roll off the tongue

Or Red Hat and Red Lang [0]

[0] https://www.red-lang.org/

Go is tough to get approved in certain Red Hat markets. Simply because it calls out to github for packages without an audit tool. A lot of finance companies have blocked the use of Golang because of that. Totally fine with Java and their own Nexus. Same with Javascript and their own NPM on Nexus. But they can't see past `go get github.com...`

When they totally could be doing `go get sources.redhat.com...`

Go has a thing for that now- everything goes through a proxy (https://proxy.golang.org), and if you set GO_PROXY, you can send it through your proxy (Nexus et al).

I don't know for Go case how it would work, but what I saw in case of Maven is it's company wide blocked and you have to get your packages through Sonatype Nexus - and Nexus either has it's own packages or it has a proxy for Maven packages. So I wonder in case of Go, if it would be unfeasible to block GitHub so they would just block the entire use of the language in company developed software.

exactly. If you block go packages via firewall IT rules, you block github.com software engineering work. It's the one thing I think that's holding Golang back. Deno as well. I know it looks novel but it's a security nightmare.

Blocking the official Google Go proxy will work pretty well, go get will just fail by default.

If someone works around that on a developer machine, it shouldn't matter, because release builds should still come from an automated system, right?

yeah, go modules have streamlined golang development so much. Providing a custom domain configuration on your site allows go to grab the code vs a user visiting it in their browser.

The audit tool is go.sum

>not picking on it specifically but I just recently saw that flatpak is written in C as well despite the fact that it was released just eight years ago.

You say "just 8 years ago" but another way of phrasing that would be "only 4 months after Rust went 1.0". And that's the first release, which means work probably started before Rust went 1.0

>Red Hat is one of the companies that also has a strange C addiction for almost anything.

This is kinda true and I wish it was different, but most of the examples people bring up are ones like the one you brought up. Rust wasn't a "safe choice" at the time they were started.

There's other factors too, like needing to support POWER and Z architectures. If you have a lot of such products written in C, and you have a GCC toolchain team in-house, that's not so difficult. If you have a lot of such products written in Rust, and your LLVM toolchain team is much smaller and the compiler itself less mature on those platforms, it's a bit more challenging. And then the whole issue of dynamic vs. static linking, where there's a ton of organizational inertia in favor of the former.

All that said I think the list of valid excuses is increasingly small nowadays.

C was my first love as an adult programmer. I still enjoy its economy and expressiveness, even though I've written no production code in it for over a decade. So it saddens me, but I agree: it's time to retire C and C++, and put some serious work into migrating security/safety critical codebases to more robust languages.

This take is not helpful imo

Truth is often uncomfortable.

Perhaps. But not everything uncomfortable is truth.

You sound like you're using the uncomfortableness as evidence of the truthfulness. Logical inference doesn't work like that.

Reply on news.ycombinator.com