Hacker News Reader

Comment by pepijndevos | Hacker News Reader

Pleasantly surprised by Linus response. IIRC his attitude to C++ was that it should be refused if only to keep C++ programmers out.

View on HN

Rust is well designed modern and concise language with sound type system, while C++ isn't. The difference is huge and obvious.

Except that one of Linus' most vocal offenses on C++ was due to operator overloading and how basic, seemingly native things like + can actually do a lot of hidden stuff unknown to the programmer. He must have softened on this since Rust offers the same facilities for operator overloading.

https://doc.rust-lang.org/stable/rust-by-example/trait/ops.h...

Linus’s point was also that C++ makes extensive use of function/method name overloading (is polymorphism) and this can make code hard to read. Not only is this not possible in C but the feature tends to be overused in C++.

Rust generally uses function/method polymorphism based on traits (aka type classes), that's far less prone to overuse and abuse than overloading in C++.

Is this form of polymorphism done at runtime and thus incurs a similar overhead to the C++ virtual?

There are two ways of doing it. The way most people use most of the time does not, it's statically dispatched. The other way is dynamically dispatched, though there are some differences from the way that C++ virtual works. They should be roughly the same in that case, though.

It depends, you have access to both capabilities. By default if you're only dealing with an impld trait then it will use static dispatch. If you are passing around that same object as a trait objects, it will use dynamic dispatch and you can also impl Traits on other traits, which are always used as trait objects (vtable) but that have some restrictions on what they can look like. If you rely on the Deref trait to make it look like you have inheritance (but in reality it is composition) it will be the same as the later using dynamic dispatch.

You can pick whether you want to do this at run-time or compile-time. The default is compile-time.

> Not only is this not possible in C ...

There are lots of object systems in C that have polymorphism via function pointers.

The linux kernel is full of those

I agree with this critique, but a good IDE helps, as does lint rules preventing egregious misuses (or even outlawing operator overloading entirely). As one example, many Java/C# linters prevent the use of non-curly-braced single line control statements entirely. The language allows them, but many codebases do not.

Operator overloading in Rust is less flexible than in C++, so there are fewer possibilities to mess it up.

Overloading is done indirectly via specific named traits which enforce method signatures, invariants, immutability rules. Assignments and moves can't be overloaded. Borrow checker limits what indexing and dereferencing overloads can do (hardly anything beyond pointer arithmetic on immutable data). Comparison operators can't be overloaded separately and can't return arbitrary values (like C++ spaceship operator). Generic code has to explicitly list what overloads it accepts (like C++ concepts), so even if you create a bizarre overload, it won't be used in generic code.

Linus nowadays also uses Qt, so.

I would assume he sees difference between requirements for kernel code and a dive tracking GUI.

Could you give me a pointer to a discussion of type soudness in Rust? I recently watched perhaps 3 years old video about Rust where Simon Peyton-Jones asked about this, and Niko Matsakis answered it was ongoing work back then.

Couldn't find anything proper by googling.

See the work of Iris[1] project. It's open-source[2] and based on Coq, see Rust-related work[3] in particular.

[1] https://iris-project.org/

[2] https://gitlab.mpi-sws.org/iris/iris/

[3] https://gitlab.mpi-sws.org/iris/lambda-rust

His attitude towards C++ also changed when using it for his side project [1].

Initially he started with C and GTK+ and later migrated to C++ and QT Framework.

[1] https://subsurface-divelog.org/

Did he have an "attitude" about C++ in general? I thought he only commented on it with respect to operating system development. He did make much more general statements about Java, though.

My other reply: https://news.ycombinator.com/item?id=23801076

I thought the famous comment on C++ was in the context of git, not operation systems?

Did he talk about his thoughts precisely ?

I think I watched an interview with him where he talked about Subsurface project. In that interview he said that C++ is not all that bad but he still prefers C because he's so used to it and will continue write C code forever. I don't remember title of the video though.

I think that was after others took over the UI development. The back end of that program also was still C as far as I remember from their presentation and the move was mostly motivated by the GTK community, the documentation and different priorities on cross platform support.

Yes, you're correct. Linus still works on C backend of the application and sometimes has to connect his parts with C++ code.

I love how the bugtracker on that is "check out our mailing list" :D

Perhaps the possibility of rust improving kernel security/robustness makes the idea of rust integration seem like it carries its own weight, where C++ has more downsides (perceived or real) and fewer upsides.

Rust's history/origins - loosely, being designed to allow replacing Mozilla's C/C++ with safer Rust that performs well - feel like a good fit for kernel drivers even if the core kernel bits will always be C.

Yes, very much so. Not even only in the context of Rust but the insight, to fail fast, integrate early and do work in the open, instead of some hidden work, failing after a long time, when revealed.

Reply on news.ycombinator.com