Yea anything big and mainstream just seems super shallow.

I’m not on top of things to compare accurately, but it was always kinda like that (and is like that here sometimes too). But whenever I’ve gone back, I’ve definitely felt like it has gotten somewhat worse. Some of that could easily be a shifting standard from spending more time on other less “mainstream” platforms though.

I imagine the fact that both of those are interpreted languages plays somewhat heavily into it.

Yea I’d imagine so too.

Yep. And then you realise that “move semantics” aren’t just a safety net that you have to “fight with” but actually a language feature against which you can develop/deploy desirable patterns.

A minor thing I noted reading your code snippets was that I immediately noticed, like at a gestalt level, the lack of ampersands (&) and therefore references and could immediately tell that this was a “faux-O”/pipline style system. Not too bad for a syntax often derided as messy/bad.

Personally, I find this incredibly elegant

I’m not entirely sure I understand exactly what you mean here.

Do you appreciate it as an implementation design for the language (I do too)?

Or do you see some utility in being able to call MyStruct::my_method(&my_var)

… or both, cuz there’s something assuring in knowing the simple pattern underneath the syntactic sugar is there?

No worries!

I myself am not on top of the “smart pointers” (yet) … so I’m hoping it’ll be helpful when I go through that just to keep perspective.

I believe you … gate-keeping types are all over the place really.

But vegans or the “vegan-curious” aren’t one thing or one kind of person, at least not any more. I personally have only ever had positive conversations with vegan types.

This instance, in being insistent on not entertaining any “harm reduction” or “compromises”, makes sense though … because it’s a space for people to talk about that sort of dedicated approach.

they drive away potential allies because the concept of harm reduction is anathema to their binary thinking. If you’re not ALL in, you’re the enemy.

I can resonate with that. But I come back to … “it’s totally ok for people to create their own spaces, especially on federated social media and especially for minority groups/ideas”.

There are likely plenty of other spaces for “potential allies” to engage and talk about veganism if they want to, or plenty they, or you, could make on their own.

Tacitly admitting that vegans are usually antisocial zealots. “It’s right in the name!”

Well, they’re running their own social media platform, so I’m not sure how anti-social they are.

Right. Well, I think the instance name “vegantheory.org” was doing that already, and I’m betting you drew your conclusion from the public description of the place too (and aren’t in the modlog or anything for challenging their ideas).

And what would a non-vegan want to do in there?

What’s wrong with minority views and practices creating their own spaces?

On which, is there any non-vegan/anti-vegan thought or idea that a vegan is likely to have not heard already? How many haven’t they heard relative to the amount of decent “pro-vegan” ideas they also haven’t heard of?

Maybe a specialised space, echo chamber even, makes sense in order to balance against the gravity of the mainstream?

I’ve peaked at that issue a couple of times, but I never worked out what the issue/feature got stuck on. Naively I would have thought it a relatively workable feature to add.

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

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.

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?