[masklinn]

> How is Rust less complicated than C++?

In pretty much all senses of the word?

> getting even more so with the myriad of features they are adding each release.

It's far from adding a "myriad of features" with each release, and most of those it adds are library stuff, see for 1.23: https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...

And with respect to non-library features currently in-flight, by and large they are "playing catch-up" to C/C++ for compatibility or to fulfil use cases for which the language is not currently convenient or sufficient e.g. generics-over-values, const functions, allocators.

Rust has an upfront feeling of complexity in lifetimes and the borrow checker, but here's the ugly truth: pointer lifetime issues don't exist any less in C++, the only difference is the compiler doesn't help you with them.

[jhasse]

> pointer lifetime issues don't exist any less in C++, the only difference is the compiler doesn't help you with them.

There's also the case though where the Rust compiler isn't helping you, but is just wrong.

Must of them are going to be fixed by non-lexical lifetimes soon though.

[masklinn]

> There's also the case though where the Rust compiler isn't helping you, but is just wrong.

Bugs aside, compilers are not wrong, they may be too limited for what you're trying to do. Which is a different situation.

[loup-vaillant]

Being too limited for the intended purpose is still being wrong on some level. Not a bug, but still.

Granted, sometimes you don't care: stuff like `true?1:"foo"` is of type int an has value 1, but the compiler will rejected because of a type mismatch in the conditional—but you don't care because the code smell is too big and obvious to ignore.

Sometimes however you do care, if only a little: the value restriction in ML for instance prevent some function from being polymorphic because some side effect might break the type system. This forces you to eta-expand the function definition (no partial application, you need to write the arguments explicitly), which is a bit of a hassle in some cases.

[masklinn]

> Being too limited for the intended purpose is still being wrong on some level. Not a bug, but still.

By that criteria, every single statically typed language is "wrong on some level", you'll always find something you want to do/express which a specific language's compiler will not accept. That's not very helpful.

> Sometimes however you do care

I'm not saying people should not care, caring about lexical lifetimes being a pain in the ass is perfectly sensible (there's a reason why non-lexical lifetimes are being implemented after all). I'm saying there's a gulf between "the compiler does not allow X" and "the compiler is wrong", and lexical lifetimes are the former.

[jhasse]

Well, most compiler bugs are cases where the compile "is wrong" and "being too limited for what I'm trying to do" also sounds like a bug. So this reads to me as "aside from when they are wrong, compilers are not wrong" ;)

[masklinn]

> Well, most compiler bugs are cases where the compile "is wrong"

Most compiler bugs are situations where the compiler allows stuff it should not or generates incorrect code.

> "being too limited for what I'm trying to do" also sounds like a bug. So this reads to me as "aside from when they are wrong, compilers are not wrong" ;)

Most every compiler is "too limited" to do some things, that is a big reason why dynamically typed languages are still a thing. For instance I can't tell Java to just take any object with an attribute "foo" despite it being the only thing I want to use (and I don't even care about its type) — bypassing the compiler via reflection aside. Do you think that's a bug in the compiler?

[jhasse]

Hm ... I wouldn say thats a limitation of the compiler but of the language itself (no ducktyping). Definitely not a bug though.