This kills the rustfag

Programming with the borrow checker is like pair programming with an autist
>you can't take two pointers to the same array REEEEEEE

Attached: rustarded.png (861x359, 51K)

LMFAOOOOO WHO DID THIS

Multiple mutable legacy pointers are the root cause of data-race. This is a good use case for reference counted pointer.
Use Rc for single threaded and Arc for multi-threaded operations.

t. D/C++ fag.

>Oh nice datastructure but you need write your own GC on rust or use unsafe rust as C

why would I reference count pointers that have a lexical lifetime.

>orange crab bad!

Attached: 1536410196291.png (264x274, 30K)

thats literally one of the features of the language..
dont like it? dont use it. so fucking simple. youre the autist one tbqh

>give criticism of a movie
>well why did u watch the movie then if u don't like it

>completely normal valid code doesn't compile
>it's a feature!

Attached: froto.jpg (400x286, 62K)

>dont like the movie genre / setting
>watch it anyway
>complain that didnt like it

>this is valid code on X language
>should be valid in Y language too!

fucking zoomers are so retarded

Explain why you think that's acceptable. We're taking two references to different elements of the array, they both go out of scope at the same time, they both live in the same scope and aren't passed to a different function.
Literally nothing can go wrong.

Why can't I have multiple mutable references if I'm not using threads at all?
Why can't I have multiple mutable references *to different areas of memory* just because they happen to be stored in the same array?

if youre really interested and not just trolling read about rust lifetimes. its literally the reason why it doesnt work.

The borrow checker is the only thing keeping me from using Rust beside the immaturity. Everything else is better designed than C++.

split_at_mut

>>you can't take two pointers to the same array REEEEEEE
this totally illustrates the mind of every C/C++ programmer, like having a bunch of different variables pointing to the same memory is a good thing. Pointers in general are not good for anything beyond making a variable pass by reference. C/C++ programmers delude themselves into thinking that pointers give some kind of special access or control over memory, using pointer arithmetic and unchecked pointer assignment is just more reasons why C/C++ are unsafe languages. C/C++ programmers are going to be pretty embarrassed to find out all that pointer passing is just a shell game for suckers that offers nothing beyond regular variables.

>having a bunch of different variables pointing to the same memory is a good thing
they are not pointing to the same memory.

C developer here, it was officially decreed in a /dpt/ a few days ago that Haskell and C are officially friends. Is there a Haskell developer here? Should we take Rust into the fold?

>reference counting a pointer with obvious lexical scope
Yep, confirmed C++ user

This is an asinine example, but there are definitely some times when the borrow checker flips shit over things that are safe in all practical cases. However, this kind of behavior is vital in a highly concurrent environment, which is what Rust is designed for.

Distinct array elements don't overlap you cretin.

Haskell, C and Racket here. Rustfags get gassed.

They're mutable pointers you ape. If you add 1 (or 4, whatever) to ref_a, suddenly both pointers are pointing at the same thing.

Fair enough, you seem to feel strongly so I'll let it go. I think Rust is pretty rough around the edges but there's some really good ideas in there.

Rust references don't support arithmetic, unless I am mistaken. You need an array ref or a slice to do that.

The good ideas are those lifted from Haskell. The borrow checker is what holds Rust back - it needs to be much more granular for Rust to be ergonomic.

>playpen
>compiling playground

HAHAHAHHAHAHAA STOP,PLEASE STOP IM CRYING FROM LAUGHTER I CANT TAKE THIS ANYMORE THIS SHIT IS LITERALLY MADE FOR OVERPROTECTED MILLENIALS HAHAHAHAHHAHAA

>what are dataraces

There can't be a datarace here because there is only a single thread.

>OMG, he's not stuck using 1970s technology, wow, what a millenial, I'll bet he cant even use makefiles lol

I love how NPCs immediately spout out data races in an example that is single threaded. Jow Forums is really pajeet central these days.

>Multiple mutable legacy pointers are the root cause of data-race
No they aren't.

>data-race
dude its just 4 lines of code, how is it going to cause any type of data race?
That piece of code is clear as piss water but even then Rust wont allow to implement it because its to dangerous lmao

>be embeddedsystemsfag
>make as much as a rustkiddo or javascriplet but don't have to live in faggy cities and get to constantly travel to industrial sites and factories

Yes and there's no need for comments or multiple files in a 4-line toy example program either, but you still want those things to be features in your language

Attached: Screenshot_2018-11-13 [Rust] Iterator invalidation vector int x; x push_back(1); x push_back(2); x p (1876x1956, 198K)

...

the non "pointers make me feel like an EPIC programmer" method
let mut array = [1, 2, 3, 4];
array[1] = 9;
array[2] = 9;


guaranteed safe, no overlap, actually existing, etc
struct cant_overlap {
a: i32,
b: i32,
c: i32,
d: i32
}

// and then
let mut s = cant_overlap { a: 1, b: 2, c: 3, d: 4 };
let ref_b = &mut s.b;
let ref_c = &mut s.c;
*ref_b = 9;
*ref_c = 9;


>but i want multiple pointer to multiple random elements for no reason in a safety oriented language
// then you use
unsafe { }
// .. because that's what it is

>iterator invalidation
iterators could and should be designed to work with arrays that can mutate during the iteration. Go even does it with map iterators where it's slightly harder.
>undeterministic dereferencing
A panic, just like calling unwrap on none (implemented by catching the segfault)
>enum
don't allow mutable references to enum fields

>just don't allow mutable references to enum fields
That's even stricter than Rust

you could also remove enums entirely, they are rarely useful anyway, beyond option types

>sum types aren't useful
no

typical reddit shill

>finding sumtypes makes you a reddit shill
who says Jow Forums can't entertain

Rust haters are actually brainlet NPCs.
>orange crab baaad!
Fuck off, OP.

>too retarded for pointer logic
>calls other brainlets

not the guy you replied to, but Rust has pointers and references, just saying bud

Wait, so the language created by commie SJWs endorses private property and capitalism?

>Pointers in general are not good for anything
Can you be any more retarded? Please go back to JavaScript, so that you can stay away from the scary pointers and multi-threading that you could'n understand, let alone use.

Lifetimes of concurrent shared memory and race conditions can be a bit difficult to get right. However a Rust-style borrow checker is absolutely insane, given that 99% of your code will be unshared data accesses.

>>too retarded for pointer logic
Yes, that describes you. Read , brainlet.

Can you take a language seriously when they use the word playground

On the contrary, they took inspiration from pic related.
The cigar is the data which must be shared one by one, if two at a time try to smoke one suffers burns.

Attached: 3728734723646464.jpg (575x323, 24K)

based and redpilled.

>kills neurons smoking pot
>not being able to reason about simple things, decide to forbid 'unsafe' ops by design.
How would you rustards implement a circular buffer with your joint sharing mindset?