Q1

/// Makes a string to separate lines of text, 
/// returning a default if the provided string is blank
fn make_separator(user_str: &str) -> &str {
    if user_str == "" {
        let default = "=".repeat(10);
        &default
    } else {
        user_str
    }
}

When compiling, what’s the best description of the compiler error?

1. user_str does not live long enough
2. function make_separator cannot return two different references
3. function make_separator cannot return a reference of type &str
4. cannot return reference to local variable default

Q2

/// Makes a string to separate lines of text, 
/// returning a default if the provided string is blank
fn make_separator(user_str: &str) -> &str {
    if user_str == "" {
        let default = "=".repeat(10);
        &default
    } else {
        user_str
    }
}

Normally if you try to compile this function, the compiler returns the following error:

error[E0515]: cannot return reference to local variable `default`

 --> test.rs:6:9

  |

6 |         &default

  |         ^^^^^^^^ returns a reference to data owned by the current function

Assume that the compiler did NOT reject this function. Which (if any) of the following programs would (1) pass the compiler, and (2) possibly cause undefined behavior if executed? Check each program that satisfies both criteria, OR check “None of these programs” if none are satisfying.

• None of these programs

// 1
let s = make_separator("");

// 2
let s = make_separator("");
println!("{s}");

// 3
println!("{}", make_separator("Hello world!"));

Q3: How fix

Of the following fixes (highlighted in yellow), which fix best satisfies these three criteria:

• The fixed function passes the Rust compiler,
• The fixed function preserves the intention of the original code, and
• The fixed function does not introduce unnecessary inefficiencies

1:

fn make_separator(user_str: &str) -> &str {
    if user_str == "" {
        let default = "=".repeat(10);
        &default
    } else {
        &user_str
    }
}

2:

fn make_separator(user_str: String) -> String {
    if user_str == "" {
        let default = "=".repeat(10);
        default
    } else {
        user_str
    }
}

3:

fn make_separator(user_str: &str) -> String {
    if user_str == "" {
        let default = "=".repeat(10);
        default
    } else {
        user_str.to_string()        
    }
}

fn make_separator(user_str: &str) -> String {
    if user_str == "" {
        let default = "=".repeat(10);
        default
    } else {
        user_str.to_string()        
    }
}

Q4: Method and Ownership

• What best describes the compiler error

/// Gets the string out of an option if it exists,
/// returning a default otherwise
fn get_or_default(arg: &Option<String>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.unwrap();
    s.clone()
}

1. arg does not live long enough
2. cannot move out of arg in arg.unwrap()
3. cannot call arg.is_none() without dereferencing arg
4. cannot return s.clone() which does not live long enough

Q5

• Which programs would pass the compiler (presuming this function, from above, passes too) and possibly cause undefined behaviour?

/// Gets the string out of an option if it exists,
/// returning a default otherwise
fn get_or_default(arg: &Option<String>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.unwrap();
    s.clone()
}

Options:

• None of these programs

// 1
let opt = Some(String::from("Rust"));
let s = get_or_default(&opt);
println!("{}", s);

// 2
let opt = Some(String::from("Rust"));
get_or_default(&opt);

// 3
let opt = Some(String::from("Rust"));
get_or_default(&opt);
println!("{:?}", opt);

Q6: Fixing

Of the following fixes (highlighted in yellow), which fix best satisfies these three criteria:

• The fixed function passes the Rust compiler,
• The fixed function preserves the intention of the original code, and
• The fixed function does not introduce unnecessary inefficiencies

/// Gets the string out of an option if it exists,
/// returning a default otherwise
fn get_or_default(arg: &Option<String>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.unwrap();
    s.clone()
}

1:

fn get_or_default(arg: &Option<&str>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.unwrap();
    s.to_string()
}

2:

fn get_or_default(arg: &mut Option<String>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.as_mut().unwrap();
    s.clone()
}

3:

fn get_or_default(arg: Option<String>) -> String {
    if arg.is_none() {
        return String::new();
    }
    let s = arg.unwrap();
    s.clone()
}

4:

fn get_or_default(arg: &Option<String>) -> String {
    match arg {
        None => String::new(),
        Some(s) => s.clone()
    }
}

deleted by creator

Also, if you REALLY want a chilling thing she says, go find the part where she says they may eventually allow people to customize the moral and political views of their chatbots on top of a standard framework, and she specifically mentions allowing churches to do that.

eeeesh.

I’m with you on that.

That all makes sense. Thanks! I was tempted to watch the whole interview but realised I didn’t actually care that much. I figured something like what you describe was where she was going just from the clip I watched, and of course it was obvious that rage baiting was going on here.

And exactly what you said … many listening to the full interview will probably think she, and therefore AI generally, is actually “right” and will be valuable … except for all the shitty ways it’s gonna be used by corporations and all of the shitty and presumptive things OpenAI and others will do to win their new platform war.

So, to be fair, the line after the quote refers specifically to those that produce “low quality” output.

So a charitable but not unreasonable read might be that she’s saying any creative role that’s easily replaced with AI isn’t really a loss. In some cases, when we’re talking about artists just trying to make a living, this is really some vile shit. But in the case of email monkeys in corporations and shitty designers and marketeers, maybe she’s got a point along the same lines as “bullshit jobs” logic.

On the other hand, the tech industry’s overriding presumption that disruption by tech is a natural good and that they’re correctly placed as the actuators of that “good” really needs a lot more mainstream push back. It’s why she felt comfortable declaring some people in industries she likely knows nothing about “shouldn’t exist” and why there weren’t snickers, laughter and immediate rebukes, especially given the lack (from the snippet I saw) of any concern for what the fuck happens when some shitty tech takes away people’s livelihoods.

If big tech’s track record were laid out, in terms of efficiency, cost, quality etc, in relation to the totality of the economy, not just the profits of its CEOs … I’m just not sure any of the hype cloud around it would look reasonable anymore. With that out of the way, then something so arrogant as this can be more easily ridiculed for the fart-sniffing hype that it so easily can be.

Every browser released since 2020 supports this

It’s a little paranoid of me, but I like the idea that a basic web app I make can be thrown onto any old out of date machine, where ~2015 or younger seems about right for me ATM.

You mean the Html template Element? I’ve never really got that to work, but I also never seriously tried.

Yea. From memory, it’s just an unrendered chunk of HTML that you can select and clone with a bit of JS. I always figured there’d be a pattern that isn’t too much of a cludge and gets you some useful amount of the way to components for basic “vanilla-js” pages, just never gave it a shot either.

Am I imagining it or has there been a noticeable uptick on the amount media/Hollywood attention on the space race? I suppose it’s always been a point of focus, but with things like this, “For all Man Kind”, “First Man” (film), “Hidden Figures” … I’m wondering if there’s a sort of “Golden Age” preoccupation that’s settled in with the space race?

Yea, I’m unclear on how you can take web components and still have widespread browser support (not knowing enough about their ins and outs).

Plain template elements are widely supported and have been for ~10 years (which ideologically matters to me along the same lines as the top post’s article) … perhaps a little bit of hacking together can get you close with just that?

But nah. These goobers got high off npm modules and did shots of JSX in the bathroom at lunch time.

Fucking LoL!

Anyone here have thoughts about doing basic interactive stuff with at most vanilla JS?

Also, on the topic of “having references as fields in structs” … see this conversation we had here about that.

That conversation started from a post on the users . rust-lang forum, where the ultimate pithy and harsh conclusion about doing this was:

You’re not allowed to use references in structs until you think Rust is easy. They’re the evil-hardmode of Rust that will ruin your day.

😉

Use Box or Arc to store things in structs “by reference”. Temporary borrows don’t do what you think they do.

The problems are wider than that. Besides, relying “individuals just doing the right thing and going a little further to do so” is, IMO, a trap. Fix the system instead. The little thing everyone can do is think about the system and realise it needs fixing.

I’m sympathetic, but to a limit.

There are a lot of academics out there with a good amount of clout and who are relatively safe. I don’t think I’ve heard of anything remotely worthy on these topics from any researcher with clout, publicly at least. Even privately (I used to be in academia), my feeling was most don’t even know how to think and talk about it, in large part because I don’t think they do think and talk about it all.

And that’s because most academics are frankly shit at thinking and engaging on collective and systematic issues. Many just do not want to, and instead want to embrace the whole “I live and work in an ideal white tower disconnected from society because what I do is bigger than society”. Many get their dopamine kicks from the publication system and don’t think about how that’s not a good thing. Seriously, they don’t deserve as much sympathy as you might think … academia can be a surprisingly childish place. That the publication system came to be at all is proof of that frankly, where they were all duped by someone feeding them ego-dopamine hits. It’s honestly kinda sad.

Yep. But that is all a part of the problem. If academics can’t organise themselves enough to have some influence over something which is basically owned and run them already (they write the papers and then review the papers and then are the ones reading and citing the papers and caring the most about the quality and popularity of the papers) … then they can’t be trusted to ensure the quality of their practice and institutions going forward, especially under the ever increasing encroachment of capitalistic forces.

Modern day academics are damn well lucky that they inherited a system and culture that developed some old aristocratic ideals into a set of conventions and practices!

For me, the biggest things to take away from these chapters were:

• Enums and pattern matching
• Borrow checker concerns emerging from these new data structures
• Derivable traits

Enums and pattern matching for the win

• That the pattern matching facility is powerful, and that enums can have associated data, structured independently for each variant … really provides a (relatively straight forward and versatile “happy path” in rust IMO.
  • I tried to hack together a file differ in rust a couple of months ago (see my post on my solution here, mostly in the comments) and found myself just leaning into enums + pattern matching and rather enjoying the process.
• So much so that major (and celebrated?) features of the language such as Option and Result types are really just applications of enums (along with rust’s good type system)

The example in the book of the IP Address enum type is quite a nice demonstration I think:

enum IpAddr {
    V4(u8, u8, u8, u8),
    V6(String),
}

let home = IpAddr::V4(127, 0, 0, 1);
let loopback = IpAddr::V6(String::from("::1"));

We’re still learning “The Borrow Checker”

• Ownership and borrowing concerns are still alive here in their application to structs and enums and what best practices arise out of it all.

Match statements

• In match statements, the concerns are relatively straight forward (I think). Match arms take ownership of the variables they “use/touch” (I’m still unclear on the details there!) …
• so if you want a variable to live beyond the match statement, match on a reference.

EG:

let opt: Option<String> = Some(String::from("Hello world"));

match &opt {
    Some(s) => println!("Some: {}", s),
    None => println!("None!")
};

println!("{:?}", opt);

• There’s a slightly tricky thing that happens implicitly here:
  • Though the match is on &opt, the s in the pattern Some(s) is also a reference because rust implicitly “pushes down” the reference from the outer enum to the inner field or associated data.
  • Seems tricky, but also ergonomically sensible.

Borrowing self in methods

Probably the trickiest and most relevant part of the two chapters

• the self in methods, like any other variable, can be one of three types in terms of ownership:
  • Owned by the method, like a plain variable
  • A reference (&self)
  • A mutable reference (&mut self)

struct Rectangle {
    width: u32,
    height: u32,
}

impl Rectangle {
    fn area(&self) -> u32 {
        self.width * self.height
    }

    fn set_width(&mut self, width: u32) {
        self.width = width;
    }

    fn max(self, other: Rectangle) -> Rectangle {
        Rectangle { 
            width: self.width.max(other.width),
            height: self.height.max(other.height),
        }
    }
}

• What’s tricky about this is that a method’s signature for self has consequences that both reach back to the initial type of the root object (ie, is it mutable or not) and forward to what can be done with the root type afterward.

  • EG, a method that takes &mut self can’t be used on a variable that isn’t initially mutable.
  • EG, a method that takes ownership of self effectively kills the root object, making it unusable after the method is called!!

• I’m sure there are a bunch of patterns that emerge out of this (anyone with some wisdom here?) …

• But the simple answer seems to borrow self, and if necessary, mutably borrow.

• Taking ownership of self is an interesting way to enforce a certain kind of usage and behaviour though.

• As the object dies, the natural return of an owning method would be a new object, probably of the same type.

• Which leads into a sort of functional “pipe-line” or “method chaining” style of usage, not unlike the “Faux-O” idea in Cory Bernhardt’s talk Boundaries. It’s likely not the most performant, but arguably has some desirable qualities.

Derivable Traits

• We haven’t gotten to traits yet, but they come up here.
• Turns out rust has kinda has a system of inheritance for structs where a trait can be easily implemented for a struct “automagically”: #[derive(Debug)]

EG:

#[derive(Debug)]
struct Rectangle {
    width: u32,
    height: u32,
}

• This particular trait, Debug, allows for the printing of a struct’s full makeup with println!.

• All of the “Derivable” traits (from the std lib) are listed in Appendix C of The Book

• There aren’t that many, but they’re useful:

  • Copy and Clone enable a struct to be copied without having to worry about ownership (though you have to be careful about the types of the fields, as its their copy methods that are ultimately relied on)
  • Four traits that implement methods for comparison and equality operators
  • Hash for hashing an object
  • Default for defining default values

• Of course, when we cover traits we’ll learn how to implement them ourselves for our custom types, but these seem to be fundamental features of the language, and easy enough to use right away.