Borrowed value does not live long enough

>It's unironically the future of systems programming.

The same way the toy hammers are the future of carpentry.

Attached: 1535031366052.jpg (1679x586, 164K)

Maybe that one liner was witty and meaningful in your head but in reality it doesn't really make sense.

What's the point in having a borrow checker if you need to circumvent it to do anything useful?

Linked list is not useful.

If you can't make a linked list, you can't make anything more useful.

Why not just weak ref one direction of the list?

>If you can't make a linked list
see

see

see

.unwrap();

Inefficient and ugly.
*node.back.upgrade().unwrap(), yikes

>unsafe blocks don't turn off the borrow checker, they just ignore the borrow checker
if it's not doing anything then it's useless

>if it's not doing anything
It's doing what it's supposed to do, which is statically resolve lifetimes and ownership of resources. The unsafe{} allows you to deference raw pointers. Why are you acting inane?

>It's doing what it's supposed to do, which is statically resolve lifetimes and ownership of resources.
Like the lifetime of pointed-to data. If you're using unsafe to dereference a pointer that the borrow cheker cannot verify the liveness of, you're circumventing the borrow checker.

Attached: brainlet.png (621x702, 56K)

>If you're using unsafe to dereference a pointer that the borrow cheker cannot verify the liveness of, you're circumventing the borrow checker.
That's because it's logically impossible to determine all of the dynamically allocated resources. Your option is to either use a raw pointer, which can be used within an unsafe{} or use a ref-counted pointer, like those used in the Linux kernel. For almost all of general purpose you would use BC with optional ref-counring, which depends on your situation. In my 10+ years of programming (including 4 years of professional) experience I've never once found a pragmatic use of Raw pointers or linked lists. Even if I have to use one, I'd just use the one in the standard library.

Nice self portrait though.

> In my 10+ years of programming (including 4 years of professional) experience I've never once found a pragmatic use of Raw pointers or linked lists. Even if I have to use one, I'd just use the one in the standard library.
Maybe you're just not a systems programmer then. The ability to make and use bespoke, hand-optimized data structures is required for systems programming - and Rust's poor support for this makes it poorly suited for ousting C and C++ from this domain.

>hand-optimized data structures is required for systems programming
Misconception. This is because C lacks generics, you "hand optimize" it in order to accommodate the lack of polymorphic traits/types.

>In my 10+ years of programming (including 4 years of professional) experience I've never once found a pragmatic use of Raw pointers or linked lists
raw pointers are faster than ref counted, so there's literally millions of places where that is relevant
linked lists are useful when you have a collection of objects that needs to be iterated through with frequent insertions and deletions

Parametric polymorphism and standard data structure libraries exist in C++. It does not solve this problem. Nothing is generic enough to achieve the ideal performance characteristics in every circumstance. That's a consequence of being generic. So designing data structures that suit the needs of your application and then making them remains routine for systems programming in C++.

Talk is cheap
>linked lists are useful when you have a collection of objects that needs to be iterated through with frequent insertions and deletions
Often out-weighed by the lack of cache locality. That's just how processors work.
Give me 1 (ONE) case where you have to "hand optimize" and std::forward_list from std::forward_list and then we talk.

>Often out-weighed by the lack of cache locality. That's just how processors work.
So you make an unrolled linked list. Your cache miss rate will go down roughly proportionately to the number of elements you can fit in a single cache line, and you still keep the cheap insertions and deletions.
It's clear now that anybody who sees no need to design data structures also has no idea how to do it.

>Often out-weighed by the lack of cache locality
not really, if you have more than a few dozen items, people are really starting to overstate the importance of cache locality

seriously though, even though I know that linked list is used extensively in linux kernel, but what is the advantage of using linked lists over just vec! in Rust

I just said it, frequent insertions and deletions
there is a trick you can do to make a vector almost act like a linked list with O(1) deletion time but it doesn't retain ordering

Tranny language. Avoid keep using cpp.

Opposite experience in reality, in production and in statistics.
channel9.msdn.com/Events/GoingNative/GoingNative-2012/Keynote-Bjarne-Stroustrup-Cpp11-Style

Attached: mlOzJ.png (971x644, 51K)

brainlets hate it because 'muh sjw boogeymen', c/c++ devs are too far into the sunk cost fallacy that they're getting stockholm syndrome, most normal developers hate it because it's too complicated compared to cucked languages like go/c# for simple applications or utilities

if you want to be redpilled then all you really need to know is that veteran c programmers like ESR, who admittedly HATE rust, still accept that it's a fine language for kernels/drivers

do you have any links to this experiment which dont require me to watch a video?

youtube.com/watch?v=OB-bdWKwXsU

>Vectors have `O(1)` indexing, amortized `O(1)` push (to the end) and `O(1)` pop (from the end)

github.com/rust-lang/rust/blob/master/src/liballoc/vec.rs

tox is being rewritten in it

Vectors have O(n) random insertion and deletion, which is the advantage lists have

I don't mean to say that it's a terrible language for 'applications' but there is a reason why people prefer easy languages like go

thats a video

stl is the proverbial hammer that makes you see nails and is also unacceptable for embedded applications unlike the good low level languages (C, Java)

nm I just found a description of the experiment, it's doing a huge amount of iteration, which is obviously the strength of a vector, the strength of a list is being able to O(1) delete from the middle

fuck rust, overly complicated for no reason

you can't abstract away complicated things no matter how hard you try

think its just the protocol
they have a bunch of guis doing their own thing

Rusts biggest achievement is creating a language that looks uglier than c++

Linked lists are often used without being a linked list type, for example parent-child relationship, often used in gui systems

>systems programming
No such thing.

Rustlet here, what's stopping someone from implementing a drop on the list and its nodes that manually unlinks nodes to break the reference cycle?

That guy was just trolling, he's never written a line of Rust or even read a line of the documentation.