[tombert]

I think there are certainly different complications in Rust than C++. The RAII can be roughly the same in the naive sense, but there's having to worry about Send and Sync and Pin and fighting with the borrow checker and all that fun stuff.

Gauging how "complicated" a language is somewhat subjective, so it's kind of hard for me to give a straightforward answer. I think it's certainly easier to be (some definition of) productive with C++ than with Rust. I feel like to do anything even remotely non-trivial with Rust, you kind of have to understand everything, because if you don't do it in the "Rust way", it often won't compile. I think this is a good thing, but it does make it harder to get started.

C++ has a lot less consistency and (kind of) more features, and lots of strange semantics to go with those features, and so if people actually use them it can get confusing and hard to read pretty quickly.

My knowledge is a bit out of date, to be clear; previously whenever I need something in the C++ domain, I could fairly easily just reach for C and use that instead. Now Rust is available and I think overall better (though I do sometimes miss how utterly simple and dumb C is).

[asa400]

> having to worry about Send and Sync and Pin and fighting with the borrow checker and all that fun stuff.

To be fair, the alternative to having to worry about Send/Sync/Pin is not "not worrying about Send/Sync/Pin". It's having to worry about correctly enforcing the constraints they describe on your own, without any kind of mechanical help. E.g., not moving data to another thread that shouldn't be and not accessing data from multiple threads that shouldn't be. This stuff is intrinsic.

In this sense the Rust mental model is simpler, because failing to uphold these constraints is no longer "your fault", it's Rust's fault.

[tombert]

I don't disagree; I was coming from Java most recently, and a lot of the equivalents of "Sync" and "Send" were just mental notes I was making myself, and I wasn't really used to it being encoded into the type system.

[Ygg2]

Yeah, and writing thread safe Java is fraught with hidden shotgun and footguns because whether something is thread safe depends on bunch of notes about this class/method not being thread safe.

And relying on people to check them. Versus a compiler.

[foobarian]

> have to understand everything, because if you don't do it in the "Rust way", it often won't compile

I confess I haven't dug into it much yet, but this reminds me of how Haskell was. By the time you got a program to compile your project was more or less done.

[tombert]

In some senses I actually find Rust a bit harder than Haskell. With Haskell the types are immutable and as such they can be happily shared everywhere. That required basically no rewiring in my brain.

With Rust, I had to get used to single ownership or explicit cloning. There's an argument that this is "better", but I found it a bit harder to learn.

[tialaramex]

You can choose to make all your things immutable and have the same "no rewiring" as Haskell. Sometimes that's an excellent idea, sometimes it's obviously a terrible idea, many times you'd have to measure to find out and IMHO in Rust you should write the easiest thing in those cases and only measure if your perf isn't acceptable.

[cratermoon]

Rust is similar. I don't have a link handy, but I've read a few articles noting experience with programming in rust where a program that compiles works. Provided the logic is correct, of course.

[tialaramex]

> I do sometimes miss how utterly simple and dumb C is

You can make an argument that the K&R C "is" an utterly simple and dumb language, but if it was it's long gone and it's also irrelevant for modern hardware.

Today because C only has a single kind of reference, the raw pointer, that means if you want references at all (which you do) you need pointers, and to get decent performance from this sort of language you need pointer provenance, and so now all your reference types involve understanding compiler internals minutiae. Bad luck though, those aren't specified in the C language standard, that's a TODO item from the turn of the century. The committee agrees that C pointers do have provenance but declines to explain how that could possibly work.

[Georgelemental]

To be fair, it's a very hard problem. Even in Rust, the formal model of how provenance works is very much WIP

[tialaramex]

Rust's Provenance itself stabilized, some time ago in fact, as basically the Tower of Weakenings. If you noticed the raw pointer provenance APIs are all marked stable since Rust 1.84, that's because the underpinning model is also stable - however the provenance rules do need to care about aliasing and Rust's aliasing rules are to some extent a WIP. So there is definitely a creaky floorboard in the specific case that you want to do pointer twiddling and your pointers might arguably alias and you'd like clarity about exactly where the line is on that.

I haven't seen places where they wanted this, but they definitely can exist. In the cases I'm thinking of any valid pointers are definitely unique (so no aliasing), or they're definitely pointing at something immutable (so aliasing is fine) or both and so there's no problem as I understand it.

There is an outstanding issue with LLVM - for any language including Rust - that it has unsound optimizations for pointers and this has implications for provenance tricks, but as I said that's not Rust specific and I think worse there are signs the same illness afflicts the GCC backend so maybe it's worse than "LLVM is buggy" and is a wider problem in how compiler developers have thought about this vague unspecified problem.