[estebank]

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.

[benreesman]

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.

[touisteur]

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.

[benreesman]

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.

[touisteur]

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.

[benreesman]

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.

[touisteur]

It's my daily driver and I think one of the reasons my company can build very complex and high integrity systems with little staff. It's got a lot of nifty features and is still being updated to integrate more. I saw so many people very uninterested in hacking and programming, learning Ada and be so efficient with it so fast, with very few bugs, that there must be something there.

I'd say the driving principle is the language tries to have you write code that can be read easier, and is less concerned about helping you write millions lines of code per month. One example (when you get past the knee-jerk 'whoa it uses begin and end instead of braces') is generics where instantiation is mostly explicit (and thus can be painful to write) which helps reading, a lot. I'd downvote to hell any change to that (let the IDE/langserv generate the code for you, but please, generics are complex already).

The other driving principle is finding defects as soon as possible. So the compiler is harsh, there are lots of static checks. But it also helps you find defects at runtime as soon as possible. It can insert validity checks everywhere, if you can pay the runtime cost (hint: it's very rare you can't).

It has strong typing, very interesting typing features, no implicit conversion, most features you'd want in a modern language (tasking, OOP, generics, exceptions - erm...) and some that are more 'original' (contracts, quantifiers, if- and case-expressions, function arguments qualifiers in/out/in-out) and very nice union types (discriminated records).

Recently it has been extended to formal proof, with the SPARK language, which is Ada with some language features disabled and an automated proof environment (based on Why3 and SMT solvers), which is also its own interesting new tech, with interesting advances these last years (proof of floating point operations, memory ownership,...).

I think I could go on and on. But if you can spare one or two hours I'd just go to https://learn.adacore.com/courses/intro-to-ada/index.html and run the tutorial (all in the browser) and read a bit about all the features, and just ask questions downthread, I'll try to monitor it (like I don't already monitor obsessively all my HN comments...).

[estebank]

Thanks, I'll look at pybind11. Have you looked at cxx by any chance?

[benreesman]

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.

[zozbot234]

> 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.)

[dureuill]

was not aware of crubit, so thanks for posting. i'm trying to follow closely what's happening in this space

[infamouscow]

It's not just C++ interop. We chose Zig because writing C library bindings for Rust is bewildering.

[benreesman]

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!

[accountofme]

the first thing i did in rust was c lib bindings and it is simple.

[infamouscow]

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)