Hacker News Reader

Comment by acdha | Hacker News Reader

The author works on Google Chrome so I'm pretty sure they're familiar with the pros and cons of C++. It's possible that there's a place for using C++ on a new project in 2019 but that would definitely be a decision to justify with a comprehensive process for mitigating the risks of not using e.g. Rust.

View on HN

Although on HN it looks like there's some kind of competition happening, Rust is a rounding error compared to languages like Java, C# or even Swift which are actually chosen instead of C++ for many projects.

I'm looking at job ads periodically and Rust is almost not at all present. I've talked to someone from the Rust community and they told me that "many" companies are using Rust, but not advertising it and not hiring for it on public channels.

Whatever the reason, the Rust skills market seems to be non-existent, which is a bad position to be in when considering whether to start a project in Rust. Project = commercial product that makes money, not OSS or start-up dreams.

The subtext of Rust in posts like this is that Rust compiles programs that are pin-compatible with C/C++ programs. Without rethinking the architecture of a kernel, for instance, you're meant to be able to write Rust drivers.

I prefer other higher-level languages to Rust; I'd rather just work with garbage collection than wrangle the Rust borrow-checker. But if you need to write software that can't abide GC, Rust is basically the only memory-safe game in town.

nickp mentioned some alternatives, basically verified C or model-driven development for cases where it really matters.

Anyway, if we stick to standard commercial projects, I'd say the languages I enumerated are solid C++ (and Rust) competitors, because C++ at least isn't used to develop only super-performant or low-level bit twiddling SW, and I don't see why Rust would be either.

Obj-C was a solid C++ competitor on anything Apple and now Swift maybe even more so. It's a great language that can get you 95% there and I can almost guarantee that the remaining 5% won't be Rust, but rather C or C++.

Same goes more or less for Android with Java or Kotlin. Having a GC didn't stop them from becoming the platform standard, despite the embarassing growing pains they had.

It's really a game of platforms. Almost no one would pick a language because it's memory-safe, it's just a standard feature for most kinds of software developed nowadays.

For the SW where Rust and C++ would both be good fit (gaming?, audio, video, etc), C++ is entrenched and it's very unlikely that companies will have to justify using it instead of Rust in 2019 or 2020, erc when it's already the default in the first place.

A hard lesson I took from my experience with Turbo Pascal, Oberon and others, is that platform languages always win in the end.

Better syntax, improved semantics are nice, but if the debugging experience, IDE tooling and integration with platform libraries take a hit, then in the long run, the improvements aren't really worthwile.

However, given that Google (Fuchsia), Microsoft (IoT Core, Azure), Oracle (railcar), Amazon (Firecracker) are testing waters with Rust, I guess it might eventually become a blessed language in some of their systems.

But it will take time for sure, specially regarding tooling parity.

I’ve been trying to correct my instincts from that era for the success of open source. It’s a lot easier now to collaborate, especially without things licensing, and the tools built around things like LLVM seem like a significant shift for the costs of a non-default language.

Not really, you just need to have a look at Android, as open source platform.

Java is the platform language, followed by Kotlin, which even with all Google love of latest, there are still a few corner cases where it isn't 1:1 with Java on the platform.

Finally there is C++, which comes on 3rd, with lots of caveats given the NDK evolution and integration into Studio.

Anything else brings their own set of problems, the headache of having the NDK as entry point into Android and JNI as FFI for Android APIs.

I’m not saying it’s easy now, just easier. Thinking back to the TurboPascal/Delphi era you had to convince people to make a large purchase, and your team had to spend a non-trivial amount of time dealing with compiler code generation, debuggers, and a wide range of less compatible operating systems (when I worked for a compiler vendor, our QA test matrix was ~600 different OS & CPU combinations). That’s a lot to fund out of a smaller revenue stream.

Although I like Rust for those scenarios where GC isn't an option, I bet Ada/SPARK still have more commercial deployments out there.

It might change given the price of their compilers versus free rustc, however those are industries that also certify compilers, which isn't going to happen for the time being for Rust toolchains.

Also Rust still isn't pin-compatible with COM/UWP or Objective-C runtime, and I guess we need to wait around one year until mixed language debugging experience is a thing across all major IDEs.

> Although I like Rust for those scenarios where GC isn't an option, I bet Ada/SPARK still have more commercial deployments out there.

I doubt it, if you're counting users. Hundreds of millions of users of Firefox and Dropbox, just to name the first two that come to mind, use Rust code.

> Also Rust still isn't pin-compatible with COM/UWP or Objective-C runtime

What? Of course it is. We're shipping Rust code that uses COM and Objective-C in Firefox beta, right now (WebRender).

Of course statistics is the art to make the numbers how we like them to be.

On my case I am counting systems in production.

Using COM is a tiny portion of COM development experience.

Where is the Rust support for creating COM and UWP components, including mixed mode debugging on Windows IDEs, likewise for Objective-C integration.

If I missed that, where can I find more about it?

Again, we ship COM components. You can't load local fonts on all versions of DirectWrite without that.

Likewise, Rust has had support for creating Objective-C classes with methods written in Rust for ages. You can't usefully render OpenGL into a window on macOS without doing that.

In that case it would be nice to actually answer my question.

> If I missed that, where can I find more about it?

How do COM type libraries get generated in Rust?

> Also Rust still isn't pin-compatible with COM/UWP or Objective-C runtime

Both COM and Objective-C can be accessed from C, and Rust is compatible with the C FFI.

Since Windows 3.x days actually, but only by those masochist enough to use the C API, or low level OS devs on the respective companies.

Anyone else that praises productivity uses programming languages that take care of the lowlevel boilerplate, and offer high level debugging experience on the respective IDEs.

> Also Rust still isn't pin-compatible with COM/UWP or Objective-C runtime

I found this: https://github.com/SSheldon/rust-objc/

How does it integrate with XCode or AppCode debugging experience, code generation and UI designers?

Debugging works just fine. Cross-language debugging in Xcode even works, because LLVM generates the debug info.

And designing a Core Data model in Rust?

Implementing an XPC server or an IO Kit driver?

Writing Metal shaders?

These are the kinds of issues that I am referring to.

Compile to a static library and drag it into the Xcode sidebar?

What about generating a Core Data model in Rust?

> ...Rust is basically the only memory-safe game in town.

How about thread safety? Are there other thread safe games in town?

As far as I know, only the Pony Programming Language[0] statically ensures identical guarantees as Rust, but it is not 1.0 and the community is tiny. Pony takes a wildly different approach to achieving those guarantees though - and it's more geared towards highly concurrent servers rather than the wide spectrum of programming domains that Rust embodies (embedded, systems, etc). It uses actor-based concurrency, is AOT compiled, has a concurrent GC without stop-the-world collection and ships with a "cache-aware, work-stealing scheduler" runtime. Similarly steep learning curve as Rust with its Reference Capabilities which is Pony's equivalent to Rust's ownership & borrow checker.

[0]: https://www.ponylang.io/discover/

As someone currently looking for a job with Rust, there are tons of opportunities out there. I am obviously a bit of a special case, but I’ve had probably forty inquiries so far, from several FAANGs, YC startups, and others. There's enough that even though there are some places that didn't reach out and that I know are using Rust, I haven't had the time to apply myself.

It is true that there’s no nearly as many as Java or C++, but that’s pretty normal given relative ages.

Yeah, you might be a special case. Wouldn't be surprised if there were dozens of companies in total using Rust and you got contacted by most of them.

I'm also looking in Europe, not US.

I think one of the January Who's Hiring jobs was a company doing Rust, but looking for onsite in Berlin or remote in europe. Maybe one in London as well.

I'd like to end up in Berlin in the near future, so I hear you there. Some of them do require being in the US, it's true.

I mean, you really are a special case - I have only lightly dabbled in Rust, but I immediately recognize your name because of the work you've done in the Rust community.

If you want an easy time finding a job, Java or Javascript will definitely accomplish that.

It is not however impossible to find jobs in Rust at the moment. I think January's Who is Hiring post had 5 rust job listings. Rust is still not used in a wide range of industries, but you can find a number of opportunities in crypto, fintech, security, and even a few big data shops.

And yes, there's even more jobs that aren't always out there on public channels. Good reason to attend your local rust meetup.

> when considering whether to start a project in Rust. Project = commercial product that makes money, not OSS or start-up dreams

How do you know whether the commercial product is going to make money when you're still considering what programming language to write it in? Until it's built and launched, it's just a "commercial product dream", similar to a "start-up dream".

That’s true in general but what I was referring to are the subset of new projects where someone would pick C++ instead of Java, C#, Go, etc. The latter are definitely more popular in general and I’d expect there to be far more cases where they’d be selected, so rejecting them for technical reasons would tend to bring you into areas like not using a runtime or GC.

If you have the luxury of choosing between C++ and Java/C#, then you don't need C++.

Well if you're starting a project now that you expect to live for many years, there's the issue of C++ safety now, and C++ safety in the foreseeable future.

Right now projects have the option of building with the santizers (particularly the address sanitizer) enabled, right? The executable would be slower and less memory efficient, but it would eliminate most of the critical CVEs that exploit invalid memory access. Is there a reason Google couldn't provide alternative builds of Chrome with the santizers enabled?

As for the foreseeable future, you can come up with arguments (convincing or otherwise) that C++ will be effectively memory (and data race) safe in the foreseeable future. At some point, presumably the core guidelines lifetime checker will enforce memory safety. To what degree it will in practice is a matter of speculation, but in theory it could be as effective as the Rust compiler.

Just as an observation, if you peruse the chromium source code, from a modern C++ perspective, there seems to me to be an alarming prevalence of raw pointers. (Probably understandable as chromium's been around for a while.) C++ is now a very powerful language, and if (memory) safety is a priority it is already practical (and performant[1]) to avoid the use of notoriously unsafe elements like raw pointers and unchecked buffers in favor of safer alternatives. (It is similarly practical to avoid data race prone elements[2].)

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...

[2] https://github.com/duneroadrunner/SaferCPlusPlus#multithread...

Reply on news.ycombinator.com