Hacker News Reader

Hacker News

Comment by Voultapher | Hacker News Reader

Parent Full thread

Voultapher

> It will never be perfect, but every little improvement helps.

Or it might convince people to stay longer on a plane with a provably [0] terrible safety record.

[0] https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...

View on HN

To put matters into perspective, Rust reference implementations depend on C++ toolchains.

Same applies to all major Ada, Java, .NET, Swift, Ocaml and Haskell implementations. And any GPGPU toolchain.

Which kind of shows it isn't going anywhere and those planes have to be improved no matter what.

As an addendum, the same goes for many C toolchains. Anything requiring GCC 4.8 or later is depending on a C++ compiler. And projects like LLVM’s libc, Fuchsia’s Zircon kernel, the bareflank hypervisor, etc, demonstrate that C++ really can be used anywhere C is used.

C++ is the new C in the sense that it’s the language everything else is built on and I expect it will be even more difficult to displace than C. For instance, the complexity of C++ makes it next to impossible to incrementally rewrite in another language, simply writing a production quality C++ implementation is a gargantuan investment so a superset language is questionable, and the C++ community is committed to evolving and improving their language whereas C has largely ossified. Perhaps C will outlive everyone reading this thread, but C++ will outlive C.

> C++ really can be used anywhere C is used.

Kind of what I have been preaching since 1993, as I adopted C++ into my toolbox, and had some fun on Usenet on C vs C++ flamewars.

It was with some vindication that I celebrated when all major C compilers eventually transitioned to C++.

I agree these planes are important and deserve care. At the same time pretty much all suggestions on how to meaningfully improve the safety of those planes boil down to successor languages Cpp2, Carbon etc. or require some other complex manual rewrite of components of said plane. There is an argument to be made for having good out-of-the-box interoperability, however even in some of the most complex and important code-bases in existence, namely browsers Firefox and Chrome, have demonstrated that you can do that part replacement in Rust. I'm not saying there is no other way. But these suggested and yet unproven improvements to C++ will not automatically make those planes safer. They will require replacing parts with new code, and if we are writing new code there is a serious question we should ask ourselves, building on what foundation do we want to improve those "planes".

The second someone makes a successor language that seamlessly/directly interops with C++ _AND_ has the level of build/IDE tooling that C++/Rust have, I'm on board.

The closest thing right now is Sean Baxter's "Circle" compiler in "Carbon" mode IMO:

https://github.com/seanbaxter/circle/blob/master/new-circle/...

Unfortunately, Circle is closed-source and there's no LSP or other tooling to make the authoring experience nice.

I also see Circle as the most promisor C++ wannabe, from all the contenders, and it being closed-source, once upon a time all major compilers were, so lets see.

Rust in Firefox is a very tiny portion of it and now they are using some WASM sandbox tricks, because they aren't going to rewrite everything in Rust, given the effort.

Chrome only now started to consider to allow adding Rust, and it is baby steps, not coming close to V8, graphics engine and such.

"very tiny portion" that's a gross misrepresentation. Rust sits at ~10% and C++ at ~27% https://4e6.github.io/firefox-lang-stats/.

Since when is 10% big?

Rust has been bootstrapped for nearly a decade. The rust reference toolchain is built in rust.

if you pretend that LLVM and friends are not part of the toolchain

So no need for LLVM and GCC, Great news!

Where can we download it?

Assuming you are serious, there is https://github.com/bytecodealliance/wasmtime/tree/main/crane... which is written in Rust and is targeted to become the default debug backend in rustc. LLVM has accumulated a lot of optimizations contributed by various groups and people over more than a decade. It's hard to catch up to that by virtue of resource limits.

I was being sarcastic, when Cranelift becomes the official reference implementation then I shut up.

Is there a reason to replace LLVM? Are there still memory bugs that are popping up and causing issues?

https://github.com/bytecodealliance/wasmtime/blob/main/crane...

Reply on news.ycombinator.com