Thread: Let's talk about Rust!

Originally Posted by Neo1

True, the way Rust manages memory is with reference counted smart pointers, like C++. So if C++ with smart pointers is fast enough for some task, then Rust will be too (Once the compiler is more mature and can optimize as well as modern C++ compilers do now).
Obviously this will be slower than the raw pointers of C, but Rust retains the level of control that C provides.

I think with optimizations enabled, the get(), operator* and operator-> are likely to be inlined, so they become as fast as raw pointers.

Well, of the top of my head:
The unique_ptrs and shared_ptrs of Rust are part of the core language, rather than part of the standard library. This means Rust can give some compile-time guarantees about leaks and dangling pointers.

This may be helpful, but it does introduce some overhead, no matter how efficient you try to make it.

Many of the more eccentric properties of C++ are not present in Rust, for starters, it actually has a standard ABI.

This is a relatively small concern. Plenty of languages have a standard ABI. It doesn't make them great languages.

All variables are immutable by default.

I fail to understand how this is a good thing. How do you modify a variable passed by reference?

All strings are encoded as UTF8, a minor but delicious property IMO!

This is a plus, given the ever-shrinking world in which we live.

Better type-safety, there is no implicit casting of built-in types

I'd consider that a bad thing. No automatic promotion of int to long? No conversion of any pointer to void*? This seems like a recipe for programmer headaches.

you cannot 'downcast' a pointer from a general type to a specific type like in C/C++.

Never? I realize that using RTTI and dynamic_cast can be a sign of poorly-designed code, but sometimes it is actually necessary, and if there's no mechanism to achieve that, then this language is clearly deficient.

Forgive me, but this smells a bit like something an old and dusty C++ programmer would say. We'd still be using FORTRAN if this was the prevalent frame of mind.

No need to start hurling insults. C++ has gotten much better with the last update (C++11), and promises to improve even more with the next minor update. This is akin to saying "the first automobile was slow, noisy, and inefficient, so let's stop making cars, and make something else."

Errr, if this was true then race conditions wouldn't be a problem would it? Just some good library additions and then that is fixed.

Every system that supports concurrency has the potential for race conditions. It is a rather immutable law of concurrent programming.

Well concurrency and race conditions are huge problems and they are problems that C++ and other existing systems programming languages have failed to address.

C++ has made progress in this area. They added tons of thread support features in C++11. No language feature or library can completely prevent race conditions. The programmer is still responsible for writing code that behaves as expected.

Originally Posted by Elkvis

I think with optimizations enabled, the get(), operator* and operator-> are likely to be inlined, so they become as fast as raw pointers.

Yet somehow the same is not possible with the Rust smart pointers?

This may be helpful, but it does introduce some overhead, no matter how efficient you try to make it.

How so? If it is handled at compile-time then it wouldn't need to be checked at runtime.

This is a relatively small concern. Plenty of languages have a standard ABI. It doesn't make them great languages.

Having a standard ABI doesn't make a language great, not having a standard ABI certainly doesn't either. Which is prefferable?

I fail to understand how this is a good thing. How do you modify a variable passed by reference?

Immutability is a cornerstone of the functional programming philosophy.
Immutable objects are simpler to reason about since you can make assumptions about variables and parameters that could not otherwise be made.
Immutable objects are inherently thread-safe.
They can result in a reduction of memory usage since identical values can reference the same piece of memory. Copying also becomes a simple matter of copying a reference/pointer.

If a variable needs to be changed it has to be declared mutable, in Rust passing it by reference implies transfering ownership of the variable from the caller to the callee. That's my impression of how it works, i'm no good at Rust yet (and i'm not going to be until the language is in a stable state) so i might be wrong.

I'd consider that a bad thing. No automatic promotion of int to long? No conversion of any pointer to void*? This seems like a recipe for programmer headaches. [....] Never? I realize that using RTTI and dynamic_cast can be a sign of poorly-designed code, but sometimes it is actually necessary, and if there's no mechanism to achieve that, then this language is clearly deficient.

As you say, sometimes doing these unsafe things are necessary. In Rust you can wrap any piece of code in an 'unsafe' block, which pretty much turns the language into plain C in the sense that you can do whatever you like, but you'd better be sure you know what you're doing.

No need to start hurling insults. C++ has gotten much better with the last update (C++11), and promises to improve even more with the next minor update. This is akin to saying "the first automobile was slow, noisy, and inefficient, so let's stop making cars, and make something else."

On the contrary? Let's keep making new cars that improve upon previous models! Elysia is the one making the argument that we already have something that works, so why bother improving upon it. No insult was offered, i think all developers -myself included- take a conservative stance on new approaches and technologies from time to time and often that is not a bad thing, but sometimes it can be.

Every system that supports concurrency has the potential for race conditions. It is a rather immutable law of concurrent programming.

Thats fine, but then some systems are more prone to race conditions than others and i think C is one of the worst languages in this regard.

C++ has made progress in this area. They added tons of thread support features in C++11. No language feature or library can completely prevent race conditions. The programmer is still responsible for writing code that behaves as expected.

Hey, i'm not the one that made the argument that this is a non-issue.

Originally Posted by Neo1

On the contrary? Let's keep making new cars that improve upon previous models! Elysia is the one making the argument that we already have something that works, so why bother improving upon it. No insult was offered, i think all developers -myself included- take a conservative stance on new approaches and technologies from time to time and often that is not a bad thing, but sometimes it can be.

My point is:
Instead of reinventing the wheel to make The Wheel 2.0, why not improve the existing wheel? The foundation is already there. It has been tested and used by thousands and thousands over people over many, many years. Its quirks are well known. Its limitations are well known. Its advantages are well known. Compare that to the "new" wheel. How long before we know its limitations, advantages and disadvantages? How long before it becomes "fixed" to the point where it works for most?
Never did I say to stop improving something. I want C++ to keep improving. I don't want it to stop.

I realize that sometimes the foundation is sometimes fundamentally broken and all you can do it patch it to keep it working (*cough* Internet *cough*). However, I do not think C++ is broken in such a way, and I do not see Rust as improving upon any of the broken fundamentals in C++ which cannot be patched in later.

Originally Posted by Neo1

Yet somehow the same is not possible with the Rust smart pointers?
How so? If it is handled at compile-time then it wouldn't need to be checked at runtime.

There still needs to be some run-time checking. If they guarantee pointer safety, then they have to check for valid pointers on every access.

...but you'd better be sure you know what you're doing.

No different from C and C++, or any other language, for that matter.

On the contrary? Let's keep making new cars that improve upon previous models! Elysia is the one making the argument that we already have something that works, so why bother improving upon it. No insult was offered, i think all developers -myself included- take a conservative stance on new approaches and technologies from time to time and often that is not a bad thing, but sometimes it can be.

My point was that C++ has improved greatly, because it has been improved over the years, and because people didn't just give up on it. If everyone listened to people like Linus Torvalds, there would be no C++. The first version of anything is always going to be a little rough. You can't just abandon it because it doesn't perfectly suit your needs when it's first created. I like the idea of new languages. They can help to steer the older languages in the direction that the world is heading, but it doesn't mean we have to give up the old ones too.

Thats fine, but then some systems are more prone to race conditions than others and i think C is one of the worst languages in this regard.

I'll definitely agree with you on C. It has practically no safety at all.

Originally Posted by Elkvis

There still needs to be some run-time checking. If they guarantee pointer safety, then they have to check for valid pointers on every access.

No, a borrowed reference to a value can never live longer than the value itself, this is enforced at compile time. At runtime, everything just lines up because if it didn't, then the program wouldn't have been succesfully compiled.

See:
Featherweight Musings: Rust for C++ programmers - part 5: borrowed references

Originally Posted by Elysia

You have to consider the fact that new languages need to mature, too. C++ is a big language. How long is it going to take Rust to get to the same point while fixing the fundamental weaknesses? I don't think C++ is fundamentally broken and needs fixing. I also don't see what Rust truly offers that makes it "so much better" that it warrants replacing other "mature" languages.

There are plenty of advantages, if better type-safety and memory-safety without the massive performance-hit and loss of control you get with GCs are not enough to convince you, then i'm not entirely sure anything actually could?

Rust fixes many of the fundamental weaknesses of C++, for example, it doesn't contain the entirety of C within the core language.

Originally Posted by Neo1

There are plenty of advantages, if better type-safety and memory-safety without the massive performance-hit and loss of control you get with GCs are not enough to convince you, then i'm not entirely sure anything actually could?

Where does it say C++ uses garbage collection? If you are referring to C#, Java, etc, then I see an alternative to those languages if you absolutely must not have garbage collection: C++.
I saw few examples: no implicit casts of built-in types (I'd consider no implicit downcasts and signed/unsigned casts to be advantages; anything else is probably mostly noise) and more compile-time memory safety. That's great. But is it enough? My answer is a deterministic: no.

Rust fixes many of the fundamental weaknesses of C++, for example, it doesn't contain the entirety of C within the core language.

That a subset of C is still part of C++ is not a fundamental weakness because you don't need to use it. Sure, you could argue that because it is there, other problems arise, such as the need for compatibility, making sure that new stuff works with the C subset, etc. However, even so, I do not consider it a fundamental weakness. Every language that evolves has some old, deprecated style, libraries, classes, etc. You need to make sure you don't break compatibility with such code, and you need to make sure new stuff works with old stuff because that's what compatibility is all about. If you don't have that problems, then your language is broken because software stays around for a long time. Rust may not have it yet, but it will. So if you, give some other example. I will not cede to that one you gave.