Google Engineers Lift The Lid On Carbon - A Hopeful Successor To C++

[ssokolow]

Fishing for something so you can launch a personal attack ?

More like fishing for an actual point which can be discussed on its merits so they have an option other than a personal attack.

[Sergey Podobry]

Or can you show me a project of one of those miracle programmers that never had an error (concurrency, buffer overflow, use after free, ...) thats not possible in rust?

I don't remember when I had this kind of errors in C++. You just have to follow a set of rules. Unfortunately a C++ compiler doesn't force you to do that like the Rust compiler. However you can't implement in Rust linked lists, trees or graphs without extra overhead (like Linux kernel does in C).

[ssokolow]

Let me quote someone else: "I've written C and C++ professionally, also used Go and Rust on hobby projects. Rust, by far, was the hardest to learn and get something useable out of it. Because of that, I would never recommend someone put it into production unless they have a very specific use case that Go could not handle. The onboarding costs would be just too much."

Pass this on to them:

In large part, it depends on what coding style you've been trained in. The borrow checker really doesn't like the complex and difficult-to-reason-about data lifetimes that you get when you make a complex, possibly cyclic graph of ownership and/or references (thus requiring something like Rc<T> or Arc<T>, being Rust's analogues to std::shared_ptr<T>, to move resolving it to runtime), and it's a language that was designed for the reality that, in real-world scenarios, most are going to reuse existing data structures written by other people (eg. the petgraph crate) rather than reinventing the wheel for every project, so it's acceptable to make implementing new data structures a more advanced skill to achieve savings elsewhere.

...that does, however, make Rust more difficult to learn than it needs to be if you follow the traditional CS101-style path of "let's learn the language by starting at the bottom and implementing a doubly-linked linked list as a synthetic problem".

I came from Python to Rust with only one semester each of C and C++ back in university, which were disappointingly focused on syntax, and found it quite easy to get into when I added reading Learning Rust With Entirely Too Many Linked Lists after The Book to my learning strategy to solidify my understanding of The Book with some practical examples of what it meant in more infrastructural contexts. (And this was back when Rust v1.0 had just come out and a lack of Non-Lexical Lifetimes support did legitimately make the borrow checker much more obtuse and confrontational.)

(I'd already gotten fed up with the boilerplate and drudgery that "quality object-oriented code" brought, so I was already using a data-oriented semi-functional style in my Python programs. Heck, I was doing dependency injection in Python for years under the banner of "architecting my code to be easy to unit-test" while saying I hated dependency injection because I didn't realize the boilerplate and ceremony from all the Java examples people pointed to was optional. YAGNI is my motto these days and it harmonizes very nicely with one of Rust's slogans, "fearless refactoring".)

[Anux]

I mean, there's always Donald Knuth.

Could you point me to the concrete bugtracker of the project that you had in mind?

I don't remember when I had this kind of errors in C++.

You most likely had some of them but probably never noticed them. Thats usually the case with all C/C++ projects.

You just have to follow a set of rules. Unfortunately a C++ compiler doesn't force you to do that like the Rust compiler.

Yeah shure even in assembler you can just follow some rules and have no memory error. But nothing warns you and you would have to be a perfect programmer that does not exist. And than a second programmer comes to you project ...

However you can't implement in Rust linked lists, trees or graphs without extra overhead (like Linux kernel does in C).

If you need performance you wouldn't use linked lists. The problem is referencing to an object inside this self object but this is easily solved with a box between. And I would bet that doesn't even influence the final performance, else there is always unsafe and pointers.

[sinepgib]

However you can't implement in Rust linked lists, trees or graphs without extra overhead (like Linux kernel does in C).

You can and there's even a book about it.
You just need to drop into unsafe for the struct itself, like you'd do in C, except in C it's all unsafe.

[sinepgib]

Could you point me to the concrete bugtracker of the project that you had in mind?

Your joke detector must be broken. I was actually agreeing with the point being made.
Just for reference, Donald Knuth is the author of possibly the most respected book in programming history as well as one of the most bug free complex pieces of software out there.

So, yeah, explaining my own joke, it's about unrealistic standards

[ssokolow]

Everyone is talking about rust being young, but it is already 12 years in the making ...

Rust v1.0 only stabilized the language syntax 7 years ago, so that's the age that's usually relevant. (Rust only dropped its Go-esque green threading runtime less than 8 years ago and the old special-cased support for garbage-collected pointers only 9 years ago.)

I had high hopes for rust when people started to write an OS in rust: https://gitlab.redox-os.org/
Every year or so I go and check the progress.
I have never been able to get that source code to compile properly. Always some incompatibility or version issue.

They require nightly versions of the compiler, which means they've chosen to depend on experimental language features that haven't fallen under the API stability promise yet. I wouldn't consider Redox representative of Rust projects without acknowledging that caveat.

(Also, I looked at their "Help! It won't compile!" instructions and they suggest that the Redox devs didn't do the responsible thing and add a toolchain-versioning metadata file to the project to tell the build system which nightly build of the toolchain it needs to pull in for guaranteed success.)

...not to mention, of course, how many times I've had to patch C or C++ code to get it to build on a GCC or Open Watcom C/C++ version newer than what the developers intended.

[ssokolow]

You can and there's even a book about it.
You just need to drop into unsafe for the struct itself, like you'd do in C, except in C it's all unsafe.

You often don't even need unsafe. Depending on what you're doing, you can often achieve the same performance by using either use Rc<T>/Arc<T> with Weak<T> for the parent pointers or something like Vec<T> and indexes akin to mmap(2) and pointers, but with protections against escaping that particular data structure's arena.

The optimizers can do some pretty impressive things if you use the abstractions well and some of the best safety-dance security audit outcomes I've seen have been about rewriting code to remove unsafe that turned out to be unnecessary to get the performance.

[piotrj3]

Wouldn't a

unsafe {
}

disable the borrow checker?


They never existed in the first place. Or can you show me a project of one of those miracle programmers that never had an error (concurrency, buffer overflow, use after free, ...) thats not possible in rust?


You seem to describe Rust.

It does not disable borrow checker. You can supress with unsafe and #[you_can::turn_off_the_borrow_checker] but it does not disable totally borrow checker it simply ignores some errors it produces.

[ssokolow]

It does not disable borrow checker. You can supress with unsafe and #[you_can::turn_off_the_borrow_checker] but it does not disable totally borrow checker it simply ignores some errors it produces.

Except that nothing turns off the borrow checker in the sense people tend to think. The compilation and optimization steps function the same whether or not you've got a breathalyzer interlock. You're still invoking undefined behaviour if you use unsafe to suppress it on the constructs within its domain and, if you can suppress it without unsafe, you've found a bug in either the compiler or one of your dependencies.