Rust

[wtd]

So, any compsci.ca members programming in Rust these days?

[SNIPERDUDE]

Haven't looked too much into Rust, what are it's strengths?

These days I'm pretty much just using Godot (gdScript, based on python)

[scholarlytutor]

I've been hearing more and more about Rust and it looks interesting. But since I'm more interested in old software, C and C++ are more relevant for me. Do you program in Rust?

[wtd]

I have dabbled, as is my wont. So far the details of lifetimes are kicking my butt.

To me it looks like OCaml because it incorporates a lot of ML-y fucntional programming ideas about type inference, pattern-matching, etc. But without garbage collection, in many ways it's worse.

I guess the best way to think about it would be a modern, better C or C++ replacement, since the lack of garbage collection makes it better suited for low level system programming than a lot of other modern programming languages.

[wtd]

I have dabbled, as is my wont. So far the details of lifetimes are kicking my butt.

To me it looks like OCaml because it incorporates a lot of ML-y fucntional programming ideas about type inference, pattern-matching, etc. But without garbage collection, in many ways it's worse.

I guess the best way to think about it would be a modern, better C or C++ replacement, since the lack of garbage collection makes it better suited for low level system programming than a lot of other modern programming languages.

[scholarlytutor]

Yes, that’s what I’ve heard too, using Rust as an alternative to C/C++. It’s safer to use Rust because I believe it’s easier to avoid problems like memory leaks, but it also has better speed than most higher level languages (though I’m guessing it’s not quite as fast as C).

Apparently there are people in the Linux community who really like it. There’s some talk about writing the Linux kernel in Rust; right now it’s written in C.

[wtd]

The compiler is very strict, especially about memory issues. It uses the concept of lifetimes to manage access to memory. It's precisely this that kicks my butt.

[SNIPERDUDE]

Definitely adds a twist I'm not used to. May play around with it a bit over the weekend

[wtd]

Good! Be sure to share. Maybe we can help each other.

[scholarlytutor]

That's interesting, so the compiler forces you to solve any memory issues.

Maybe I'll take a look at Rust too, though I doubt I know as much about memory management as you guys do. And I know absolutely nothing about lifetimes.

[wtd]

Judging from my difficulties, I don't know anything either!

[wtd]

But seriously, consider the following in C.

c:

#include <stdio.h> int foo() {     int x = 42;     return x; } int main() {     int y = foo();     printf("%d\n", y); }

No issues because while the lifetime of x is limited to the function foo, it's returned by value. A copy of x is made, x dies, and that copy lives on.

But what about:

c:

#include <stdio.h> int *foo() {     int x = 42;     return &x; } int main() {     int *y = foo();     printf("%d\n", *y); }

Uh oh. We're trying to return the address of a value whose lifetime has ended. This invokes undefined behavior. A good compiler will warn about this, but it will still compile. Because the behavior is undefined, it might even work sometimes. But it might not, and that leads to bugs.

So let's look at two samples of Rust code that approximate these C examples.

code:

fn foo() -> u32 {     let x = 42u32;     x } fn main() {     let y = foo();     println!("{}", y) }

The above works just fine. Everything is done by value, and copying and lifetimes have no bearing on the process.

code:

fn foo() -> &u32 {     let x = 42u32;     &x } fn main() {     let y = foo();     println!("{}", *y) }

This one? Not so much. In this case foo is specified to return an unsigned 32-bit int by reference. It attempts to do that by "borrowing" x and returning it, but x dies when the fu\nction returns. This behavior in C has bad ramifications but the compiler allows it. In Rust, the compiler errors out.

code:

error[E0106]: missing lifetime specifier  --> test2.rs:1:13   | 1 | fn foo() -> &u32 {   |             ^ expected named lifetime parameter   |   = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from help: consider using the `'static` lifetime   | 1 | fn foo() -> &'static u32 {   |             ~~~~~~~~ error: aborting due to previous error For more information about this error, try `rustc --explain E0106`.

The 'static lifetime is a bad idea. This means it lasts until the end of the program. Works for such a small program, but in bigger programs this could create excessive memory usage.

We can try adding an explicit lifetime to the value...

code:

fn foo<'a>() -> &'a u32 {     let x = 42u32;     &x } fn main() {     let y = foo();     println!("{}", *y) }

But that won't compile because we're still trying to return a reference to memory owned by the function foo.

Instead we apparently (I'm still learning) use a Box to create a smart pointer, and dereference it with *.

code:

fn foo() -> Box<u32> {     let x = 42;     Box::new(x) } fn main() {     let y = foo();     println("{}", *y) }

Unless otherwise specified, bindings in Rust are constant. So let's mark something as mutable.

code:

fn foo() -> Box<u32> {     let x = 42;     let mut z = Box::new(x);     *z += 2;     z } fn main() {     let y = foo();     println("{}", *y) }

Now this should print 44. But bear in mind that y is still constant, so we can't mutate that further without marking it mutable.

[SNIPERDUDE]

wtd @ November 15th 2021, 2:13 pm wrote:

More to come

Hope so, been quite informative thus far