Rust lacunae [LWN.net]

Rust lacunae

Posted Jun 11, 2021 11:19 UTC (Fri) by daniels (subscriber, #16193)
In reply to: Rust lacunae by ncm
Parent article: Rewriting the GNU Coreutils in Rust

> It could be seen as tragic when wholly new projects, like Pipewire, Vulkan, and Wayland, are coded in archaic, bug-prone C for no defensible reason; but they can anyway be redeemed starting with a 1-line change to their build script.

Wayland literally predates Rust, so sadly that wasn't an option.

The core library is quite tiny though, and its primary role in life is to act as a mediator between UNIX sockets (raw bytes) and an FFI bridge (C base types) to whichever language clients or servers are written in. Maybe C++ has matured a bit since Wayland's inception, but at the time C++ interfacing with itself might as well have been an FFI given how difficult it was. Either way, the code in between the sockets and the FFI is so thin that you'd probably increase the code complexity and error factor by converting it to C++.

I get frustrated at C when working on Weston because it's so unhelpful. But C++ doesn't help me with that, because remembering what the name of my type isn't my problem, nor is more ergonomic list/array iteration (because everyone augments the laughably-inadequate C standard library with their own anyway). Working with a language like Rust - which has a real type system unlike C/C++, the benefit of which flows through your entire codebase - would be a lot more compelling though.

to post comments

Rust lacunae

Posted Jun 11, 2021 12:02 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

> Working with a language like Rust - which has a real type system unlike C/C++, the benefit of which flows through your entire codebase - would be a lot more compelling though.

Indeed. Rust is so nice (except for syntax which I still hate) that I fear for the Mozilla a lot nowadays. Because most (if not all) really popular languages which were developed in companies either belong to companies are no longer are relevant in the software field (like AT&T with C) or extinct (like Sun with C++ and Java, like Netscape with JavaScript, etc).

Rust was separated from Mozilla, though, let's hope it would save Mozilla from that fate.

Rust lacunae

Posted Jun 14, 2021 16:45 UTC (Mon) by anton (subscriber, #25547) [Link] (1 responses)

Not sure why you mention Sun for C++. Bjarne Stroustroup worked at AT&T Bell Labs from 1979 to 2002.

Rust lacunae

Posted Jun 14, 2021 16:49 UTC (Mon) by khim (subscriber, #9252) [Link]

Memory wart, sorry. So both C and C++ were by AT&T and Java was by Sun.

Thanks for the correction, but it still doesn't bode well for Mozilla.

Except Rust is now separated from it thus there are hope.

Rust lacunae

Posted Jun 12, 2021 8:00 UTC (Sat) by ncm (guest, #165) [Link] (10 responses)

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.

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/