Hacker News new | ask | show | jobs
by benreesman 1422 days ago
Oh I completely agree that defaults matter, and I wouldn't advise anyone to go start some big C++ project unless they had a very good reason to.

But Rust vs. C++ is not an apples-to-apples comparison in this regard: Rust got a clean slate and was willing to cut ties with engineer-millenia of existing high-value software to do it.

In a perfect world Rust wouldn't be ambivalent at best and hostile at worst to C++ interop, c'est la vie.

2 comments

Rust isn't hostile about C++ interop, it's that between native interop (which requires dealing with templates and memory unsafety) and safety, Rust prioritized safety, while Carbon is trying the alternate approach. The behavior of C++ is simply hard to interface with while providing the assurances Rust gives you.

Edit: how many languages have native C++ interop that supports the whole language? Would love to hear of any.

I said ambivalent to hostile at worst, and I'm sorry, it is. I write FFI to C++ in Rust, Python, and Haskell practically every week, and Rust <-> C++ sucks.

Slap it in an `unsafe` block, fine. But let me move a `std::vector<std::string>` into my `unsafe` block easily. Erase the types, fine. But let me call `v.at(idx)`.

Python takes C++ interop seriously, which is why Tensorflow and PyTorch and all the other people trying to script gigantic, extreme-value C++ codebases use it. Try `pybind11` sometime, it's night and day.

Edit to reply to edit: `pybind11` supports an absurd amount of C++ out of the box with completely natural semantics and a very modest performance penalty. So, Python.

I wouldn't say python takes C++ interop seriously, it's more like the pybind11 people are amazing at what they do and found a way to slice the problem neatly. But yes, it's night and day, pybind11 is a godsend.
Haha I don't know if it matters much whether we praise the `pybind11` folks in particular or the Python community in general or both: they are fucking amazing at what they do. It's such a hard problem that most language communities don't even seriously try, it's a nightmare to get even close on, and they get more than close. Everything just works exactly as you'd expect, with great performance (relatively speaking of course) into the bargain.

Top ten best open source language efforts on Earth. Maybe top five. Just legendary stuff.

I do think that for all its faults though (cough packaging cough), the Python community displays an incredible commitment to getting shit done and helping people solve their problems. It's really a rather mediocre language as these scripty things go, but it just friggin works, which is why everyone uses it for everything.

Oh I meant C++ binding was more of a pain before. I've been doing swig and other kinds of C FFI wrapping for years and this is far better...

Of course it relies on the module/extension API from python that is quite amenable to this kind of full-object and their methods binding. But it works very well together.

So much that we asked similar for Ada https://github.com/AdaCore/Ada-py-bind (Raphael Amiard from AdaCore is quite the Ada hacker) which, even with the limitations of Ada generics, has been a godsend for scripting Ada objects from python.

I have to admit to basically total ignorance of Ada. It's got a heritage around avionics-type stuff right, extreme low defect tolerance settings? Looks kinda like Pascal?

Is it something that a true polyglot hacker needs to know? It's got important, novel ideas or unique applications that aren't addressed well by other tools? I love learning languages, but there are so many you'll never learn them all well.

Thanks, I'll look at pybind11. Have you looked at cxx by any chance?
I have. `cxx` and `autocxx` and `bindgen` and `cbindgen` are, better than nothing I guess? But they're all flakey and have weird corner cases (and crash sometimes! I'm looking at you `cbindgen`!) and don't handle containers well if at all and just, ugh.

I always end up saying fuck it and `extern "C"`-ing everything. It would be completely possible to make these tools work well, but the Rust ethos is "rewrite everything, pure Rust", at least in large parts of the community, and so these projects kind of never get totally dialed in.

> But they're all flakey and have weird corner cases and crash sometimes!

Did you report those crashes? There's also crubit these days, mostly combining the autocxx and (c)bindgen approaches. (It's a very new effort, which is why it's being kept separate from these more established ones.)

was not aware of crubit, so thanks for posting. i'm trying to follow closely what's happening in this space
It's not just C++ interop. We chose Zig because writing C library bindings for Rust is bewildering.
Yeah.

I know the talking points (it's impossible to go on the Internet and not know all the Rust talking points) but you have a few beers with some Rust people and pretty quickly you're hearing how anything that isn't Rust all the way down is somehow like, tainted, with the dreaded binary quality of being "unsafe" as opposed to "safe". A serious Rust hacker who shall remain nameless once broke out that old chestnut on me: "A barrel of wine and a spoonful of sewage makes a barrel of sewage." in reference to Rust software that links to C. It's not a coincidence that somewhere, every conceivable library that anyone could ever want is being rewritten in "pure Rust".

And it's a shame because Rust is fucking cool and I want to be using it even more than I already am. But I'm not going to become a Scientologist to get into a party in LA and I'm not going to throw away a mountain of excellent C and C++ because it's, unclean.

I'm optimistic that as Rust continues to have its center of gravity migrate away from strictly OSS and into ever higher stakes industrial settings (which it's clearly making great headway on) that the religious fervor will mellow and it'll become a "getting shit done" language that also happens to be a really cool language!

the first thing i did in rust was c lib bindings and it is simple.
The C library we need has a few requirements that most people agree are difficult for Rust.

Working with any of the following is a nightmare:

- Memory arenas

- Intrusive data structures

- Buffer lifetimes with interesting lifetimes (typically because it maps to hardware)

Given the vast C++ ecosystem (including pretty much every big game engine), there are still a ton of very good reasons to start a new big C++ project.

At least until Carbon is ready! But that's a few years away at the least.