Hacker News Reader

Comment by Xylakant | Hacker News Reader

Essentially, this has been Rusts value proposition from the outset - build a language that you can integrate into other codebases seamlessly, hence the choice of no runtime, no garbage collector etc. Bindgen (https://github.com/rust-lang/rust-bindgen) and similar tooling were around essentially since day one to assist in that.

It’s the only approach that has any chance of transitioning away from unsafe languages for existing, mature codebases. Rewriting entirely in a different language is not a reasonable proposition for every practical real-world project.

View on HN

Rust had to be dragged kicking and screaming into integration with other languages, and its C++ compatibility is a joke compared to Swift.

It's absolutely true that you need integration and compatibility to enable iterative improvements, but Rust historically has been hostile to anything besides unsafe C ABI FFI, which is not suitable for the vast majority of incremental development that needs to happen.

Luckily, this is starting to change.

"Hostile" is assigning intent that was not present. C++ ABI integration was and is extremely difficult; you need to be able to fully handle C++ semantics and to target each platform's take on the ABI. Most C++ competitors have struggled with this for much the same reason.

This means that "solving this" requires partial integration of a C++ compiler; it's not a coincidence that the languages with the most success have been backed by the organisations that already had their own C++ compiler.

A much easier solution is to generate glue on both sides, which is what `cxx` does.

If the intent was to interoyerate with c++ then not supporting the api is hostile. I have a lot of code using vector, if I have to convert that to arrays then you are hostile and worse that is new code which per the article makes it suspect

d does support c++ abi. It seems almost dead now but it is possible.

realistically there are two c++ abis in the world. Itanimum and msvc. both are known well enough that you can imblement them if you want (it is tricky)

> If the intent was to interoyerate with c++ then not supporting the api is hostile. I have a lot of code using vector, if I have to convert that to arrays then you are hostile and worse that is new code which per the article makes it suspect

It's not hostile to not commit resources to integrating with another language. It might be shortsighted, though.

> d does support c++ abi. It seems almost dead now but it is possible.

That was made possible by Digital Mars's existing C++ compiler and their ability to integrate with it / borrow from it. Rust can't take the same path. Additionally, D's object model is closer to C++ than Rust's is; it's not a 1:1 map, but the task is still somewhat easier. (My D days are approaching a decade ago, so I'm not sure what the current state of affairs is.)

> realistically there are two c++ abis in the world. Itanimum and msvc. both are known well enough that you can imblement them if you want (it is tricky)

The raw ABI is doable, yeah - but how do you account for the differences in how the languages work? As a simple example - C++ has copy constructors, Rust doesn't. Rust has guarantees around lifetimes, C++ doesn't. What does that look like from a binding perspective? How do you expose that in a way that's amenable to both languages?

`cxx`'s approach is to generate lowest-common denominator code that both languages can agree upon. That wouldn't work as a language feature because it requires buy-in from the other side, too.

As long as Rust depends on GCC and Clang, it can surely take the same path.

I don't see Cranelift ever replacing them as the main backend.

I'm not arguing rust made the wrong decisions. I'm arguing the concequences of those decisions is hostile to C++ interoperability.

> Rust had to be dragged kicking and screaming into integration

On what basis do you make this flagrant claim? There is certainly an impedance mismatch between Rust and C++, but "kicking and screaming" implies a level of malice that doesn't exist and never existed.

Such a low quality comment.

>has been hostile to anything besides unsafe C ABI FFI

As opposed to integrating with a whole C++ frontend? Gee, I wonder why more languages haven't done this obvious idea of integrating a whole C++ frontend within their build system.

This is the exact attitude I am referring to. Also, Rust already uses LLVM.

Unfortunately, sharing a codegen backend is neither necessary nor sufficient to enable the sort of seamless high-level cross-language integration that you appear to be requesting.

> Rust had to be dragged kicking and screaming into integration with other languages

Rust has integration with the C ABI(s) from day 1, which makes sense because the C ABI(s) are effectively the universal ABI(s).

> and its C++ compatibility is a joke

I'm not sure why you would want Rust to support interoperability with C++ though, they are very different languages. Moreover why does this fall on Rust? C++ has yet to support integration with Rust!

> compared to Swift

Swift bundled a whole C++ compiler (Clang) to make it work, that's a complete deal breaker for many.

> Rust historically has been hostile to anything besides unsafe C ABI FFI

Rust historically has been hostile to making the Rust ABI stable, but not to introducing other optional ABIs. Introducing e.g. a C++ ABI has just not been done because there's no mapping for many features like inheritance, move constructors, etc etc. Ultimately the problem is that most ABIs are either so simple that they're the same as the C ABI or they carry so many features that it's not possible to map them onto a different language.

I would like to point out also that C++ is not yet compatible with itself. Even GCC has dozens of C++ features it doesn't implement and it was the first compiler to implement 100% of C++11: https://gcc.gnu.org/projects/cxx-status.html

Technically true but in the real world those are rare edge cases.

Only because they're not used. If you're not going to implement the spec then is it really a spec?

It could also be argued that they aren't used because not all major compilers implement them.

If there was demand major compilers would implement them. That is why despite being difficult all major compilers are working on getting modules working.

I have millions of lines of c++. I'd love t use something else but without interoperability it is much harder. If you only write C you are fine. If you write java you want java interoperability, similear for lisp, or whatever your existing code is in.

That was created with the intention of being integrated into a very large C++ codebase.

I do agree that they could do more. I find it kind of wild that they haven’t copied Zig’s cross compilation story for example. But this stuff being just fine instead of world class is more of a lack of vision and direction than a hostility towards the idea. Indifference is not malice.

Also, you seem to be ignoring the crabi work, which is still not a thing, of course, but certainly isn’t “actively hostile towards non-c ABIs”.

I think they had to get over the knee-jerk reaction that Zig was a, quote, "massive step back for the industry", frowny face.

It seems they have, which is all to the good: the work to make custom allocators practical in Rust is another example. Rust still doesn't have anything like `std.testing.checkAllAllocationFailures`, but I expect that it will at some future point. Zig certainly learned a lot from Rust, and it's good that Rust is able to do the same.

Zig is not, and will not be, a memory-safe language. But the sum of the decisions which go into the language make it categorically different from C (the language is so different from C++ as to make comparisons basically irrelevant).

Memory safety is a spectrum, not a binary, or there wouldn't be "Rust" and "safe Rust". What Rust has done is innovative, even revolutionary, but I believe this also applies to Zig in its own way. I view them as representing complementary approaches to the true goal, which is correct software with optimal performance.

While Patrick played a critical role in Rust's history, he said that years after he stopped working on Rust. I haven't seen people still involved share strong opinions about Zig in either direction, to be honest.

I've known Andrew for a long time, and am a big fan of languages learning from each other. I have always found that the community of people working on languages is overall much more collegial to each other than their respective communities can be to each other, as a general rule. Obviously there are exceptions.

I'll admit hostile was perhaps too harsh, however looking back to the late 2010s, it seems clear that the attitude was:

- C ABI is good enough for any compatibility

- "Rewrite it Rust" / RESF

- Prioritize language proposals, not fundamentals

I think the attitude as changed somewhat in the last 2-3 years, with more interest in cxx and crubit and crabi, although many of those things are at least partially blocked on stalled language proposals, and largely ignored by the "core" Rust community. I would say indifference and posturing does approach hostility.

There's also consistent conflation of "compatibility with C++" and "rich compatibility with all of C++". Swift is a great example of how targeting PODs and std::vector and aligning concurrency expectations gets you extremely far, especially if you limit yourself to just LLVM.

btw, I really appreciate your Rust book.

Thanks for the kind words about the book!

I think indifference is very different than hostility. That there's only limited time, resources, and interest and those must be balanced and that means some projects advance before others is a very different thing than a refusal to do something.

Why is Rust then insecure by default, with exicit unsafe blocks leading to type and memory unsafeties, plus blocking IO leading to concurrency unsafeties?

They are talking about actually safe languages, secury by design and secure by default. Which would be a lisp or scheme without an FFI, or a beam language (Erlang, Elixir). Or pony, without the FFI. Or Concurrent Pascal, not Go.

Or a safe scripting language

The article explicitly uses Rust as an example of a safe language

Reply on news.ycombinator.com