[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology


Thread archived.
You cannot reply anymore.


[Advertise on 4chan]


File: hq720-2.jpg (28 KB, 686x386)
28 KB
28 KB JPG
I keep falling in love with this lang like you wouldn't even believe anon. Holy shit it's beautiful. Sexy even.

https://youtu.be/SMCRQj9Hbx8?si=S9cQ1x-7fThc9Q5N
>>
>>107472495
>this code does magic that you cannot see!
magic is bad
just use C
>>
No.
>>
File: Tohru.jpg (1.48 MB, 1708x2600)
1.48 MB
1.48 MB JPG
>>107472495
Is Rust a maid language? It seems like a language for maids.
>>
buy and add
>>
>>107472875
>anon discovers functions
>>
>>107472495
>Holy shit it's beautiful. Sexy even.

He's about to troon out and chop his dick off. Screen cap dis
>>
Any language feature that makes a line of code do anything other than what it looks like it's doing (chiefly macros and operator overloading) is bad and one corpse on the pile of reasons software is so slow.
>>
>>107473031
in teal languages you can read whats in the funcitons you use
>>
Oh you like Rust?
Explain Pin interface without words words words.
>>
>>107473170
Makes a type immovable unless you Unpin.
>>
>>107473161
You can literally just see the code a macro generates too. It's not magical or anything.
>>
>>107473197
This doesn't explain anything.
>>
File: rust.png (114 KB, 627x722)
114 KB
114 KB PNG
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
https://bpb-us-e1.wpmucdn.com/sites.gatech.edu/dist/a/2878/files/2022/10/OSSI-Final-Report-3.pdf
https://archive.ph/uLiWX
https://archive.ph/rESxe
https://lkml.org/lkml/2025/2/6/1292
https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12464988
https://lwn.net/Articles/1030517/
https://github.com/lcnr/solver-woes/issues
>>
File: rust2.png (296 KB, 1080x1080)
296 KB
296 KB PNG
>>107473501
>>
File: rust3.jpg (220 KB, 989x630)
220 KB
220 KB JPG
>>107473509
>>
>>107472495
>Sexy even
on what stage are you on?
long hipster hair? cute long girly socks? or feminizing surgery?
>>
File: rust4.jpg (400 KB, 993x1094)
400 KB
400 KB JPG
>>107473522
>>
>can't explain Pin still
Is this it?
The great midwit filter?
>>
>>107472495
Remember to dilate.
>>
>>107473548
You are describing yourself, midwitted, zero-IQ, lying, completely retarded, negative-worth, demented troll.
>>
>>107473621
Hi Alkeryn.
>>
>>107472875
>just use C
Wait until you find out that C has macros and functions. They don't work very well and Ctrannies are triggered that they exist, but it has something called macros and functions, that Ctrannies at one point tried to claim were features.
>>
File: Rust mental illness.jpg (431 KB, 852x1261)
431 KB
431 KB JPG
Jeremy Bicha.
>SEX BAT BY JUVEN/VCTM UNDER 12; F.S. 794.011(2) (PRINCIPAL - 2 COUNTS)
Pedophile.
Rust developer.
PPA for Rust.
https://launchpad.net/~jbicha/+archive/ubuntu/rust

Mental health, pronouns and alter egos are at the very least trends in Rust. Also as the community Rust Discord server goes.

Hector Martin.
Insisting that Asahi Lina is not his alter ego.

https://aturon.github.io/tech/2019/06/25/back-in-the-saddle/

https://fasterthanli.me/articles/state-of-the-fasterthanlime-2024
https://fasterthanli.me/articles/that-health-is-mental
>>
>>107473737

https://wiki.ubuntu.com/JeremyBicha
>I am a United States Navy Veteran and spent 2007-2010 living in Bahrain. I currently live in Florida. I joined Canonical in 2022 but my Ubuntu story started much earlier.

https://wng.org/articles/the-high-cost-of-negligence-1617309216
>Florida prosecutors weren’t forgetting: The U.S. Navy discharged Jeremy, and when he reached U.S. soil, authorities arrested him. He eventually pleaded no contest to two counts of sexual battery on a child under 12 while he was under 18. His defense attorney asked for less than a year in the county jail. The prosecutor asked for 15 years in state prison.
>>
>>107472495
If rust is so good, why is everything written in C?
>>
>>107473621
What a strange copycat.
>>
>>107473755
Because C shills are very aggressive about wanting C to take over and replace everything.
>>
>>107472875
>just use C
Cniles back at it again with buffer overflows and arbitrary command execution
https://github.com/libgit2/libgit2/releases/tag/v1.9.2
>>
>>107473755
not even the C compilers (the ones actually used) are written in C anymore
>>
File: 1764023019074027.gif (2.87 MB, 200x234)
2.87 MB
2.87 MB GIF
>>107473785
So... Since those compilers basically run the world, they're obviously written in Rust, right?
Wouldn't want whole world's software risk miscompiling...
>>
>>107473859
Why does it matter what language the backend is written in?
>>
File: laughing alien sluts.png (185 KB, 540x641)
185 KB
185 KB PNG
>>107472495
>Rust is beautiful
>this macro runs [code that isn't the rust programming language]
>>
>>107473891
kinda the whole point of metaprogramming, it allows to add features that are not in the language.
i've seen cniles attempt doing it for C and it was either some preprocessor vomit, or they'd parse their whole codebase with python to output some transformed c file that'd then be compiled.

metaprogramming being built into the language is miles better than preprocessor trash or having to (badly) parse the language to transform it.
with rust you can access and modify the AST directly, it's not as powerful as lisp macros but it's realy close.

also a proc macro can run literaly any code, this is used by crate like sqlx to allow static checking of your sql queries against your database tables at compile time (this is an optional feature obviously).
>>
>>107473282
> This doesn't explain anything.
only if you are a nocoder.

pin, as it says, pins an object in memory such that references to it stay valid until it is unpinned, this essentialy allows to guarantee that a reference will stay valid until it is unpinned and can be useful for many things.
>>
>>107473652
alkeryn here, i just arrived on this thread
those are my posts :
>>107474280
>>107474292

i'd not repeat a modification of your garbage comment, it's not even a good insult.
i think you are confused, i came back to the other thread to see that you argued for hours with other people thinking they were me lmao.
>>
>>107473548
>>107473621
>>107473652
is this a samefag ?
>>
>>107473509
linked lists aren't efficient thoughbeit
>>
>>107473509
>>107474363
linked list are trivial to write in rust, both with and without unsafe.
this is not the W cniles think it is lol
>>
>>107473785
anon, do you use rustc or cranelift for final build...?
>>
>>107474345
>>107473652
i think i live rent free in your head now, i did like 3 comments and from then on you assumed every posts were from me, i literaly was offline until now.

i'm seriously currious if you are still gonna post my name weeks from now even if i don't go on 4chan whatsoever, i'd honestly find it fun lol
>>
>>107474392
i think you don't understand what cranelift is.
the compilation process does rustc -> llvm ir -> llvm or cranelift -> linker -> executable.

you use cranelift WITH rustc, it's not an alternative to rustc but a replacment for llvm you can use in the toolchain.

rustc can be compiled with rustc using cranelift or llvm as the ir to machine code converter.
>>
>>107474349
Yes.
>>
>>107472875
>magic is bad
All code is magic. Even the CPU is magic
>>
>>107474292
It's funny, because that's not what it does, but you're such a low IQ nocoder that you couldn't help yourself being wrong.
>>
>>107474477
kek, i initialy just shared my repo to show some anon that doing no_std hello world in rust is trivial.
then some schizo started to think every posts after that were mine.
i come back to read a rust thread and see a trillion mentions of my username, or mentions of it in this one where i hadn't even posted yet.
i didn't think it'd matter much to share my gh since it was just to share some code but i should have had the foresight that posts that are not mine would be associated with me.
>>
File: file.png (70 KB, 1229x268)
70 KB
70 KB PNG
>>107474501
it's literaly what the documentation says...
>>
>>107474591
>>107474501
me again, we are talking about Pin, not core pinning if you haven't noticed.
>>
>>107474591
That's not the only thing it says, but it seems like it's the first tike you opened that page, retarded faggot.
>>
>>107474611
> That's not the only thing it says
you precisely asked for a brief explanation without words words words : >>107473170
>>
>>107473161
Well in crimzon languages you can see what a macro generates
>>
>>107474657
rust has macroexpand too
you could even integrate it in your editor if you realy wanted, but generaly jump definition is good enough imo.
>>
>>107474622
I asked for an explanation, not a midwit's headline of what's in the documentation, midwit.
>>
>>107474713
> claim to not understand a feature
> someone explains it
> no that's not what it does
are you just trolling ?
>>
>>107474726
I'm starting to think that you might not be a midwit, but a dimwit.
>>
>>107474733
>>107474713

this was just a perfect explanation, making a type immovable, i gave more detail about the reference thing, what do you want more?
>>107473197
>>
>>107474746
>>107474733
what do you want more, to explain that it allows self referential structures ?
like what do you think is missing from the explanation we gave ?
>>
>>107473170
>TL:DR
A type in Rust that guarantees that the value behind a pointer will not be moved in memory again.

> Moar!!!!
Rust normally moves values instead of copying them.
If a type contains pointers to parts of itself (a self-referential struct), moving it would invalidate those internal pointers. Rust forbids that pattern unless you use something that guarantees a stable address.

That’s where Pin comes in.

Pin<P> says:
>You can move the pointer P around, but you cannot move the value T stored inside

Pin does not magically freeze memory in place, it just prevents moves through safe Rust APIs.
>>
>words words words
>copy pasted even
So you don't understand what Pin does?
>>
>>107474797
nice bait m8
>>
File: 1764987264657240.jpg (456 KB, 1600x1170)
456 KB
456 KB JPG
>rustling troll cannot explain the point of Pin in his own words
>>
>>107474371
linked list are trivial in rust...until you start inserting/deleting anywhere that's not the head/tail.
>>
>>107474816
i said linked list, that includes all of their features.
>>
>>107474813
>>107474805
>>
>>107474371
Feel free to write both variants and post on your goyhub page, alkeryn.
>>
>>107474829
alk here again, i'm not the one that wrote this post >>107474770
i'm the one that made this one :
>>107474805
>>107474827
>>
>>107474813
Anon just play around with the code
>>
>>107474829
>>107474849
also if you read my github profile you'd know that i almost don't use it anymore, the only thing that are still here are my dotfiles and cv.
>>
File: 1764913323319684.gif (496 KB, 540x487)
496 KB
496 KB GIF
>>107472495
Just use HolyC instead
>>
>>107474869
only terry had divine intellect, that doesn't apply to mere mortals like us
>>
>>107474873
True but I'm already know how to code in HolyC
>>
>>107474850
>just play around with undefined behavior bro
>>
>>107473170
Pin is a wrapper around types that can't be moved. Analogous to C++ class without a move constructor.
>>
>>107474884
based
>>
>>107474885
you mean c?
>>
>>107472495
>using variable before it has been declared
cut it out
>>
>>107474902
this is a common pattern in python and in this case i think it's alright because it's scoped to the macro.
the content of the macro is the declaration.
>>
>>107473170
If T: !Unpin then Pin<&mut T> doesn't implement DerefMit<Target=T>
This is basically the whole guarantee
>>
>no anonymous structs
>no anonymous enums
>boxed future shenanigans
>false positives in borrow checker
>lack of useful standardized traits (see pic related, see `num_traits`)
>many useful features seemingly permalocked behind nightly
all this being said, Rust is undeniably the best stable language for systems development.
but Clojure is more comfy for most software.
>>
>>107474891
Except majority of types can be moved?
Why even bother writing this inane drivel if you don't know how Pin works?
>>
>>107474938
> no anonymous structs
> no anonymous enums
usecase ? there is also tuples and inline definition anyway.
also you could just make a macro for them or use structx if you care that much.
> boxed future shenanigans
the compiler doesn't know at compile time the size of something it can't know at compile time, doesn't shock me much
> false positives in borrow checker
what is the halting problem
> lack of useful standardized traits
when there are things in the std "reeee bloat", when there aren't things in std "where is it reeeee".
at least the nice things with traits is that since implementation is separate from struct definition they are composable and can be added by libs. you can impl a lib trait for your types or your own trait for a lib type.
>many useful features seemingly permalocked behind nightly
alright, i agree with that one (i'd love become to be stabilized), but at the same time, the point of nightly is to be able to test things and break stuff, the std is supposed to be stable so it makes sense for them to be careful when adding new stuff to it.

> Clojure is more comfy for most software.
i should try it desu, not a fan of the jvm though, but i do like LISP's in theory, haven't used them enough to know if they are actually nice to use in the real world.
>>
>>107473737
I hope steve klabnik hangs himself. what a pompous asshole.
>>
>>107474972
the whole point is to say that it should not be moved.
because sometime you need something to not be moved in its lifetime.
you can pin any type, yes most type can be moved, the point is to say "this instance should not be moved even though the type normaly can be".
>>
>>107474938
>>107475001
honestly my biggest issues are that you can't define proc_macro in a normal crate.
and using ? and async in .map() is kinda anoying.
but that's the usual blue red issue.
i have to say, as much as i dislike go, i realy like goroutines as a concept.
>>
>>107475018
Yet majority of types can be moved anyway?
>>
>>107475077
green threads are wonderful, but they are simply not fit for a systems language, where absolute predictability is necessary
each await in Rust is an acknowledgement of a yielding point. Go injects these automatically into your AST. a VM like Erlang does "reduction" counting in order to guarantee fair allocation of compute time across all processes.
>>
>>107475077
I had some declarative macros. I wanted to add another one, but it had to be proc because rules can't use an ident as a segment of a path in a use clause. That meant I had to add three crates, one for proc macros, one for declarative macros because they can't both be exported from the same crate and one for actual code (proc macro was using declaratives so it couldn't go together with code)
>>
>absolute predictability
>async bloat
>>
>>107475126
> what is pragmatism
you don't have to use async
but you can if you need to
>>
>>107475094
All types can be moved. Some types can't be moved after being pinned.
>>
>>107475123
yea i had a similar problem onces
doesn't matter that much because i have a crates directory in most of my projects that are in the workspace.
but still, this is kinda annoying
>>
>>107472923
if you like sadistic maids that won't even collect your garbage for you
>>
>>107475158
if the maid is gonna make everything in the house 10x slower by collecting garbage, i rather do it myself.
>>
>>107475178
just buy more maids and have them do the work concurrently. She's a maid, not a slave to be worked like a plow horse.
>>
>>107475139
Pragmatism is when async has no usecase.
>>
>>107475191
but it's not just throughput, it's latency too, i want it NOW, and CONSISTENTLY NOW !
>>
>>107475284
> async has no usecase
lol
>>
>>107472495
Macros are a double edged sword. The Rust community definitely relies on them too much and it leads to undebuggable fucking messes.
>>
>>107474972
>Except majority of types can be moved?
In Rust types are movable by default. You need to use Pin to make them unmovable.
In C++ types are unmovable by default. You need to add move constructor to make them movable.
It doesn't get any simpler than this.
>>
>>107475397
>it leads to undebuggable fucking messes.
What problem did you had when using macros that was undebuggable? Modern IDEs can expand macros with just 2 clicks.
>>
I don't care about the nonsense itt but how do you write an efficient doubly-linked list in Rust without unsafe?
>>
>>107475487
If it expands to straightforward code, yeah.
My main problem is with UI libraries that make you define the entire UI layout and event listeners and their callbacks, the state etc. all in some in-macro-DSL.

It's a disaster.
>>
>>107475620
Cells
>>
>>107475620
you don't: http://rust-unofficial.github.io/too-many-lists/
and after you decide to use unsafe for efficiency, Rust starts to suck more than you might expect: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/
>>
>>107475637
the library-using experience from one end of Rust to the other is: if you're doing what the library author anticipated, then everything is so convenient it seems ridiculous for anyone to complain about Rust's usability. Are only morons saying that? The tooling is good, everything just works, and it's fast, and it catches all my mistakes.
And if you're straying off the beaten path, fuck you, rewrite it in Go.
>>
File: 1762539527317438.jpg (593 KB, 2048x1614)
593 KB
593 KB JPG
>>107475620
just read a book.
>>
>>107475620
more efficient that individual allocations too
>>
>>107475641
How do I get a reference to a list node then?
>>107475729
The safe one uses RefCell which is overhead. The other one is unsafe. Unfortunate.
>>107475789
Kek. Yeah I've done the right enough times, compiled first try.
>>107475790
This is less efficient, adds one layer of indirection.
>>
>>107475789
>list_init
Why does it point to itself rather than to NULL?
>>107475910
It adds two levels of indirection, (DLL->Slab + Node.next) etc..
The idea of an optional "manager" that allocates a contiguous memory area for the list and optionally resizes it is nice, for read access you don't want to go through that even once.
>>
>>107475910
>This is less efficient, adds one layer of indirection.
you have no idea how slow pointer chasing is. fewer allocations = more compact memory = better performance
>>
>>107475971
>>107475977
This is solvable by simply using an allocator with bins, like for example the default glibc allocator. There's no need to put that cruft into the data structure itself.
>>
Rust? More like crust. Nobody uses it so it collects dust. Using a different language is a must. Rust is something I distrust.
>>
>>107476004
ok, well, no matter the performance details, arenas allow for trivial cyclical references in Rust, defeating the argument of requiring unsafe or other weird shit
>>
>>107476017
>arenas allow for trivial cyclical references in Rust
Arenas aren't required though? Why does Rust impose an unnecessary requirement?
Also, anon... implementing an arena in Rust requires unsafe.
>>
>>107476039
>Also, anon... implementing an arena in Rust requires unsafe.
you do not know what you are talking about. an arena is a just a collection. just a data structure. they can be arrays, hash maps, b-trees, tries, slabs (makes the most sense for linked lists with random removals), etc.
>>
>>107476004
I didn't mean putting it in the data structure, I meant wrapping the data structure in what amounts to a VLA that tracks the linked list's allocation.
struct LinkedListMutator {
int allocated;
int used;
LinkedList head[1];
}

(Plus a free list if deletion is allowed / not ignored. And just "unused" instead of allocated & used if it reallocs by +4098 instead x2.)
Then use the LinkedList as a regular linked list, and do mutation via LinkedListMutator.

>>107476017
That's by basically bypassing the borrow checker for that cyclical object, right? Similar to making all relevant lifetimes 'static (meaning ⊤ / tee / top / always).
>>
File: 1752852939520889.jpg (295 KB, 750x731)
295 KB
295 KB JPG
>>107476008
lmao
>>
>>107476162
>That's by basically bypassing the borrow checker for that cyclical object, right?
yes
>Similar to making all relevant lifetimes 'static
no, because you might remove objects, resulting in different lifetimes

it is not possible (has been mathematically proven or some shit) to produce a borrow checker that can handle all cyclical references at compile time. hence unsafe, simulation of pointers via arena IDs (my preference due to contiguous memory being faster), or borrow checking at runtime via reference counting (which also cannot handle all situations, hence why garbage collectors exist).
>>
>>107475001
>structx
based
>what is the halting problem
the compiler could do far more than it does currently
>>
>>107476220
>no, because you might remove objects, resulting in different lifetimes
There's a way to implement a linked list in an Arena without using handles ("arena IDs") or reference counting?
E.g., without overhead?

>it is not possible (has been mathematically proven or some shit) to produce a borrow checker that can handle all cyclical references at compile time.
Programmers can do it so the problem is that the borrow checker disallows valid programs and cannot accept proofs that they are valid, like for instance ATS can and is made for, C is made for but can't programmatically verify, and Rust's unsafe does in a way that is more complex than C but less complex than ATS and supposedly isolated to less LoC.
>>
>>107476039
> implementing an arena in Rust requires unsafe
not necessarily no, you can implement an arena with or without unsafe.
>>
>>107476236
>the compiler could do far more than it does currently
i agree, but that'd be a huge increase in complexity for probably not that much to gain, there are limits to how much it can be pushed anyway.
>>
>>107476906
>there are limits to how much it can be pushed anyway.
That's not true...
>>
>>107472495
Running python's for loop huh, in a programming language aimed towards high performance environment.
>>
>>107476924
>That's not true...
by that i mean that you are never gonna be able to remove all false positives because of the halting problem.
>>
>>107476924
>>107476946
and besides the halting problems, you don't know everything at compile time so when the compiler doesn't know and can't know, it assumes that it is a positive.
>>
>>107476946
That's a lie too.
>>107476950
>can't know
You don't know what you're talking about...
>>
>>107474884

Absolutely beautiful. I would love to take a deep dive of Temple OS and so how it functions under the hood, but haven't gotten around to it yet.
>>
>>107476957
the fact that there can be pieces of data the compiler can't know at compile time if they will ever be accessed is a fact.
there are more than one reason but you can't argue against it.
if it can't be sure that it won't have more than 1 owner, it'll return an error, even if you know that won't happen, the compiler can't predict the future or make static analysis with data it doesn't have.
>>
File: image.png (786 KB, 1080x1198)
786 KB
786 KB PNG
>>107477112
>muh not listening
>muh more than one reason I won't name
>muh you can't argue against it
>muh shifting the goalpost
>>
>>107472495
>runs Python
Congrats, you've just pushed me 2x as far from liking Rust as I already was
>>
>>107474363
The image already covers that:
>>107473509
>I dislike doubly linked lists, therefore they cannot be good for comparisons
Try again.

>>107474371
https://rust-unofficial.github.io/too-many-lists/
Doing it in unsafe? Unsafe Rust that isn't even fully specified?
https://zackoverflow.dev/writing/unsafe-rust-vs-zig/
https://lucumr.pocoo.org/2022/1/30/unsafe-rust/
https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/
Try again.
>>
>>107475013
You could also stop lying and deceiving, Steve Klabnik.
>>
>>107477711
I wish steve klabnik was here. he might actually kill himself.
>>
>>107477748
>>107477711
>>
>>107474363
>I want to regularly apply an expensive operation over a sequence of objects
>The sequence may change over time, with new objects being appended, or old objects being removed
>The performance penalty of indirection is negligible in comparison to the operation
>But I don't want to have to move large portions of the bookkeeping data every time I add or remove an element, nor maintain dummy elements to represent removals
>I already have an allocator implemented
>So I'll use a linked list
>>
>>107477835
There are other data structures that can give similar guarantees, but Rust can be even worse for implementing some of those relative to doubly linked lists.
>>
>>107475910
>How do I get a reference to a list node then?
&head
&head.get().next
>>
>>107475729
>unsafe is le bad
lol look at these midwits, my code is full of unsafe just to make you mad.
>>
>>107474930
Seems like a pretty shitty guarantee when you think really hard about it.
Because you see, I really wanted an enum that is !Unpin because of the context it's used it, then I thought about it really hard once again, and realized that no rustroon who believes that Pin is for asyncslop exclusively, would understand why that enum is !Unpin unless I wrote words words words words words words to explain the whole context.
Really unfortunate.
>>
>>107478253
>Seems like a pretty shitty guarantee when you think really hard about it.
NTA.
When I think about it I don't see any meaningful difference from what C++ does. Except the default behavior is different. Like pointed out here: >>107475467
>>
>>107478301
I cannot help but feel that both the C++ approach and the Rust approach to movable/non-movable types, leave much to be desired. Maybe it's inherently difficult, maybe succesor languages to C++ and Rust will be able to figure something out.
>>
>>107478327
>leave much to be desired.
I have been working in Rust for 8 years and the only thing left to be desired for me is pin projection. Something that can be accomplished with simple unsafe one liner or a 3rd party crate abstraction. That's literally all.
>>
>>107478344
What are your thoughts on these articles?

https://lwn.net/Articles/1030517/
>Pinning continues to be the most difficult aspect of Rust to understand
https://without.boats/blog/pin/
https://without.boats/blog/pinned-places/
https://without.boats/blog/changing-the-rules-of-rust/
>>
>>107478104
B-trees are a meme. You've never actually met anyone who implemented a B-tree.
>>
>>107478225
>le
arn to read
>>
>>107478381
>What are your thoughts on these articles?
I am unfamiliar with these articles.
>>
>>107478301
C++ doesn't do anything about it at all.
But enough deflection, disingenuous tranny, your language is misdesigned pile of shit.
>>
>>107478442
>C++ doesn't do anything about it at all
C++ also has move semantics.
>>
>>107478445
C++ doesn't have a semantic for immovable values.
>>
>>107478454
>T(T&&) = delete;
>>
>>107478461
So, how do you represent int* that cannot be moved in C++?
Write a full class wrapper if you must, I really want to know.
>>
Nice to see there are no fresh anti-Rust talking points bots can use, only tard recycled ones, old tard recycled ones even.
IT'S REALLY OVER
lol
>>
>>107478487
Damn Alkeryn, you get breaks at 10 in the morning? That factory must be paying you well.
>>
>>107478473
You want a non-movable *pointer*? Are you sure? You don't mean a non-movable int?
>>
>>107478515
Both mean same thing, feel free to write the code that expresses this in C++ and I will go test it in production right now.
>>
>>107478454
C++ types are immovable by default. You need to provide a move constructor to make them movable.
>>
>>107478546
You seem very avoidant of providing any code that would support your claims.
>>
>>107478402
>>107478441
lol
>>
>>107478551
Here you go
https://en.cppreference.com/w/cpp/language/move_constructor.html
>>
>>107478578
So where's the code for int*?
>>
>>107478525
template<class T>
class Pinned : public T{
Pinned(Pinned&&) = delete;
Pinned& operator=(Pinned&&) = delete;
}

This should create an identical class without the move constructors.
>>
>>107478583
What int*?
>>
>>107478597
int*
>>
>>107478600
I don't know what you are talking about. We were talking about how Rust and C++ declares movable/unmovable types. What int* have to do with anything?
>>
>>107478253
So? A) nobody is going to use your code anyway and B) they don't need to understand why it's !Unpin, you write the API, you make the constructing functions return a Pin, you make the methods take a Pin, done
>>
File: NUT.jpg (61 KB, 497x663)
61 KB
61 KB JPG
>>
>>107478586
>Pinned(Pinned&&) = delete;
So this is the power of c++
>>
>>107478586
C++ won, this thread can be deleted now.
>>
>>107472495
>loves rust
>posts dirty links
sums up.
>>
>>107478603
#include <iostream>
#include <vector>
#include <memory>

template<class T>
class Pinned : public T{
Pinned(Pinned&&) = delete;
Pinned& operator=(Pinned&&) = delete;
};

struct selfref {
int x;
int* xp;

selfref(int x): x{x}, xp{&this->x} {}
};

int main() {
//std::vector<Pinned<selfref>> pins;
std::vector<std::unique_ptr<Pinned<selfref>>> pins;

int x = 0;
while (pins.size() < (1024*1024)) {
////pins.emplace_back(x++);
//pins.push_back(x++);
pins.emplace_back(new Pinned<selfref>{x++});
}

for (auto& pin : pins) {
std::cout << *(pin->xp) << '\n';
}
}

Learned something new from these shitty threads.
Very unfortunate that in Rust, Pin isn't that.
>>
Except this still compiles.
Pinned<selfref> make_selfref(int x) {
return Pinned<selfref>{x};
}

It shouldn't be a problem in real programs, but semantically it is.
>>
>>107479065
The constructor returns a prvalue. From a semantic purpose, this should be thought of as a promise, not an actual object. So when
>auto px = make_selfref(1);
is executed, no move occurs. The prvalue is propagated into px, and that's where the object is constructed. No temporaries are created. You can test it yourself, px.xp will point to a stack object.
This feature of C++ is called "prvalue semantics".
>>
>>107479107
Not relevant, semantically, the value was created inside a function on the stack frame, then moved somewhere else.
What I'm trying to do, in Rust, is find a way to create a type that can only be created on the current stack frame and never be moved nor copied no matter what, because there do exist some problems that warrant this level of restriction and compiler being able to enforce that is what I expect from a language that specializes in static analysis.
C++ cannot do this.
>>
>>107479136
You deciding to interpet the language with your own mistaken semantics isn't a language defect. In the *actual* proper semantics of C++ (since 17) the value wasn't created inside the function.
>>
>>107479180
nta
Does that mean it would not compile in C++11 because no prvalue semantics meeting the deletes of Pinned<>?
>>
>>107472495
....why would you do that
>>
>>107479180
I didn't mistake anything, you're just coping with defects as usual.
>b-b-b-ut
Sorry tranon, but if it cannot do what I need, I don't give a shit, I will just rawdog int* and document the invariants because C++ cannot encode them at the language level.
This isn't about how it works, this is about it not working in this context and you have no reason to be this mad unless you're a disingenuous troll whose only meaning is to ragebait people constantly.
>>
>>107479277
I'll ask you too, does that "bad example" compile with -std=c++11, or are you complaining that C++ 17 has C++ 17 value type semantics and not something else?

Like how would it a) compile b) move c) have move = delete. That's what you have to show, not that you don't like that prvalues imply acting on the caller's stack as though inlining the code.
>>
>>107479306
I'm complaining that semantics are less restrictive than semantics I need and there's no way to force semantics that I need.
In a language like English, I can define new words in a specific context and get semantics I want, in these languages that claim to be as powerful as English, I unfortunately can't.
I always end up with "fuck it, pointer is just a register storing a plain integer".
>>
File: rust-breaking-linux.png (199 KB, 802x842)
199 KB
199 KB PNG
>>107472495
>mentally ill tranny language users do mentally ill things again
>>
>>107479306
But to be very clear, it doesn't compile in C++11.
So fucking what? I always use latest "standard". If it doesn't work in -std=gnu++currentyear then you can go take a hike because I don't have time for this cope, I will use plain int* and document
>you cannot do this or that
Rust has same issue, where it can encode some problems, but not others. And current Pin interface is perfect example of it. I basically need AlwaysPinned<T> and I'm not sure if it's possible to do it or if someone will always find soundness holes.
But you know what I can do? Use plain *T and require unsafe {} everywhere, except rustrannies start screeching that unsafe is rarely needed and I'm doing it all wrong.
>>
>>107479136
pinned OnceCell?!
>>
>>107479234
It wouldn't compile, no.
>>
>>107479403
If it has 0 runtime checks, then it fits my usecase, if it does have runtime checks, then it goes straight into trash.
Rust Pin really should've been named something else, because I honestly made a mistake of depending on it when it doesn't mean that the pointer is stable, it only means that the struct isn't self-referential, and ensuring pointer stability always requires unsafe so I may aswell cut the noise and rawdow *mut T as I said.
>>
>>107479380
But your example literally just works as expected both in C++11 and C++17, no value is ever moved
Trying to move it would be a compile time error
>>
>>107479462
It doesn't compile in C++11 and compiles in C++17 when I expect it to never compile, and if you know something I don't, feel free to modify that example in good faith until it doesn't.
Everything applies to this too:
error: negative bounds are not supported
--> src/main.rs:3:25
|
3 | fn require_immovable<T: !Unpin>(_: Pin<&mut T>) {}
| ^

I thought it was obvious thing I missed, but no, you cannot heckin do that um because you just cannot ok???
>>
>>107479473
A prvalue is basically a lazily evaluated constructor masquerading as a value
Meaning when it's needed the code to construct it will be called and the value will live there
I learned this accidentally while learning C++11 for UDK3 development, and everything involving this that compiles in C++17 still compiles in C++11
Here's some docs:
https://www.geeksforgeeks.org/cpp/understanding-lvalues-prvalues-and-xvalues-in-ccwith-examples/
Ig for the meat of it you have to understand xvalues:
https://stackoverflow.com/questions/58703140/what-are-xvalues-in-c

Basically forcing a move in that make_ function is what would reintroduce the error because it then would not be able to return a prvalue (semantically, it may still be optimized away just as hard but the standard doesn't guarantee it so it's a compile error if a move *may* happen when move = delete).
But forcing it is pretty hard, let me see...
Oh, no it's not hard! It may still be elided by the compiler, but it's not a guaranteed elision, so it's not semantically a prvalue:
Pinned<selfref> make_selfref(int x) {
Pinned<selfref> psr {x};
return psr;
}

Now it fails in C++17 too.
>>
>>107479136
Functions have their own stack frames.
Use macro if you want to expand code inside the callee context.
>>
>>107479527
>just write code differently, just write it correctly
See where this is going?
>>
>>107479380
>But you know what I can do? Use plain *T and require unsafe {} everywhere, except rustrannies start screeching that unsafe is rarely needed and I'm doing it all wrong.
No one cares what you do.
>>
>>107479536
>Use macro
Why would I do that? I'm trying to look for valid reasons to write code in anything but C, which means macros as in C macros are banned.
>>
>>107479434
>Rust Pin really should've been named something else,
Use type alias then.
>>
>>107472495
Don't know what it does under the hood.
Shills it more.
Crashes half of the internet.
Good god why rust troons are this retarded ?
>>
>>107479550
Okay? Then don't tell me that your language deprecates C, since remember, you don't care that it does not and never will.
>>107479555
How do I force rustc team to use my type alias?
>>
>>107479552
>Why would I do that?
I explained it to you.
Functions have stack frames. If you want to invoke a code inside callee context, you use macros. This is how it works in any language.
>>
>>107479561
>Then don't tell me
I don't.

>How do I force rustc team to use my type alias?
You don't. No one cares what you do.
>>
>>107479563
You didn't explain anything, you're just getting defensive for no reason when holes in your abstractions are found.
I don't care about abstractions that are leaky.
>>
>>107479569
>You didn't explain anything
I explained to you how stack frames work. Each function has their own stack frame. If you want to invoke some code on callee side, you need to use macro. This is how it works in any language.
>>
>>107479565
Instead of being a disingenuous tranny, you could suggest something that works. But such basic human decency is too much to expect from someone who's severely mentally ill I suppose.
>>
>>107479578
>Instead of being a disingenuous tranny
I'm not. I don't care about your fetishes. No one cares actually.
>>
>>107479586
Okay tranny, stop responding if you have nothing of value to add beyond incoherent screeching about how much you don't care while continuously shitting up this thread with how much you don't care.
Like sure, that's fine, but did I ask?
>>
>>107479593
>Like sure, that's fine, but did I ask?
Yes. Here >>107479561
>How do I force rustc team to use my type alias?
And the answer is, you don't. No one cares what you do.
And here >>107479380
>But you know what I can do? Use plain *T and require unsafe {} everywhere, except rustrannies start screeching that unsafe is rarely needed and I'm doing it all wrong.
And the answer is it doesn't matter because no one cares what you do.
>>
File: t.png (1.34 MB, 1906x2048)
1.34 MB
1.34 MB PNG
>Hey guys, I'm trying to learn R-
>NOONE CARES WHAT YOU DO
>>
>>107479538
Your "bad function" does not move anything to begin with, it doesn't do anything unexpected or unwanted either in C++11 or in C++17.
No "moves slipping by" in any of the code posted since Pinned<T>, no moves happen or compile errors happen.
What doesn't work besides that "a move doesn't happen when you expect it to"?
>>
>>107479677
How do you know if it does or does not do something unwanted when you're too retarded to argue in good faith about anything and don't understand what semantics I need?
>>
>>107479677
>"no moves happen" or "compile errors happen" always, if move = delete.
fixd
>>
>>107479690
Where did I not argue in good faith?
I even turned on this benchod trip to clarify which posts are mine:
>>107479527
>>107479462
>>107479306
>>107479234
>>
>>107479710
>Where did I not argue in good faith?
Sure, here's an example:
>A prvalue is
Stopped reading there, because I know what a prvalue is and you're just trying to waste my time instead of arguing the point.
>>
error[E0658]: `Pin<NotUnpin<&mut BorrowingStruct<T>>>` cannot be used as the type of `self` without the `arbitrary_self_types` feature
--> src/main.rs:39:21
|
39 | fn borrow(self: Stable<&mut Self>, value: Stable<T>) {
| ^^^^^^^^^^^^^^^^^
|
= note: see issue #44874 <https://github.com/rust-lang/rust/issues/44874> for more information
= help: consider changing to `self`, `&self`, `&mut self`, or a type implementing `Receiver` such as `self: Box<Self>`, `self: Rc<Self>`, or `self: Arc<Self>`

Fr no cap on god yet another thing I can't do but borrow checker is what filters people.
>>
>>107479719
If you know what a prvalue is, why does >>107479065 compiling confound you?
>>
error[E0573]: expected type, found module `self`
--> src/main.rs:39:33
|
39 | fn borrow(self: Stable<&mut self>, value: Stable<T>) {
| ^^^^ help: a self type with a similar name exists (notice the capitalization): `Self`

I'm starting to think that my inexperience isn't the problem.
>>
>>107479735
It doesn't. You'd know that if you weren't trolling.
>>
File: aFO0Qtr.gif (1.19 MB, 500x272)
1.19 MB
1.19 MB GIF
Assembly will always be the best, which is why China is winning the AI war despite running shit on a toaster.
>>
>>107479780
Writing C is much faster, and C doesn't ask you to pretend that abstractions mean anything.
>>
>>107479754
So what's the problem with it if it never causes a move?
You don't like that that syntax is used to express the same semantics as putting Pinned<T>{x} at every would-be callsite of make_selfref? Or what?
What's the issue with the semantics of that example? Like:
Pinned<selfref> muh { 5 };

... is semantically equivalent to:
Pinned<selfref> muh = make_selfref(5);
>>
>>107479838
You'd know if you read my posts. Within what C++ offers, this construct is worthless and is more obtuse to use than a raw int*.
>>
It's really funny how something claimed to have 0 intelligence, tells me the answer I didn't want to see, because I'm trying to find a way to show that some abstractions can be 0 cost and not leaky at all, but there's always retards getting in my way.
>>
>>107479852
But it Pinned<T> implements the !Unpin that you were missing in Rust?
You never explained what it does wrong, just that you expected some specific syntax to never work, not why you expected it to never work
>>
>>107479884
Doesn't change the fact that T could just have deleted move and copy constructors on its own without this wrapper bloat, and that RVO semantics aren't desirable in some contexts, for example when value should never move.
RVO and function inlining is an implementation detail that doesn't change the semantics of value being created in a function and moved somewhere else.
>>
LLM just told me to do this:
use std::cell::UnsafeCell;

/// Raw pointer wrapper with stability guarantees
pub struct StableRef<T> {
ptr: *mut T,
}

impl<T> StableRef<T> {
/// # Safety
/// Caller must ensure the pointer remains valid and stable
pub unsafe fn new(ptr: *mut T) -> Self {
Self { ptr }
}

/// Get reference (safety: you guarantee stability)
pub unsafe fn as_ref(&self) -> &T {
&*self.ptr
}

pub unsafe fn as_mut(&mut self) -> &mut T {
&mut *self.ptr
}
}

// Usage: Document clearly that users must ensure stability

I agree, but if this requires unsafe, how is it better than &'stable mut T, what is this pretense for?
>>
>>107479788
C is faster, but with AI, the point is moot, you nees to do more with less.
>>
>>107479940
I use AI a lot, and I never saw it write code that I'd be happy to copy paste and commit without a single change.
Most times I ask it in advance to not write any code, because it always gets it wrong.
>>
>>107472495
ok, so python has been infested. import ivermectin, or something
>>
>>107479838
// should have no choice but to return some unrelated value or void
Pinned<ref> some_context() {
int x; // it shouldn't matter how x is allocated
auto pinned_x = Pinned<ref>{x};

// some API that requires Pinned<ref>
// e.g. auto borrower = borrower{};
// borrower.depend_on(pinned_x);

for(;;) {
// may break out at any moment
}

// Should always be wrong with a clear error
//return pinned_x;
//return borrower;
}

This is my problem, and so far, no language can express it soundly, so I choose to use plain int*.
>>
>>107479906
>Doesn't change the fact that T could just have deleted move and copy constructors on its own without this wrapper bloat
Sure, I didn't write that wrapper, but it's indeed only necessary for modifying the behavior of primitive types. And it's only code bloat.
>RVO semantics aren't desirable in some contexts
RVO semantics only apply to objects which *can* be moved. If RVO semantics determine an object must be moved, but it is move = delete, this is a compiletime error.

>RVO and function inlining is an implementation detail
C++17 adds explicit semantics for *copy and move elision*, it specifically adds mandatory *never-copying, never-moving* in specific situations:
https://stackoverflow.com/questions/70185398/what-has-changed-in-c17-in-terms-of-move-elision
That is why your example compiles under C++ 17, it is guaranteed to never move by these semantics.
Very much not an implementation detail.
Not trolling, I'm just not super deep into C++ yet.
>>
>>107480054
But this is an example of RVO for an object that cannot be moved:
template<class T>
class Pinned : public T {
Pinned(Pinned&&) = delete;
Pinned& operator=(Pinned&&) = delete;
};

struct ref {
int& value;
};

Pinned<ref> some_context() {
int x;
return Pinned<ref>{x};
}

int main() {
auto broken = some_context();
}

The reference is now dangling, abstraction doesn't prevent one thing it's supposed to.
>>
>>107472495
>>107472495
>>107472495
THAT
IS
FUCKING
DERANGED!!!
>>
File: jeff-laugh.jpg (112 KB, 1200x800)
112 KB
112 KB JPG
>>107472495
>now your code can get python's vulnerabilities too
>>
>>107480104
oh kek, okay
It still works but I have to have a look at how this is allowed, I am not entirely ...
#include <cstdio>
template<class T>
class Pinned : public T {
Pinned(Pinned&&) = delete;
Pinned& operator=(Pinned&&) = delete;
};

struct ref {
int& value;
};

Pinned<ref> some_context() {
int x;
return Pinned<ref>{x};
}

int main() {
auto broken = some_context();
printf("%i\n", broken.value);
}

x gets interpreted as int x = 0; (but using x from int x; is undefined behavior afaict) and then that 0 is a prvalue, so the again the whole thing is moved to callsite. Basically, the lifetime of int x is automatically expanded to that of broken.
Roflmao.
>>
>>107480168
#include <iostream>
#include <memory>

template<class T>
class Pinned : public T {
Pinned(Pinned&&) = delete;
Pinned& operator=(Pinned&&) = delete;
};

struct ref {
int& value;
};

Pinned<ref> some_context() {
auto ptr = std::make_unique<int>(789456);
std::cout << *ptr << '\n';
return Pinned<ref>{*ptr};
}

int main() {
auto broken = some_context();
std::cout << broken.value << '\n';
}

$ g++ broken.cpp && ./a.out
789456
1694317102

>
>>
>>107480200
Fails to compile on GCC. Overload resolution believes Pinned<ref> is not constructible from *ptr.
>>
>>107480168
This also fails to compile. Fascinating. Time to place your bets:
Is it a Clang or a GCC bug?
>>
>>107480303
Compiles on my GCC.
>>
>>107480337
Ah, I was looking at Trunk. Probably a GCC bug then.
>>
>>107480349
Ah, it compiles with -std=c++17 but fails with -std=c++20 and onwards. Could be a standard change.
>>
>>107480349
>probably a bug
lmao cope
>>
>>107472495
In 2 weeks rust will support linked lists
>>
use std::pin::Pin;

struct Borrower<T> {
strawman: *mut T
}

impl<T> Borrower<T> {
fn new() -> Self {
Self {strawman:std::ptr::null_mut()}
}

fn borrowing(self: &mut Pin<&mut Self>, value: Pin<&mut T>) {
self.strawman = unsafe { value.get_unchecked_mut() };
}
}

fn some_context() -> Pin<&'static mut Borrower<i32>> {
let mut i: i32 = 789456;
let i_pin = Pin::new(&mut i);
let mut b = Borrower::new();
let mut b = Pin::new(&mut b);
b.borrowing(i_pin);

b
}

fn main() {
let _ = some_context();
}

I find it really odd that nobody told me that I can just require T in my API, because T isn't bound by anything, Rust cannot assume that T: Unpin, and gives me errors for trying to move the value in any way, I also cannot escape from the context with my limited knowledge no matter what retarded code I try to write. Rust seems to work fine here, but it's so obtuse I honestly cannot know if this is 100% sound or might have some holes.
error[E0515]: cannot return value referencing local variable `b`
--> src/main.rs:24:5
|
21 | let mut b = Pin::new(&mut b);
| ------ `b` is borrowed here
...
24 | b
| ^ returns a value referencing data owned by the current function

For more information about this error, try `rustc --explain E0515`.
error: could not compile `test-pin` (bin "test-pin") due to 1 previous error
>>
>>107480374
It's P1008R1
>>
Unfortunately, this code compiles:
use std::pin::Pin;

struct Borrower {
strawman: *mut i32
}

impl Borrower {
fn new() -> Self {
Self {strawman:std::ptr::null_mut()}
}

fn borrowing(self: &mut Pin<&mut Self>, value: Pin<&mut i32>) {
self.strawman = value.get_mut(); // imagine if T was a String that can be moved here
// without unsafe
}
}

fn some_context() {
let mut i: i32 = 789456;
let i_pin = Pin::new(&mut i);
let mut b = Borrower::new();
let mut b = Pin::new(&mut b);
b.borrowing(i_pin);
}

fn main() {
let _ = some_context();
}

Which is a problem to me, because these pointers should be stable
>inb4 just write correct code lil bro
This can segfault without unsafe.
>>
File: explicit.png (27 KB, 571x281)
27 KB
27 KB PNG
>>107480443
I sometimes question why I use this language
>>
File: frog.jpg (54 KB, 976x850)
54 KB
54 KB JPG
use std::pin::Pin;

struct Borrower {
strawman: *mut String
}

impl Borrower {
fn new() -> Self {
Self {strawman:std::ptr::null_mut()}
}

fn borrowing(self: &mut Pin<&mut Self>, value: Pin<&mut String>) {
self.strawman = value.get_mut(); // imagine if T was a String that can be moved here
// without unsafe
}

fn so_about_that_thing_we_borrowed_safely_and_dropped_safely_outside_this_struct_yea_it_is_fucking_gone_man(self: &mut Pin<&mut Self>) {
println!("{}", unsafe {&*self.strawman});
}
}

fn some_context() {
let mut s = "Hi".to_string();
let s_pin = Pin::new(&mut s);
let mut b = Borrower::new();
let mut b = Pin::new(&mut b);
b.borrowing(s_pin);
std::mem::drop(s);
b.so_about_that_thing_we_borrowed_safely_and_dropped_safely_outside_this_struct_yea_it_is_fucking_gone_man();
}

fn main() {
let _ = some_context();
}

>It compiles and prints garbage.
Not a meme, how do I make this thing sound?
>>
>>107474280
>or they'd parse their whole codebase with python to output some transformed C
Anyone worth their salt is processing their own codebase with C.
>>
>>107480560
For context, imagine if `strawman` is actually a pointer held by something outside of Rust program.
I can't find a way to make Pin work for my usecase.
>>
>>107480646
Google Engineers get paid 6 figures and their protobuf uses Python, and who are you?
>>
Jannies filtered my trip
>>107480560
You need it Pin be contagious? You didn't Pin the owner of the data
>>
>>107480688
If Pin is owning, how do you get a pointer to inner value then?
>>
>>107480485
Use lifetimes, not Pins
>>
>>107480780
How do I attach uncountable amount of lifetimes that exist outside Rust program?
>>
>>107480794
There is no uncountable amount of anything in software. Computers are fundamentally countable, and in practice, finite.
>>
>>107480830
Data is created at runtime and must be restricted to a specific context window and you cannot know in advance how many pointers, that must be forever stable, there will be.
How does Rust express this in its type system?
>>
>>107480852
Lifetimes. When you create a variable and take reference to it, its lifetime is limited to the current scope. You can borrow it and reborrow as many times as you want.
>>
>>107480769
nvm, I was thinking of a simpler problem
>>107480852
You're working with external data and you have structs that *represent* the lifetime of external data / pointers to it, e.g. as long as struct exists external data is accessible and you guarantee that manually, but std::mem::forget allows for footgunning the value into oblivion?
Maybe you just want to wrap the raw pointer in a struct, put the struct in a separate module to hide the raw pointer from all consumers of the struct wrapper, and only allow access to the raw pointer via a getter that lends it out?
Oh, and the wrapper struct can only be constructed as Pin<struct> or something like that.
>>107481000
He's also talking about the std::mem::forget issue, so I think data hiding
>>
>>107481011
My problem is that data is owned by Rust, but it's passed back from external source as a pointer, lifetime data is gone, so the only thing I can try to do is try to restrict moving or design api in a way that removes all references and then user is responsible for keeping track of data by only using enum to determine what should be accessed, or an enum with a stored index to determine that I should be accessed from some arena.
I've been trying to avoid this C-like API and use strictly references, but I can't get it to work with Pin because Unpin exists.
>>
>>107481072
>but it's passed back from external source as a pointer, lifetime data is gone, so the only thing I can try to do is try to restrict moving or design api in a way that removes all references and then user is responsible for keeping track of data by only using enum to determine what should be accessed
Wrap it in a structure with PhantomData with a lifetime.
https://doc.rust-lang.org/std/marker/struct.PhantomData.html#unused-lifetime-parameters
>>
>>107481121
And how do you match the lifetime between some method that arbitrarily borrows a value, passes it outside of Rust, and some other method, that only has foreign data coming from outside Rust, that must be turned back into the reference?
The answer is you don't, I simply need something that tells rust that a value is forever borrowed beyond this point, must not need to be moved, because moving is copying, and copying is a waste of cycles.
>>
>>107481202
>And how do you match the lifetime between some method that arbitrarily borrows a value, passes it outside of Rust, and some other method, that only has foreign data coming from outside Rust, that must be turned back into the reference?
That depends entirely on the semantics of that data, its valid use rules and things you want to be able to do with it and things you want to prevent.
Write the FFI functions declarations with some comments about validity rules and maybe desired usage examples that fully encompasses the main problem you are facing and I will tell you how to write a safe wrapper for it. I can't work with your current explanation.
>>
>>107481339
[/code]
let mut data = Data::new(); // predictable data that can be allocated on the stack, but I do not control it
let mut data_user = DataUser::new(); // my API
data_user.register(&mut data);
loop {
// data must still exist here
// data must not be moved
// data must live until data_user is gone or unregister is called
// data user might have runtime allocated uncountable amount of similar references registered and unregistered here
// all data is referenced here
// T: Unpin makes this UB
// yet T: Unpin could be used here
}
[/code]
>>
>>107481397
Write the FFI declarations of what you are trying to wrap, not just usage example.
>>
>>107481410
I can tell you is that I'm trying to abstract epoll API, but it's completely irrelevant that it is for epoll, data is simply not owned by my API.
Again, I can just make it unsafe to register pointers, I can also just use C at that point.
>>
>>107481425
>I can tell you is that I'm trying to abstract epoll API, but it's completely irrelevant that it is for epoll, data is simply not owned by my API.
https://en.wikipedia.org/wiki/XY_problem
Just provide the FFI declarations and I will tell you how to do it. I can't help you solve your problem using completely wrong solution.
>>
>>107481445
struct epoll_event {
uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};

Which part of this confuses you?
>>
File: pepe-eyeroll-eyeroll.gif (14 KB, 220x220)
14 KB
14 KB GIF
>Copy 8 bytes to a struct passed to Linux
>Some time later those 8 bytes are given back at unpredictable time
>This kills borrowchecker and smartest rust shill on boards.4channel.org/g/
>>
>>107481457
This is not FFI, this is just a C struct.
Write the FFI functions declarations with some comments about validity rules and maybe desired usage examples that fully encompasses the main problem you are facing and I will tell you how to do it.

>Which part of this confuses you?
No part confuses me. However you seem confused because you are trying to solve lifetime problem using types made for making self referencial types. You also seem to be confused on what FFI declarations mean.
Just do what I tell you and I will tell you how to solve your problem.
You are making this way harder than it has to be.
>>
>>107481489
What FFI functions? There aren't any.
Want to see epoll syscall ABI? Read Linux source code.
>>
>>107481703
>What FFI functions?
The functions that:
>arbitrarily borrows a value, passes it outside of Rust
>other method, that only has foreign data coming from outside Rust
That you've mentioned here: >>107481202

In order to pass data outside Rust and to get foreign data you need foreign function interface. FFI in short.
>>
>>107481731
I really wonder what you expect to see if this is so hard for you to comprehend.
>In order to pass data outside Rust and to get foreign data you need foreign function interface. FFI in short.
No I don't?
>>
>>107481738
>I really wonder what you expect to see
What I expect from you is to write the FFI functions declarations with some comments about validity rules and maybe desired usage examples that fully encompasses the main problem you are facing and I will tell you how to do it.

>No I don't?
Then post the code of functions that:
>arbitrarily borrows a value, passes it outside of Rust
>other method, that only has foreign data coming from outside Rust
Remember to have them include the code that actually does pass data outside of rust and gets foreign data from outside Rust
>>
>>107481772
There are no functions and no code, if I knew how to write it, I wouldn't be asking here.
There is no FFI, only ABI, since you seem unable to find it yourself, here's the only interface a white man needs:
Arch/ABI      arg1  arg2  arg3  arg4  arg5  arg6  arg7  Notes
──────────────────────────────────────────────────────────────
alpha a0 a1 a2 a3 a4 a5 -
arc r0 r1 r2 r3 r4 r5 -
arm/OABI r0 r1 r2 r3 r4 r5 r6
arm/EABI r0 r1 r2 r3 r4 r5 r6
arm64 x0 x1 x2 x3 x4 x5 -
blackfin R0 R1 R2 R3 R4 R5 -
i386 ebx ecx edx esi edi ebp -
ia64 out0 out1 out2 out3 out4 out5 -
loongarch a0 a1 a2 a3 a4 a5 a6
m68k d1 d2 d3 d4 d5 a0 -
microblaze r5 r6 r7 r8 r9 r10 -
mips/o32 a0 a1 a2 a3 - - - 1
mips/n32,64 a0 a1 a2 a3 a4 a5 -
nios2 r4 r5 r6 r7 r8 r9 -
parisc r26 r25 r24 r23 r22 r21 -
powerpc r3 r4 r5 r6 r7 r8 r9
powerpc64 r3 r4 r5 r6 r7 r8 -
riscv a0 a1 a2 a3 a4 a5 -
s390 r2 r3 r4 r5 r6 r7 -
s390x r2 r3 r4 r5 r6 r7 -
superh r4 r5 r6 r7 r0 r1 r2
sparc/32 o0 o1 o2 o3 o4 o5 -
sparc/64 o0 o1 o2 o3 o4 o5 -
tile R00 R01 R02 R03 R04 R05 -
x86-64 rdi rsi rdx r10 r8 r9 -
x32 rdi rsi rdx r10 r8 r9 -
xtensa a6 a3 a4 a5 a8 a9 -

Fully expressible and usable from Rust without any foreign functions.
>>
>>107481793
>There are no functions and no code,
Then what are the functions that you have mentioned here: >>107481202

>There is no FFI, only ABI, since you seem unable to find it yourself, here's the only interface a white man needs:
>Arch/ABI arg1 arg2 arg3 arg4 arg5 arg6 arg7 Notes
>alpha a0 a1 a2 a3 a4 a5 -
>arc r0 r1 r2 r3 r4 r5 -
>arm/OABI r0 r1 r2 r3 r4 r5 r6
>arm/EABI r0 r1 r2 r3 r4 r5 r6
>arm64 x0 x1 x2 x3 x4 x5 -
>blackfin R0 R1 R2 R3 R4 R5 -
>i386 ebx ecx edx esi edi ebp -
>ia64 out0 out1 out2 out3 out4 out5 -
>loongarch a0 a1 a2 a3 a4 a5 a6
>m68k d1 d2 d3 d4 d5 a0 -
>microblaze r5 r6 r7 r8 r9 r10 -
>mips/o32 a0 a1 a2 a3 - - - 1
>mips/n32,64 a0 a1 a2 a3 a4 a5 -
>nios2 r4 r5 r6 r7 r8 r9 -
>parisc r26 r25 r24 r23 r22 r21 -
>powerpc r3 r4 r5 r6 r7 r8 r9
>powerpc64 r3 r4 r5 r6 r7 r8 -
>riscv a0 a1 a2 a3 a4 a5 -
>s390 r2 r3 r4 r5 r6 r7 -
>s390x r2 r3 r4 r5 r6 r7 -
>superh r4 r5 r6 r7 r0 r1 r2
>sparc/32 o0 o1 o2 o3 o4 o5 -
>sparc/64 o0 o1 o2 o3 o4 o5 -
>tile R00 R01 R02 R03 R04 R05 -
>x86-64 rdi rsi rdx r10 r8 r9 -
>x32 rdi rsi rdx r10 r8 r9 -
>xtensa a6 a3 a4 a5 a8 a9 -
>Fully expressible and usable from Rust without any foreign functions.
Ok, now include some comments about validity rules and maybe desired usage examples that fully encompasses the main problem you are facing and I will tell you how to do it.
>>
>>107481819
I already explained to you that there's simply borrowed uncountable data that must not move or drop until it's not used anymore, without having to move it into memory that I manage, because that's bloat and waste of cycles, not sure what else I can tell you besides that this just works in C, and in Rust, requires unsafe high level interface.
>>
>>107481846
>I already explained to you that there's simply borrowed uncountable data
There is no uncountable data in computer science. Pretty much everything in computer science is countable.

>that must not move or drop until it's not used anymore,
Then borrow it.

>not sure what else I can tell you besides that this just works in C, and in Rust, requires unsafe high level interface.
Post the C code and I will tell you how to rewrite it in Rust.
>>
>>107481869
>post C code
C code just assumes that you aren't a retard, doesn't work in Rust.
Provide design in next reply or I will accept your concession, timewasting troll.
>>
>>107481885
>C code just assumes that you aren't a retard, doesn't work in Rust.
Post the C code and I will tell you how to rewrite it in Rust.
>>
>>107481885
> accept your concession
Ah yes, the retard that got filtered by hello world lol
>>
>>107481892
>he doesn't know how epoll works
thanks midwit, I'll just go make 'cord account and ask the expert troons instead, still less mentally ill than you
>>
>>107483016
> he hasn't heard of io_uring
lol
>>
>>107483016
Have fun!
>>
Is rust a good language to learn for someone starting programing?
>>
>>107483454
Not efficient for my usecase.
>>
>>107483603
No, It's a fairly difficult language with infamously steep learning curve.
You are better starting with C to learn basics of systems programming and programming in general before you start messing with Rust.
>>
>>107483771
Rust is easy to use if you just use it like C and ignore the screeching thoughbeit.
>>
>>107483805
Cool
>>
>>107483819
So, what's the holdup? Did you realize that you're the jeet that got filtered by lifetimes?
>>
>>107483662
What usecase?
io_uring outperforms epoll in most cases.
And if you care that much you stop using syscalls anyway and write kernel code or ebpf.
>>
>>107484124
>most cases
>>
>>107479244
scripting.
>>
>>107484320
You don't need that.
>>
>>107484358
you quite literally do
use dioxus::prelude::*;

fn App() -> Element {
// You can link to assets that are relative to the package root or even link to an asset from a url
// These assets will automatically be picked up by the dioxus cli, optimized, and bundled with your final applications
const ASSET: Asset = asset!("/assets/static/ferrous_wave.png");

rsx! {
img { src: "{ASSET}" }
}
}
>>
>>107484385
>embedding 'p into rust binaries at compile time
usecase?
>>
>>107483603
no, learn Go. spend two years with it.
then spend a week with C, then 3 months with Elixir, then 3 months with Racket, then 3 months with Haskell, then 3 months with Rust
then do whatever the hell you want.
oh yeah, definitely learn SQL to an advanced level. try building a webapp entirely in Postgres with SQL and PL/PGSQL, with PostgREST to automatically deploy a REST API. if you're not using SQL triggers, stored procedures, and functions, you are not doing advanced enough of SQL.
>>
>>107484494
what the crud is unc yapping about lol
>>
>>107484163
Name one where it doesn't
>>
>>107484654
You have a lot to learn if your post is unironic and not just blatant bait.
Not sure how would io_uring would remove a requirement for good design by the way, it seems like you don't actually program.
>>
>>107484637
>>
>>107473782
Valid points never get attention
>>
>>107484844
>programming language exploration
Cool, anything notable?
>>
>>107484889
here's a benchmark of a hash table implementation that I have outperforming Google's Swiss Table (Rust's implementation)
I am even outperforming a b-tree in a situation where it is going as fast as it possibly can.

I've found numerous bugs in Bouncy Castle by writing a Clojure wrapper around it. I've built a cryptographic validator for the integrity of revealed information within partially-redacted documents. a fault tolerant programming language (includes deterministic replay of concurrent operations). an experimental type system. a transaction utility that uses a custom trie implementation (even supports the read/write locking of subsequences, such as parts of an array).
>>
>>107484941
Cool, did you submit the patch to the abseil?
>>
>>107484984
no, it is not public work. it's also not a fork of Swiss Table, but an entirely custom design.
>>
>>107484996
So it's not used anywhere except in a benchmark, good job I guess.
>>
File: 1759339547133798.png (430 KB, 715x916)
430 KB
430 KB PNG
>>107485324
>yeah bro, just open source the tech that would save big companies millions in electricity every year, I'll give you a Github star lol
>>
>>107485408
No? Build your own datacenter at a fraction of the cost and outcompete Google. But let me guess...
>>
>>107485446
anyway, that hash table is just a side project. I even have an idea of how I could make it faster, but I'm working on more interesting, marketable things at the moment.
>>
>>107479729
Does borrowing struct implement Deref<Target=T>?
>>
>>107479744
self is a value, Self is a type
>>
>>107485489
No, and I gave up trying because I'll just stick to scoping data using a closure so I will never know, Pin is only meant for self referential structs so whatever, won't bother fighting it.
>>
>>107478115
Returns a copy, not the actual node, try again
>>
>>107480104
Pin is not supposed to prevent reference outliving the referee, that's borrow checker's job
>>
>>107472875
fpbp
>>
>>107485561
>C++
>borrow checker
boards.4channel.org/g
>>
>>107480512
Hopefully cause they you for it
>>
>>107485556
Copying a reference is a noop
>>
>>107472875
this
>>
>>107481457
>>107481072
Make an abstraction around an epoll instance
Make the abstraction own the data associated with each member added to the epoll instance
>>
>>107485796
Doesn't prevent safe moving causing UB.
>>
>>107485588
So you're saying the cell contains a reference? Cell<&T>? What's the lifetime of that borrow anon?
>>
>>107485578
>The reference is now dangling, abstraction doesn't prevent one thing it's supposed to.
Pinning is not the abstraction that's supposed to prevent dangling references
>>
>>107484669
My guess is that you have no usecase and are just larping, prolly the same dude that got filtered by hello world.
>>
>>107485812
What safe moving.
>>
>>107485827
'static
>>
>>107485862
Moving that is safe.
>>
>>107485875
The epoll instance abstraction owns the data, it can just not move it
>>
>>107485886
>just write good code
>>
>>107485869
Oh that's cute, but I want to dynamically allocate my list nodes.
>>
>>107485965
Box::leak
>>
>>107485990
So I have to leak memory in order to have a safe doubly linked list? You know I create and delete a lot of nodes...
>>
>>107484404
>>embedding 'p into rust binaries at compile time
>usecase?
retard
>>
>>107486033
>So I have to leak memory in order to have a safe doubly linked list?
No, you don't need to leak memory. You can also use Rc.
>>
>>107486049
Rc is overhead. I accept your concession, in order to have a doubly linked list in safe Rust I must either
>leak memory
or
>accept overhead
>>
>>107486068
wow nigga, you just came across a known computer science problem. Lisp, having came up with garbage collection over 70 years ago, were thinking of the same problems that you are today.
>>
>>107486033
Surely you're already using an arena to cope with the fact that linked lists suck?
>>
>>107485928
What? You tie the lifetime of a resources referenced in an epoll instance to the rust abstraction over said instance. You could require the resource is pinned before being passed to the abstraction as data to be referenced by an added fd, but really that is just an internal invariant of the abstraction that doesn't need to be leaked outside. All the users see is a that you pass the ownership of the associated data to the epoll abstraction, and you get a reference back to it if you wait and the fd for that data got an event
>>
>>107486068
> waah the language designed to prevent memory errors and data races won't let me write code that could lead to data race without telling it to trust me that it doesn't.

kek, how is your hello world going ?
>>
>>107486136
>move into epoll
requires heap allocation when C code does not
>>
>>107486068
You don't need to introduce overhead. You can also use unsafe
>>
>>107486254
I can also use C.
>>
>>107486260
Yes
>>
>>107486260
and give up namespaces, modules, generics, exhaustive pattern matching, selective use of unsafe, a SOTA build system, proper macros, and so on.
your argument is akin to
>excessive exercise is bad, so I will never get up from the couch ever
>>
>>107486263
following anon's comment >>107486280
why do you bitch so much about rust ?
just use C if you like it that much, it seems you keep trying to justify your decisions with retarded usecases that aren't even an issue in rust anyway.
last time you were filtered by no_std hello world and blamed the compiler for hours because the error certainly couldn't be you it could only be the compiler, then someone shared some no_std repo to show you how easy it was and that the issue wasn't the compiler at which point you inhaled a quantity of copium that'd have been enough to replace zyklon b.
>>
>>107486280
none of these things are worth spending hours on building leaky abstractions that also end up unsound anyway
>>
>C
struct T t;
struct T* t_ptr = &t; // just don't move it bro

>Rust
&Pin<UnsafeCell<T>> // just don't misuse it bro

>Rust shill
words
words
words
words

didn't read allat
>>
>>107486329
> leaky abstractions
why would they, if your C abstraction is not gonna be leaky, your rust has even less chance to be so, even on unsafe most of the checks are still here.

also, in C you don't even have proper generics, you'd most of the time have to reimplement a shitty linked list for every of your projects and multiply the risks of fucking it up.
in rust you could always do LinkedList<T>.

anyway, linked lists are retarded and there are close to 0 real world engineering tasks where they are the best solution.
most of the times you are even better off using an array and node indexes, or a linked hashmap so that you can get any node in O(1) time.
>>
>>107486400
There are no abstractions in C.
Rust claims to fix this, until you need &Pin<&UnsafeCell<T>> and then you realize that if you ever create a &mut T, shit is unsound because theoretically, somewhere, perfectly safe code, might swap your mutable data that should not be.
>>
>>107484494
> muh only right path is my path
retard
as much as i think rust is a terrible first language to learn, your path is also retarded imo.
just start with learning the command line and basic editor.
then learn bash, c and python in whatever order.
then have some fun with c++ if you want.
and then you'd be about ready to learn rust.
bonus points if you learn some reverse engineer, asm, and binary exploitation.
eventualy explore lisp and haskell.
sql is so trivial to learn once you've done the ones above it barely deserve a mention.

anyway, programming languages are nearly all the same, if you know very well a handful you can learn pm anything as long as you aren't brown
>>
>>107486440
> There are no abstractions in C.
oh boy do i have a story to tell you about excessive use of the preprocessor and broken abstractions.
> until you need &Pin<&UnsafeCell<T>>
you clearly have never built anything with it.

> theoretically, somewhere, perfectly safe code, might swap your mutable data that should not be.
is the data swapper in the room with us anon ?
>>
>>107486460
>>107486440
honestly you behave just like i did when i was 12 and was autisticaly obsessed with "muh performance" and "muh purity".
there is no C code you cannot generate assembly somewhat equivalent if not identical with rust if you realy want to.

rust is just a language that is gonna be MUCH nicer to use and avoid tons of pitfals.
also it doesn't have 20 broken build systems.
>>
>>107486460
>midwit forgets what safe rust is
>>
>>107486481
The only pitfall is the language.
>>
>>107486482
safe rust is safe based on the assumption that you did not fuck up in your unsafe blocks, it is treated similarly to an axiom.
oh and sure the odd compiler bug that you'd never reach in the real world anyway as code has to be specificaly crafted to reach it.
still having to care about the few blocks were you use unsafe is miles better than every potential block of code no matter how trivial could corrupt your memory if fucked up.

anyway, memory safety asside, rust has just tons of features that make it just nicer to use, C doesn't even have basic generics, the build system is retarded, the preprocessor is retarded, no decent metaprogramming, i mean it's a fun toy language but there is close to no good reason to use it today unless you want to interact with legacy codebases or libraries or want to write a meme compiler for a niche architecture.
>>
>>107486492
> The only pitfall is the language.
citation needed, you can't formulate a single valid criticism of the language, it always comes back to your own skill issue.
see, no_std hello world.
>>
>>107486492
>>107486511
also this is pm your mentality
>>107486280
>>
>>107486505
Ok so explain how those unsafe blocks were meant to prevent safe code from moving out of &mut T, midwit.
>inb4 just don't have &mut T
>>
>>107486515
what's your issue exactly ?
i'm not gonna read the whole thread to find where you mentioned it.
>>
>>107486520
>midwit gets confused by safe rust nd its implications
C doesn't have this problem.
>>
>>107486532
> C doesn't have this problem
what problem exactly ?
you seem to be unable to formulate it.
is the problem in the room with us anon ?

also, even if that was true, C has a bazillion different problems that would be worse lmao.
though i'm not even exactly sure what your imaginary problem actualy is since you can't seem to be able to formulate it.
>>
>>107486567
The problem that safe rust creates.
Something tells me that your IQ is too low to comprehend why it is indeed a problem and not a solution.
>>
>>107486450
>sql is so trivial to learn once you've done the ones above it barely deserve a mention.
lmfao
when people say shit like this, it's embarassingly easy to tell that they have not done shit.
sure, your basic crud app is easy SQL. now predict the disruption in the logistics chain of some coastline based on meteorological storm data, road pathways, business locations, ethnic population response tendencies, etc. in conjunction with historical data to consult.
oh yeah, your dataset is over 500tb
you are just a dumbass that thinks the difficulty of programming is based on your language selection. it is not. it is entirely based on your problem domain.
>>
>>107486578
> The problem that safe rust creates.
> refuses to explain the problem exactly
i think the problem is imaginary and in your head, until you formulate it, i accept your concession.
>>
>>107486578
> mentions IQ in a debate
nice admission that you lost the plot lol
>>
>>107486659
>the problem is imaginary
no wonder you cannot get employed
>>
>>107486674
post code
>>
>>107486585
> le join and groups are somehow muh hard.
dude, there is nothing hard about sql, even the niche features are fine.
> oh yeah, your dataset is over 500tb
sharding, design your data model in a proper way.

anyway, my point is that most people are not gonna need complex sql queries, and by the time they do, they will know how to do them, also if you get to huge scales you are probably gonna use an OLAP and not OLTP database.
> the difficulty of programming is based on your language selection
i precisely said the opposite, that languages don't matter if you understand the fundamentals, they are just abstraction for what the machine is doing, if you understand what is happening the language is irrrelevant.
>>
>>107486674
> muh rust has a problem
> what problem
> *can't formulate it* uh.... uh.... you can't get employed
meanwhile you got filtered by a no_std hello world.
lmao, i accept your concession.
>>
>>107486585
>implying resident midwit would be allowed near a database bigger than a gb
>>
>>107486662
You're right, I shouldn't mention what you don't have.
>>
>>107473509

Isn’t it just a matter of having the nodes have a pointer for the next node with a lifetime shared by the double linked list abstraction, and a weak pointer for the previous node?

Sorry, didn’t write much Rust, but doesn’t seem difficult
>>
>>107486725
Feel free to post code.
>>
>>107486715
> muh i'm so smart
> *can't write a no_std hello world*
> waaaah it's the compiler, not me saaaar
>>
>>107486776
I can tell that you specialize in hello words, call me when you upgrade to a fizzbuzz.
>>
>>107486786
i don't, but you were filtered by it and are butthurt that we laughed at you for that.
>>
>>107486806
Still no idea what you meant by that, I hope you can advance beyond fizzbuzz one day and handle a conversation like an adult, even though I really don't expect this site to enforce bans on underage faggots like you.
>>
>>107486847
this : >>107402251
you are the guy that says "muh i accept your concession" i recognize your style from a thousand miles.
>>
>>107486731
>>107486725
hey anon, so no, you cannot make a zero overhead linked list in safe rust, you could use Rc which has minimal overhead but it still is one.
the reason is that the borrow checker doesn't allow ownership cycles and doubly linked list are inherently cyclical (A points to B, B points to A).
if you truely want 0 overhead you can but you'll need unsafe.
another options is to implement a linked list over a hashmap, pro is that you can access any nodes in O(1) but you do have the overhead of using a hashmap.
>>
>>107486932
use a fucking slab
>>107475790
>hashmap
how inefficient can you be?
>muh slab overhead
less overhead than individual allocations per node
>>
>>107486946
btw, this implementation does actually have a downside, but nobody in this thread has actually brought it up
>>
>>107486946
> use a fucking slab
yea that's what i'd do, linked lists are a retarded data structure for 99% of cases anyway.
> how inefficient can you be?
can make sense for BIG LRU's, if you want to access / remove / add in O(1), but yes, not cache friendly, for small N nothing beats an array.
> less overhead than individual allocations per node
true, but the dude wants "muh c like linked list".
>>
>>107486957
What's the point of bringing it up when samefagging tranny will find a way to dilate all over it.
>>
>>107486957
downside is if you go above the vec's size you need to allocate a new one double the size and copy everything around.
it can be a fair trade depending of your usecase.
also, if you want to avoid it you could always use slabs implemented over deques.
>>
File: 1746585661390505.jpg (67 KB, 622x622)
67 KB
67 KB JPG
>>107486977
bring it up, I'm waiting
>>
>>107486982
>>107486957
anyway, arrays will have the best cache locality friendliness, if your list is gonna have a max size that's a good data struct to use.

all data structs have strenght and weakness, which is why i mentioned linked hash map earlier, it's imo better than linked lists for most cases
>>
>>107486982
I guess that this could be considered a downside, but it is so far from typical computing that it honestly is not even worth bringing up. if you really are in an extremely latency-sensitive environment where ANY inconsistency is not tolerable, then just reserve some capacity for the slab that you know you will not exceed.
the actual downside is that you cannot combine two lists together in an efficient manner.
>>
>>107486988
It's written in Rust and not an actually useful programming language.
>>
>>107487000
>then just reserve some capacity for the slab that you know you will not exceed
sums it up pretty much

anyway, we are kind grasping at straws over meme data structures we almost never use in the real world (and still can if we want to).
also, if you are gonna use a linked list, Rc's overhead is trivial compared to the retardedness of using a linked list.
i feel like this data structure only got popular because c is a pain in the ass and it made some things easier to do even though it was not the optimal struct for many cases.

> the actual downside is that you cannot combine two lists together in an efficient manner.
good point but when's the last time you had to do this ?
also depending of your slab impl you can, a slab could serve as storage layer for two different lists.
i once implemented a graph by index over fixed sized vecs, worked like a charm, nothing prevented me from defining two independent graphs and then connecting them.

anyway, i'm not the guy that suggested slabs.
>>
>>107487022
rust is far from perfect but it's literaly the best thing we have right now.
>>
>>107487037
Better than Haskell and LISP is a pretty low bar and it has yet to actually be better than either of those.
>>
>>107487022
you bring down the quality of this board. at least marketing fags keep to their own shitty threads. you actively invade enjoyable discussions just to try and shit on people that seem to be having any modicum of joy in discussing their interests, and you won't even post any code in the process
>>
>>107487046
>projection from t. ranny that has been shitting up this thread for over 18 hours non-stop
>>
>>107487045
> Haskell and LISP
neither of those are system programming languages.
as much as i like those family of languages there are things i can do in rust they are just not fit for.
i don't see much as a replacement to c anyway, i see it more as a better C++.
>>
>>107487062
>neither of those are system programming languages.
neither is rust
>>
>>107487072
> neither is rust
nice cope, but that's false.
you can even program microcontrollers, kernels and drivers in rust, you can pm target anything and have same (and sometime better) perfs than cpp.
>>
>>107487058
I have had better discussions with Somalians than you
you're just a piece of shit. what is your purpose in existing, seriously?
>>
>>107487082
i don't think he's the same one as the "samefag" spamming one of last time but we can't have a single thread that mentions rust without some anons shitting the thread.
i think it's just not the right place for those discussions, /g/eet nocoders come thiking they have some sort of valuable insight or something.
>>
>>107487098
I accept your concession, samefag nocoder tranny hello worlder.
>>
>>107487109
> can't even write a hello world
> I accept your concession
> no, YOU are the nocoder waaaah
what kind of mental illness is that even.

have you been able to write a no_std hello world yet ?
>>
>>107487098
we should have a thread where we write C and shit on its lack of features. would be fun
>>
>>107487135
we could even screenshot all funny posts for later posting whenever Cniles get uppity
>>
>>107487135
There's just one problem, you cannot write anything without your beloved crutches.
>>
>>107487149
i've been using c and c++ over a decade before moving to rust, and the reason i learnt rust in the first place was to be in a good position to criticize it, something you are too lazy to even do.
of course, once i knew it, i realize that it was indeed better.
>>
File: lmao-c-safe-arithmetic.png (216 KB, 1902x3872)
216 KB
216 KB PNG
>>107487149
lmfao
it's really funny when C syntax highlighters cannot even handle the absolutely atrocious preprocessor
>>
>>107487162
You used C++ for 5 years in last 5 days? Damn unc.
>>107487180
I missed the part where that's my problem.
>>
File: lmao-c-safe-arithmetic.png (300 KB, 951x1936)
300 KB
300 KB PNG
>>107487180
that was weird
>>
>>107487204
>mactoddler btfo
>>
File: file.png (1.39 MB, 1242x1018)
1.39 MB
1.39 MB PNG
>>107487197
believe it or not i have very old codebases
>>
File: lmao-c-arrays.png (792 KB, 951x5902)
792 KB
792 KB PNG
>>107487204
here you will notice that I was using "I" for later replacement via the preprocessor, because syntax highlighting was so shit, and having to press backslash all the fucking time was so shit
but sure, Rust's native generics are not that useful of a feature
lmao
>>
>>107487197
>Damn unc
i'd not attempt to criticize anyone when you can't even write a hello world.
>>
>>107487242
one think that pissed me off with c++ is that for the most basic network features i had to do #ifdef _WIN32 bullshitery and reimplment shit for all targeted platforrms, and of course windows syscalls are similar but not the exact same on linux and windows so more pain to make nice abstractions.

nearly all c++ devs i've ever met had to build their own "mini std" they copy in all projects to do the most trivial things because the language is so shit.
>>
lmao
>>
>>107487242
>malloc
>>
>>107487280
What's so funny?
Besides that your LOC cope consists of 0 value headers like this one?
>>
>>107487332
yes, most software need to allocate memory, does that concept filters you too ?
>>
>>107487339
Humans landed on the moon without malloc, jeets are still trying.
>>
File: 1748883269774392.jpg (60 KB, 413x429)
60 KB
60 KB JPG
>>107487338
>What's so funny?
>>
>>107487350
1. the use of malloc in this software was necessary because of windows crap api's.
2. if you think all software can be written without allocation you are a retard.

yes, many software don't need dynamic memory allocation, but that's a small percentage of software.
but anyway, i shouldn't expect a nocoder that can't even write a hello world to understand this.

also regarding the software that got to the moon, it was in full control of the computer's ressources, unless you want to not be able to run more than one program at once on your computer, and you don't want all your program to use more memory than they need, malloc isn't a choice.
>>
File: beautiful-rust.png (583 KB, 1177x4338)
583 KB
583 KB PNG
>>107487280
but Rust?
wow, so much prettier
all my homies love generics
>>
File: file.png (57 KB, 625x347)
57 KB
57 KB PNG
>>107487431
oh no the horror, T types
>>
>>107487374
Maybe necessary to a midwit nocoder like you who got filtered by VirtualAlloc.
>>
File: 1702961638453.png (462 KB, 775x1500)
462 KB
462 KB PNG
Most programs don't need dynamic memory allocation.
>>
>>107487460
> can't write a hello world
> no you are the nocoder saar, not me, waaaaah

> VirtualAlloc
le shitty windows api
also it's still dynamic allocation retard
>>
>>107487470
> Most programs don't need dynamic memory allocation.
citation needed.

if you want your program to work with arbitrarily large data, you often need to be able to allocate memory.
sometime a fixed buffer does the job, but in most cases it doesn't.
and regardless, if you use malloc() or not, the kernel is still gonna allocate memory for your process so the end result is kind of the same.
>>
>>107487470
even if that was true (which it isn't) you still admit that there are process that needs memory allocation, rending your whole point moot.
>>
File: 1762491429950219.jpg (49 KB, 540x668)
49 KB
49 KB JPG
>>107487498
he probably read the TigerBeetle articles and thinks he is an expert on memory allocation specifics in every system on the planet now
>>
>>107487517
> TigerBeetle
i have no idea what you are talking about but you are still unable to make any argument of your own.
"muh dynamic allocation is useless"
cool opinion dude, until you can explain your reasoning everyone is gonna laugh at you being a retard.

you either are an edgy peak dunning kruger 12yo who read a shitty blog post and thinks he has figured everything out, or a troll that has nothing better to do with his life than to shit threads with retarded opinion and a smug attitude.
>>
>>107487542
nigga I am in agreement with you
memory allocation is sometimes necessary
>>
>>107487470
even if that was true, how is that relevant to rust exactly ?
you can do no malloc rust.
>>
>he doesn't use GNU M4 for preprocessing
>he needs generics
https://www.gnu.org/software/m4/manual/m4.html
>>
>>107487626
>his build system does not include a Jinja pass
>>
>>107487626
> just use another program to parse my shitty macro code and generate the actual code out of it so that the compiler can compile just because my meme lang is missing the feature in the first place
> no my lang doesn't totally suck reeee
>>
>>107487487
>nocoder keeps screeching about hello world
>doesn't understand why maloc is shit and VirtualAloc is not
Rakesh...
>>
File: images.jpg (20 KB, 335x597)
20 KB
20 KB JPG
Dynamic allocation?
No thanks, I only practise dynamic deallocation to counteract all the jeets who leak memory because leaking memory is safe o algo.
>>
>>107487663
> nocoder keeps screeching about hello world
i don't screetch about it, i just refuse to listen to you seriously because you got filtered by the most basic and trivial thing imaginable lol.
there is nothing impressive about hello world, that's the fucking point.
>>
>>107487697
No idea who hurt or how you but I hope you will recover from your trauma.
>>
>>107487663
>nocoder
post code
>>
>>107486221
Uh, no?
>>
>>107487808
I already figured out the design and not going to now. Stay mad, midwit.
>>107487812
Indeed, does not require moving anything.
>>
>>107487498
Most programs don't need to work with arbitrarily large data.
>>107487505
>>107487568
Not the anons you're arguing with.
>>
>>107487808
>>107487865
i swear these nocoder /g/eets larping as le amazing engineer.
you are the only one in the thread that didn't share a single piece of code yet everyone but you is a nocoder apparently.
>>
>>107487893
> Most programs don't need to work with arbitrarily large data.
we don't have clear data but i'm not sure this is true.
at least if you only count programs that runs under linux / windows / mac.
if you count microcontrollers etc, then that'd tip the scale.
regardless, the whole point is that there is no issue with using malloc if it makes sense too.
even then malloc is more of an issue if you keep calling it repeatedly everytime in a loop etc instead of preallocating your shit.
>>
>>107487916
>at least if you only count programs that runs under linux / windows / mac.
Nope, most programs on desktops don't need to work with arbitrarily large data.
>there is no issue with using malloc if it makes sense too
It's fallible.
>>
>>107487916
It never makes sense to use malloc.
>>
>>107487931
portability you stupid motherfucker
imagine using Windows for anything other than chatting up bitches in video games on the weekend lmao
>>
>>107487926
>work with arbitrarily large data
so working with arbitrarily large data doesn't mean you need malloc, ie you can reuse a buffer in many case.
however if you need to hold the whole thing at once and not shift a buffer around it, then yes allocating the memory is often the best way to do it.
i'm thinking 3d file editor, image editor, slicers.
also web browsers without dynamic allocation would be pretty shitty.
and even if you wanna have fixed buffer, there is a case to allocating them at startup rather than staticaly, ie, you can adapt the buffer size based on system available memory.

> It's fallible.
using malloc once or twice in your main before doing the main work is no more faillible than just running your program, if you are out of memory the kernel won't be able to allocate memory for the executable anyway.
>>
>>107487931
typical windows jeet response.
how's your day going saaar?
>>
>>107487976
Tell me which toy platform has the bloat that is malloc but cannot run tcmalloc or jemalloc
>>
>>107487982
>Day
>>
>>107487983
> jemalloc is a general purpose malloc(3) implementation.
both uses mmap internally anyway, what's your point
>>
>>107487991
true, here in europe it's 6:38
>>
>>107488002
>Dunning Kruger Reductionism (again) award
I wonder why those other two exist if malloc is so good.
>>
>>107488013
i wonder why rust exists is c++ is so good.
reason is that it's better than the latter, doesn't mean the former is completly useless.
>>
>>107488013
anyway, if you are gonna call it 2 times in your program's lifetime it doesn't matter much anyway which one you use.
>>
>>107488037
That's 2 times too many.
>>
>>107487978
>3d file editor
mmap
>image editor
mmap
>slicers
mmap
>web browsers without dynamic allocation
would be completely fine, you can set limits so high no web page would ever reach them
>allocating at startup
this is exactly what happens when you declare static memory segments
>adapt the buffer size based on system available memory
what's the point? modern OSes have swap and overcommit, and you will never need to do this for anything but a file, where you could just use mmap
>>
>>107488047
> literaly no real world difference
> bro, you neeed an extra dependency trust me saaar.
if you are gonna call it one or two times for your whole program's lifetime it's retarded to add the dependency.
and anyway, this all started with "muh you use malloc", you didn't even know if i was building using libc or not and even if i was using jemalloc, i'd still be the "malloc" function, the code would be the same.
>>
>>107488066
> mmap
that's literaly dynamic memory allocation if you are not mapping to a file, which you will not want to in most cases.
and even if you map to a file, the kernel would still do some dynamic memory allocation for you anyway to speed things up.
malloc uses mmap underneath...
> would be completely fine, you can set limits so high no web page would ever reach them
i like being able to cache multiple pages in ram you know.
> swap
holy bloat, no thanks

> this is exactly what happens when you declare static memory segments
thus my point that it's irrelevant, except for the fact that there is a limit to how big you can make a static array, the stack is limited, that's the whole reason we have the heap in the first place.
>>
>>107488098
>mmap is literally dynamic memory allocation!!!
then so is running more than any kernel at all because physical pages are dynamically allocated
the point is to make the userland program more stable
mmap is also something that you can allow to fail gracefully, unlike something like malloc
>>
>>107488068
>>107488098
I can't believe this isn't ragebait.
Jamal... Please return the computer to the person you stole it from.
>>
>>107488126
> unlike something like malloc
you can also fail malloc gracefully, it returns a null pointer if it fails, you can decide what you want to do from that point.
if you used mmap instead of malloc the code would be almost identical except that's a function with more arguments, nothing wrong with having a wrapper over it, especialy since it can choose to use other syscalls depending of your alloc size.
>>
>>107488131
a nigger wouldn't even know what dynamic allocation means, i think you are the troll here honestly.
> "muh dynamic allocation is useless".
>>
>>107488152
Jamal, I'll be honest, I noticed that you don't know.
>>
>>107488174
why are you constantly shitting threads though ?



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.