Any memelang programmers in the house?

Any memelang programmers in the house?
use std::vec::Vec;
use std::rc::Rc;
use std::cell::RefCell;

fn main() {
let s = Rc::new(RefCell::new(128));
let t = s.clone();
let u = s.clone();

println!("{}", *(s.borrow()));

*(t.borrow_mut()) = 256;
println!("{}", *(s.borrow()));

*(u.borrow_mut()) = 512;
println!("{}", *(s.borrow()));
}

>this compiles and works as expected
What did Rust mean by this? I thought I wasn't supposed to have multiple mutable references. Whatever it was trying to stop me from doing with its borrowing rules can obviously be done that way, so what is the point?

Other urls found in this thread:

play.rust-lang.org/?gist=309fd29a7b2203b98e661b83acdf0018&version=stable
doc.rust-lang.org/stable/book/first-edition/references-and-borrowing.html#the-rules
twitter.com/SFWRedditGifs

Which esoteric language is this?

Rust

>curly braces
>esoteric
Not every memelang is esoteric.

you dont have multiple mutable references. the references are destroyed after the expr evals

>b-b-b-but technically
I have multiple handles on the same piece of data, and I can mutate it through each one at will. It is effectively the same thing as having multiple mutable references except for the ugly syntax and superfluous reference counting, so what's the point of the restrictions? It only makes code uglier.

>Rust
why anybody would use anything other than Go for systems programming is beyond me

performance, mostly.

>Go
Why anyone would bother with Go over C is beyond anybody sane. At least Rust has some interesting features.

i guess, though benchmarks are all over the map depending on the computation. Go's getting faster though.

I find Go elegant and easier to write and maintain, more so for large projects. It also has a nice ecosystem and tools.

I had no idea R was such an interesting language

Array

Go is an example of a language that compiles to native code, but which is NOT a systems language. And so long as it has a mandatory garbage collector, it can never be a systems language, because it is restricted to hosted environments where there is an assumption about how memory is allocated to begin with.

Why Rust syntax is to shitty?

Start as OCAML variation, some autist want remove GC with weird memory model.

>I find go elegant
were you dropped on your head as a child?

desu this is my main problem with rust too; i love it otherwise

but on the other hand i can't think of many ways to improve the syntax, aside from dropping "::" (seriously, kill "::" with fire in all languages) and annotating lifetimes with literally anything other than "'"

With pointers and a bit of unsafe code you can opt-out of all of Rust's safety guarantees

>With pointers and a bit of unsafe code
But this doesn't use pointers or unsafe code, and it still does something that should not be done according to Rust's designers. What's the point of having such a restriction if it's so easy to work around (at the cost of ugly code), especially given how often you do have to work around it?

What is the problem here? It looks like the compiler was able to prove you aren't doing anything naughty with those references. Now try to split this code into functions/run it in different threads and see what happens.

>It looks like the compiler was able to prove
The compiler wasn't able to prove anything. RefCell does the borrow checks at runtime. As far as the compiler is concerned, these are all non-mutating references, except for the borrow_mut bits (which die immediately after use).

This is the whole point of RefCell. Instead of checking borrow rules at compile-time, it does it at run-time, which in this specific program didn't cause problems.

Thanks for the correction. I've just started learning Rust myself.

That's what you use RefCell for, it's for interior mutability.

The borrow checking is done at compile time, you'll get a panic if you have an active `cell::Ref` when you call `borrow_mut()`. You have to uphold those invariants yourself.

What's your point?

Both the compile-time and the run-time borrow checking is circumvented in that snippet. There are effectively 3 mutating references in that snippet, all munging the same piece of data.

>std::vec::Vec
>std::rc::Rc
>std::cell::RefCell
>let s = Rc::new(RefCell::new(128))

I thought rust was supposed to be less verbose than sepples, but that shit is just unnecessary.

>let s = Rc::new(RefCell::new(128));
>auto s = std::make_shared(new Box(123));
Sepples loses out even in this example.

There aren't you dimwit.

Except you're ignoring the using clause in the beginning and you're using make_shared wrong (you're supposed to use it instead of new).

auto s = make_shared(Box(123));

>Go for systems programming
TOP KEK

>There aren't
Then how come I can modify the same piece of data through multiple different handles that coexist, subhuman? You can make as many mutating references as you like. This is an objective and undeniable fact. Rust's rules are just blind to this fact because the language was designed by retards, for retards.

play.rust-lang.org/?gist=309fd29a7b2203b98e661b83acdf0018&version=stable
>click on the mir button
>show me the portion where there are two mutable borrows
>realize you can't
>kill yourself

>using using

pls

If Box's constructor isn't declared as explicit, you can even do this:

auto s = make_shared(123);

DELED TIS

Rust shills BTFO.

Rust has some nice features but it doesn't have many libraries. I wish Qt were ported successfully into Rust

It was never supposed to be less verbose than C++, verbosity is never taken into consideration in the designing, explicitness on the other hand...

>verbosity is never taken into consideration in the designing
Good thing nobody outside of a small group of circlejerking memers is going to have to deal with this language.

I'd rather have a bearably verbose and barely implicit language than a bearably verbose and barely explicit language.

Too bad Rust is unbearably verbose, unbearably implicit and overall poorly thought out, as demonstrated by my original post.

Tell me more.

I think this demonstrates quite well both how ugly it is and how poorly thought out it is:
use std::rc::Rc;
use std::cell::RefCell;

struct Boxed {
rcc_data: Rc
}

struct MutatingRef {
rcc_data_ref: & 'a Rc
}

impl Boxed {
fn new(value: T) -> Boxed {
return Boxed:: {
rcc_data: Rc::new(RefCell::new(value))
};
}

fn borrow_mut(&self) -> MutatingRef {
return MutatingRef:: {
rcc_data_ref: &self.rcc_data
};
}
}

impl {
fn read(&self) -> std::cell::Ref {
return self.rcc_data_ref.borrow();
}

fn write(&self, value: T) {
*self.rcc_data_ref.borrow_mut() = value;
}
}

struct Trash
}

fn mutate_trash(trash: &Trash, x: i32) {
trash.data.write(x);
}

fn main() {
let v = Boxed::new(123);

let trash1 = Trash {
data: v.borrow_mut()
};

let trash2 = Trash {
data: v.borrow_mut()
};

mutate_trash(&trash1, 55);
mutate_trash(&trash2, 66);

println!("{} {}", trash1.data.read(), trash2.data.read()); // Ooops!
}

>fn borrow_mut(&self)
nice try faggot.
doc.rust-lang.org/stable/book/first-edition/references-and-borrowing.html#the-rules
those rules, even in your contrived example intended to confuse, are still not broken

You're subhuman. Anyone can run the code and see two handles that coexist and can be used at any time to change the same data.