The Case for Rust (in the base system)

T-Aoki said:
But as Ada is STRONGLY standardized (for compilers allowed to be named Ada), if the above-mentioned problems/risks becomes no problem, Ada can be the best candidate for memory-safe alternative.
Click to expand...

Unfortunately it seems to have the same issue as Rust with regards to interfacing directly with C code:

https://learn.adacore.com/courses/intro-to-ada/chapters/interfacing_with_c.html

Specifically:

https://learn.adacore.com/courses/intro-to-ada/chapters/interfacing_with_c.html#adapting-bindings

The language is mostly memory safe, but the glue required to call into the operating system very much is not. In many ways this likely could result in more memory errors than sticking with homogenous C.

An OS written entirely in Ada would be the better solution rather than shoehorning it into FreeBSD and mashing the languages together. The Rust Redox OS is the good approach here (its really the only Rust project that is relevant).
 
I get a lot of mileage out of -Wall and whatever analysis the vendor's toolchain provides. I've been impressed by potential mistakes flagged. However, some of the compiler warnings in C++ make me feel like I'm programming in Rust mostly because the compiler (Rust or C++) isn't smart enough to realize the code is actually safe.

Example: declare a class with a buffer. In the constructor, fill the buffer - but make sure there's an if/else clause inside the loop. Most source code analyzers will complain that I forgot to (fully) initialize the buffer - which just isn't so.

I can either pre-fill the buffer with zeroes to placate the analyzer (which wastes a few cycles since it is promptly overwritten with the real values) or use a pragma to hush the analyzer. Neither is ideal.

Looking at this from the direction of C/C++, the compiler can enforce many of the same rules as the Rust language with most of the same advantages and annoyances.
 
kpedersen said:
Its been 52 years. Any day now! ;)
Click to expand...

You're right, that's far too long - let's get Rust merged already! ;)

unitrunker said:
Looking at this from the direction of C/C++, the compiler can enforce many of the same rules as the Rust language with most of the same advantages and annoyances.
Click to expand...

Static analyzers have vastly improved in the 25 years I'm using C/C++, but it's really not the same level as Rust. The checks are mostly restricted to local issues, and as in your example there's far too many false positives, as well as false negatives. Rust gives you confidence of memory safety on the whole compilation, at the price of conforming to the language.
 
I started learning Rust (my colleagues and I have to convince the company management not to rush into rewriting “everything” in Rust, but to stay in C and C++ for now). I haven’t made much progress (so far here - https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html), but I don’t see a single advantage compared to C, much less compared to C++. Here's an emotional article that I mostly agree with - https://dorinlazar.ro/240228-i-hate-rust-programming-language/

(I continue to study and practice in Rust...)
 
Andrey Lanin said:
I started learning Rust (my colleagues and I have to convince the company management not to rush into rewriting “everything” in Rust, but to stay in C and C++ for now). I haven’t made much progress (so far here - https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html), but I don’t see a single advantage compared to C, much less compared to C++.
Click to expand...

Uhmm ... so you haven't read the relevant chapters yet and don't know anything about Rust, but "don't see a single advantage"? How should anyone take you seriously like that, including yourself and your management?

If they want to push Rust, ask them for a 2 day retreat to learn the basics. Day 1 you're through with the tutorials, day 2 you can apply the concepts in some toy programs. That will help you to make an informed decision, more so than to follow the ramblings of some simple-minded random guy on burnout who wasn't able to learn Rust.
 
I've been programming for a long time, since 1982. I've been writing in C since 1995, in C++ since 1999. It doesn't take me long to realize that Rust doesn't have any advantages, at least in comparison to C++. But I continue to learn Rust. Although I don't think my opinion about it will change...:-/

Anyway, thanks for the advice.
 
Everyon should recall that even C cannot descrive the whole bunch of FreeBSD. Some (maybe mostly inline) asm part remains. Yes, mixed languages.
So should be Rust.
No language (except pure interpreters like /bin/sh) should discard mixed up linking feature with other languages, unless forcing everything to be rewritten at once. Yes, AT ONCE.
On Unix-like environment, the basics shoud be C, as C itself was designed and implemented for implementing Unix.
If clang implements inline Rust just like inline assembly, it would help much, although Rust guys would surely hate it.
 
Andrey Lanin said:
my colleagues and I have to convince the company management not to rush into rewriting “everything” in Rust, but to stay in C and C++ for now.
Click to expand...
That's interesting. Usually its the exact opposite way round. The juniors pining for Rust and management telling them to just conform to industry standards.
 
You know the Dilbert for this, yes?
PHB "A good manager hires people smarter than himself"
Alice "That means your boss is dumber than you"
Dilbert "And the CEO is the dumbest around here"
Wally "Unless you are bad managers"

But I concur with BaronBS , they hired the experience they lack. Problems start when they don't want to listen.
 
To me it's brain-damaged to put an exclamation mark after a function call like this:

println!("Hello, world!");

The extra work of having to type Shift-1 to get a redundant exclamation mark seems pedantic to me. The language is ugly as hell. I'm avoiding it like the plague while I can.

How did they manage to make a language uglier than C++?
 
rbranco said:
To me it's brain-damaged to put an exclamation mark after a function call like this:

println!("Hello, world!");
Click to expand...
It does look pretty ugly.

In Rust that println is a macro (similar to a template function. Safer than C MACROs because expanded into AST rather than simple substitutions). It would be the C++ equivalent of:

Code: 
template <typename A>
void println(const A& _a)
{ ... }

[...]

println<std::string>("Hello World");
println("Hello World"); // template argument can be automatically inferred


They decided not to do it via overloads for a few reasons (perhaps they are doing something fancy with traits instead). I suppose they highlight this kind of template function (with a !) in the same way that in C we highlight MACROs in all caps.
 
rbranco said:
To me it's brain-damaged to put an exclamation mark after a function call like this:

println!("Hello, world!");

The extra work of having to type Shift-1 to get a redundant exclamation mark seems pedantic to me. The language is ugly as hell. I'm avoiding it like the plague while I can.

How did they manage to make a language uglier than C++?
Click to expand...
Not defending it, but it's a macro.
 
POSIX, as well as Win32, the fundamental operating system interfaces, perpetuate the single most costly mistake in the history of computing, which is the zero-terminated string. (source)
Click to expand...

I've felt similarly for so long, glad not to feel alone on this.

These things are hard to quantify, but evidently null is a billion-dollar mistake.

rbranco said:
To me it's brain-damaged to put an exclamation mark after a function call like this:

println!("Hello, world!");
Click to expand...

That's a pretty superficial criticism. Also it's a macro, not a function call - here's a decent discussion of why.

To be fair, I'm the guy who originally responded to Ruby with "this doesn't even have semicolons, I can't take it seriously." Then put together a solid decade+ professional run with it.
 
patmaddox said:
I've felt similarly for so long, glad not to feel alone on this.

These things are hard to quantify, but evidently null is a billion-dollar mistake.
Click to expand...
Certainly not alone. Which is pretty much why they are the first things C++ "fixed" decades ago. std::string and references&.

Turns out, the zero terminated strings kind of lived on because it helps ensure ABI stability. Even young languages like Swift, Rust and Go can't avoid them when calling into the OS and platform libraries.
 
Jose said:
I became an instant hater of C++ references the first time I had to use an std::map. I was checking for the existence of a particular key, and to my astonishment, every C++ map contains every possible key.
Click to expand...
See how efficient C++ is with memory? What? Sure, I'll get my coat...

You are not the first one to make that mistake, I know I did (and will likely do again some time). Every language has such traps, or it is not a true scot... a real language.
 
patmaddox said:
That's a pretty superficial criticism. Also it's a macro, not a function call - here's a decent discussion of why.

To be fair, I'm the guy who originally responded to Ruby with "this doesn't even have semicolons, I can't take it seriously." Then put together a solid decade+ professional run with it.
Click to expand...
It's an aesthetic judgment, and as such: superficial and subjective. Rust code just looks ugly to me. I can't help it. =/
 
patmaddox said:
These things are hard to quantify, but evidently null is a billion-dollar mistake.
Click to expand...
I read the article - and it offers technical reasoning why null references were a mistake to create/use. But it offers no financial analysis whatsoever, just an assumption casually thrown out by the speaker as random ballpark guesses.

Yes, there are hurdles to financially quantifying the cost of a 'mistake'. Yes, there were highly paid programmers who spent months/years to develop something that was ultimately shown to be of limited use/value. Yes, that technical mistake snowballed before some smart people caught on and realized that it's a mistake that needs to be rectified so that other expensive projects are not declared a wash.

From an XKCD that Crivens posted on @kpedersen 's profile: If all modern digital infrastructure seems to depend on this one little project that has been maintained by someone in Nebraska since 2003, then that design detail is a hugely expensive mistake. We can call all those security holes 'Expensive mistakes', too.
 
astyle said:
I read the article - and it offers technical reasoning why null references were a mistake to create/use. But it offers no financial analysis whatsoever, just an assumption casually thrown out by the speaker as random ballpark guesses.
Click to expand...
Read "a billion dollar mistake" as "a very very expensive mistake". The modern equivalent of "myriad".
 
You must log in or register to reply here.
Back
Top