Hacker News new | ask | show | jobs
by stormbrew 1366 days ago
The thing is that C is still the lingua franca abi, so there's still no need to rewrite in bulk, you can still just use the same C libraries in another language, and rust is particularly well suited to doing that in roughly the same ways C++ is.

What's getting harder and harder to see now is why, if you need to write new or rewrite now, you'd choose C++ over rust. In the long run that's a recipe for only the most gnarly old codebases being written in c++ and no one wanting to touch them.

2 comments

> The thing is that C is still the lingua franca abi, so there's still no need to rewrite in bulk, you can still just use the same C libraries in another language

No. C is the lingua franca for exported public stable ABIs, which is an extremely small subset of any given program's ABI usages.

C++ ABI is just as widely used as C's, just for internal unstable linkage instead of stable exported linkage. So yes you still need to rewrite in bulk to move off of C++, unless your code happened to be tiny & only used C API libraries.

We're starting new projects today, in 2022. (We do Signal Processing code for the Position, Navigation, and Time industry.)

It's all C and C++, and Python if we need a scripting front-end. (Prototypes are done in matlab). "Rust" doesn't even exist in our universe. I don't think the people on HN are really in touch with how real people program in the real world.

And on few the occasions when we have to do a complex desktop GUI app, we'll use C# or F#. We can get cross-platform Windows/Linux easily this way.

Rust is still fringe even at FAANG level companies. I work at one such and we have a service or two written in Rust. I like Rust as a C++ replacement in the right context, but for 99.999% of applications it’s not better in any qualitative or quantitative way than C++. Or Java. Or Go.
> Rust is still fringe even at FAANG level companies.

Yes, everyone knows that, except for HN users! While I'm sure there are managers at large companies who let some employees play with Rust, it's not used.

I mean, I'm a HN user who just left one FAANG for another and I'm pretty confident this is changing a lot faster than you think.

The thing that obscures this, I think, is that at most of them the surface area that the intersection of C, C++, and Rust that is high availability, security critical software, makes up a relatively small portion of what they do no matter what language it's in.

So while there's a lot of C++ at say, Google and Facebook (but relatively little at Apple IME), very little of it needs to be in c++ let alone Rust.

But where it matters? You better believe big companies are shifting towards "if you're starting new you should seriously consider Rust" (if not a mandate). And once you let one other language into your mix, the question becomes: why's all the high level stuff written in c++? May as well start new projects in Go.

Some are farther along than others but it's a thing.

There is a lot of C++ at Apple. It's of course possible to work there and never touch it, but it's also possible to work there and do almost all your work in C++. Many significant parts of iOS and macOS are written in C++, for example WebKit, the implementations of ObjC and Swift, clang/llvm, dyld, CoreAudio, CoreAnimation, WindowServer, Dock, Finder, etc.

I enjoy this[1] annual series of blog posts on Apple's usage of Swift in iOS. I just did a quick and dirty, but similar analysis of Apple's usage of C++ of the macOS 12.5.1 install on my computer. I extracted my dyld_shared_cache, and then used find and nm to count up binaries containing unstripped C++ symbols. This undercounts the usage of C++, since sometimes it's used only internally in stripped binaries, and I also think the number of binaries metric probably undercounts the importance of C++ because the ones that do use C++ tend to be more significant binaries, but even still it gives some idea of the scope of C++'s use at Apple.

About 25% (559 / 2292) of the libraries in the dyld_shared_cache contain unstripped C++ symbols. About 15% (22 / 154) of executables in /System/Applications (so 1st party apps / helpers that ship with the system) do.

That said, I think you're probably right that things are changing. Probably there are lots of people at Apple thinking of how they can replace C++ with Swift in their code. But on the other hand, I would not be surprised if we can still find significant uses of C++ in whatever macOS release we have 10 years from now.

[1] https://blog.timac.org/2021/1219-state-of-swift-and-swiftui-...

To clarify: Relative to Google and Facebook, which have built up immense c++ codebases that span the entire companies.

I spent 8 years at Apple, mostly working in C and then rust, both even smaller pieces of the Apple language pie.

But I also did a little c++. I have commits in swift for eg (though I wasn't on the team and they were pre-oss, so you'd have to dig real deep to find them now).

Most of the services side of the company, which is where I was, was java ime. A lot of shift to Go in the last few years though. And that's a very quickly growing part of the company where you can't do a local check to find out language use. It's also the only part where rust is viable, because the product side of the company has much stricter limitations on what they'll build for distribution and as of when I'd left, adding rust to that mix was not even on the radar there.

But the places where rust was gaining were small but important, which is the main thrust of what I was saying.

But anyways, with how siloed apple is experiences can differ a lot, even beyond normal for bigcorps. :/

The number of teams at these companies where “you should seriously consider Rust” is a thing is approximately (not exactly) zero. Its adoption is still a novelty, and most of the impetus behind it is engineers looking to scratch an itch without any legitimate analysis of the benefits or trade-offs involved.

It may be changing, but certainly not faster than I’ve observed (it’s not a matter of speculation, for me).

But the world isn't FAANG. There are thouasands of other companies doing interesting things.
I didn't say it was? We're talking about faang in this sub thread.
> I don't think the people on HN are really in touch with how real people program in the real world.

I mean, I’m a real programmer in the real world. I think most people on here are. Rust is already in heavy use at Microsoft, Amazon, and Google, it’s not some fringe thing anymore.

I have worked at two of the companies you’ve mentioned, and I can confirm Rust is not heavily used in these companies. Maybe a few teams use it, but it’s not really supported, and you won’t find many internal libraries and tooling support for it.
They’re using it to write useful, novel production systems software though. Fuchsia is in Google Nest Hub, AWS Firecracker is used in ECS Fargate and fly.io. I would say those represent major commitments to the language, and they’re both also novel as systems projects too.
How do you write GUI apps in C# with Win/Linux support? Usually people don't go C# if they're doing GUI on other things than Windows. CLI/Server software is a first class citizen on Linux these days though.
There are many ways!

https://halfblood.pro/the-story-about-net-cross-platform-ui-...

I like to use Xaml. For iOS/Android there are solutions, too.

A lot of companies started with Java or Go, and will consider Rust without ever touching C++. The stigma alone is enough to turn people off.

Hell it's going into the kernel in 6.1.

C++ runs a real risk of surviving only in the embedded/realtime space in the next 10 years.

10 years? That feels too short.

C++ is all the operating systems and the browsers and the games and the JVM.

> The stigma alone is enough to turn people off.

C++ has been hated for decades now. The reason it's used is often because you have to.

> C++ runs a real risk of surviving only in the embedded/realtime space in the next 10 years.

Ten years from now C++ will still be the language underpinning LLVM, web browsers, geometric modeling, machine learning, etc

Rust means you don't have to anymore. While the old software codebases will keep using it, the new ones won't.
> C++ runs a real risk of surviving only in the embedded/realtime space in the next 10 years.

Embedded/realtime? No way. The people I know in embedded won't touch C++ with your 10 foot pole.

Most of my embedded code is wrangling various "stacks" into cooperation with one another, and C++ helps me not one whit with that. At the other side, when I'm just poking sensors, C is more than enough.

And, as much I would really like embedded communication stacks to be in Rust, all that would happen would be the vendors slapping "unsafe" on everything so they would basically be writing C anyway.

More or less this. “Unsafe” as a value proposition loses its luster when it’s ubiquitous in a code base.