Rust lacunae [LWN.net]

Rust lacunae

Posted Jun 12, 2021 8:00 UTC (Sat) by ncm (guest, #165)
In reply to: Rust lacunae by daniels
Parent article: Rewriting the GNU Coreutils in Rust

To suggest that C++ does not have a real type system, when in fact its type system was the primary model for Rust's, and which power Rust language developers still seek to match, illustrates how what you write about the language wholly lacks factual foundation.

When you show you need to rely on falsehoods to make your case, you reveal you have no case.

to post comments

Rust lacunae

Posted Jun 13, 2021 14:10 UTC (Sun) by jezuch (subscriber, #52988) [Link] (3 responses)

> when in fact its type system was the primary model for Rust's

Um, excuse me? C++'s type system is based on misunderstanding of object orientedness (which in C++, and just about any other "OO" language, is just an extension of structural programming and a far cry from Simula's design, which we're only now rediscovering). Rust's type system is based on algebraic types, in the ML tradition (not as pure as in Haskell, but still). Traits are first-class citizen in Rust, while in C++ they're a design pattern at best, and everything is centered on classes. Completely different paradigms.

BTW, I know that my interpretation of history of programming language design is un-orthodox, no need to point it out ;)

Rust lacunae

Posted Jun 13, 2021 18:38 UTC (Sun) by zlynx (guest, #2285) [Link] (1 responses)

I hear OO purists complain about C++ design all the time.

But no, it was not a "misunderstanding." I think C++ design is probably one of the best compromises possible between efficient machine code and OO. And of course we must remember it stayed compatible with C.

"Pure" object oriented languages are just disgustingly inefficient. Java succeeds because of the immense work put into its JVM and JIT compiling. Python and Ruby show off what happens when everything is an object.

Anyone can look and see that C++ is used where speed matters.

Also it is very funny that you use Simula of all languages as an example of object oriented. Smalltalk was the pure object oriented language. Simula was a mashup of Algol and OO juist as C++ is a mix of C and OO. Simula doesn't contain even half of what became Object Oriented in Smalltalk.

Rust lacunae

Posted Jun 14, 2021 12:28 UTC (Mon) by jezuch (subscriber, #52988) [Link]

Yes, sorry, should have not clouded my point with my peeves :)

The claim was that Rust bases its type system on C++ and is far behind it. My point was that Rust, while syntactically in the C family, explicitly breaks away from its type system. And is more powerful thanks to a conscious design and not being a heap of ad-hoc.

Rust lacunae

Posted Jun 13, 2021 19:28 UTC (Sun) by ncm (guest, #165) [Link]

"Unorthodox" meaning wrong, of course.

Language purity is a farce. C++ was never promoted as an "object-oriented language". It has always been a language that provides support for an object-oriented style as one among many, and supports promiscuous mixing of styles for anyone not stupidly wedged into just one.

Most of its type operations are inspired by ML, as in Haskell. Algebraic types are just types. There is no paradigm. Paradigms are a farce too.

Rust lacunae

Posted Jun 13, 2021 14:13 UTC (Sun) by jezuch (subscriber, #52988) [Link] (5 responses)

> which power Rust language developers still seek to match

Oh, and I believe that Rust's type system is way more powerful than C++'s, which is a complete mess. So the catch-up goes the other way.

Rust lacunae

Posted Jun 13, 2021 15:02 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (2 responses)

Well, C++ does have NTTP (non-type template parameters) and HKT (higher-kinded types; "template templates" in C++). Specialization is also probably more powerful in C++, though I'm less versed in Rust's capabilities here. So in that respect, C++ does have more expressiveness, but Rust adds expressiveness in terms of knowing how ownership of data flows through an API. The lack of exceptions also means that error cases are exposed directly on the API too (checked exceptions being, largely, a failed experiment AFAIK). It can sort of be done with C++, but the corner cases that exist are annoying. The one that comes to mind is `std::optional<T&>` and `std::variant<T&>` are not usable in C++ today (one can wrap `std::reference_wrapper` around it, but is tedious to type and juggle).

Rust lacunae

Posted Jun 13, 2021 21:54 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

Type system of C++ is built like everything else in that language: 100 stories tall skyscraper with the foundation of quicksand. Yes, I know why, but the fact that size > -1 is always false if size is unsigned with no warnings or errors caused far more real-world problems than anything related to issues with references. The fact that uint32_t, uint64_t and size_t are not distinct is seriously problematic, too.

Rust have a pretty decent type system. Not perfect but pretty good. Type system of C++ is collection of footguns. Yes, you can make your program misbehave in so many interesting ways… but does anyone finds it fun to explore all these ways when they are debugging something?

Back then when C++ at least tried to be compatible with old versions it sounded justified at least, but now, when new versions of C abd C++ are designed to add new and exciting bugs into programs which were perfectly safe yesterday that “compatibility!” excuse just doesn't sound convincing. At least Linus works as good enough brake for that activity in “Kernel C”. But nobody does the same with C++.

At least safe Rust doesn't try to pretend that someone may write code in 1990 which obeys rules which are not yet finalized yet in 2021. Unsafe Rust, sadly, inherits that issue because of it's LLVM foundation, but in typical program there are limited amount of unsafe rust code.

Rust lacunae

Posted Jun 24, 2021 15:24 UTC (Thu) by nye (guest, #51576) [Link]

> size > -1 is always false if size is unsigned with no warnings

$ clang++ -Weverything /tmp/test.cpp
/tmp/test.cpp:4:14: warning: result of comparison 'unsigned int' > 4294967295 is always false [-Wtautological-type-limit-compare]
    if (size > -1) {
        ~~~~ ^ ~~
/tmp/test.cpp:4:16: warning: implicit conversion changes signedness: 'int' to 'unsigned int' [-Wsign-conversion]
    if (size > -1) {
             ~ ^~

Even if you don't like using -Weverything because you don't want to opt in to newly added warnings, I do think that -Wsign-conversion is something that should always be turned on for code under active development. If you have substantial legacy codebase then you will doubtless need to add a lot of explicit casts to silence false positives, but, well, that's what you asked for.

Rust lacunae

Posted Jun 13, 2021 19:35 UTC (Sun) by ncm (guest, #165) [Link] (1 responses)

You are free to believe as many falsehoods as you like.

Or, you can look at the actual proposals to strengthen Rust's type system to be able to express more of what can now be expressed in C++ and Haskell but not in Rust.

Rust lacunae

Posted Jun 14, 2021 12:22 UTC (Mon) by jezuch (subscriber, #52988) [Link]

Well, Rust's type system is Turing-complete[1], so it's hard to argue that it's less powerful than anything.

[1] https://sdleffler.github.io/RustTypeSystemTuringComplete/