Thread 106532364

>"hurr durr, Rust is not hard at all and I never had problems fighting the borrow checker!"
>*uses RefCell*
I am so fucking sick of this

it's the exact same thing with kotlin vs. java
"dude it's TYPE SAFE!"
>does a bunch of shit to get around that
pointer problems suck but it's always YOUR JOB to figure them out

>>106532373
QRD? Are they not both Garbage Collected?

>>106532364 (OP)
>uses tool in the language to do something
what did OP mean by this?

>>106532364 (OP)
explain to me why using RefCell for certain things is bad

>"hurr durr, C++ is not hard at all and I never had to manage memory manually"
>*uses std::vector*
I am so fucking sick of this

this is how you sound

>>106532364 (OP)
she's so cute! we need to get more girls like her into coding :3

>>106532416
>>106532402
If you use Rc, RefCell or std::shared_pointer EVER, you might as well use Go/C#
So, usecase for Rust?

>>106532395
they ARE but the runtime itself has to remove them :^)

>>106532441
>So, usecase for Rust?
You're too stupid to know what a linter is and also too stupid to check your own code, but NOT QUITE stupid enough to where you can't write a bunch of slop that should fail because of pointer errors (AKA indicating you're doing it wrong)

>>106532441
You're not employed. You have never written any valuable open source software. You're a hobbyist programmer that makes useless toys, and you've never had sex.

at least he is programming unlike 90% of /g/

>>106532486
All of that also applies to you, sis ;)

>>106532494
he's amateurgramming

compiling rust codes is literally painful

>>106532364 (OP)
i've never seen this text editor. what's this?

>>106532364 (OP)

This is a low iq bait

What is a smart pointer (shared_ptr) in C++? Exactly the same wrapper type.

kys

>>106532441
w-what?
are you literally retarded?

>>106532537
In C++ you are not required to use it since you can just new and delete.
In Rust you are required to do this for any graphical application with a state, because the borrow checker does not understand that "this dialog object owns the state and also owns all callbacks that happen on it, therefore it should be allowed to borrow a reference to the state inside any callback where the dialog object is the first parameter, because that indicates that the dialog object owns this callback"
There is no way to do that using the Rust's borrow checker.

>>106532364 (OP)
NOOOOOOOOO YOUR NOT ALLOWED TO USE REFCELL EVERYHING IS SUPPOSED TO BE IMMUTABLE WTFWTFWTFWTFWTFWTF

>>106532583
prove me wrong.
a garbage collector has been proven to outperform a C++ program with heavy smart pointer usage. So, why would Rust be any different.

>>106532619
>proven
the fever and hallucinogen fueled dreams you had while severely intoxicated don't count as proof

>>106532619
>prove me wrong
lmao

ChatGPT thread

>>106532619
prove you wrong how?
what are you even talking about?
non-determinism calls for non-determinism solutions.
if you need refcounting, you need refcounting, whether you want it or not and you'll reimplement it if you don't have it available.

you should like a massive retard and should stop posting.

>>106532638
>>106532688
RefCell is just slower than a language with a GC. Hate to break it to you, sis

>>106532699
ah yes, the ultimate source... a barely voted comment on a stackoverflow post from a literal who

>>106532713
All I see from you is bark and no bite. I made an assertion and backed it up.
You backed up your assertions with nothing.
Therefore, I win.

>>106532717
now it's orange reddit
>what are arena allocators
>what is creating objects on the stack, something shitty gc languages simply cannot do
it's embarrassing and you should kill yourself

>Why are you using this tool?!
>Why are you using this tool that way?!
>REEEEEEEEEEEEEEEEEEE

>>106532746
Explain to the thread how RefCell and shared_pointer make use of arena allocators and stack?

>>106532699
>>106532717
the problem with retarded claims like this is it's always "in theory" and ignores all the actual tracing gc part of the costs.
"pauseless" GC's ignore trade-offs vs stop-the-world as well and ultimately every GC shitlang I ever dealt with was always much slower than C++ or Rust by orders of magnitude due to other factors unrelated to GC.
The reality is, C++ or Rust can simply use allocation patterns that look like "arenas" and still heem these shitty GC runtime languages anyway.

>>106532768
>every GC shitlang I ever dealt with was always much slower than C++
because nobody in C++ uses std::shared_pointer. Everyone just uses unique where applicable and if unique is not applicable, everyone just uses raw pointers and new/delete mechanism
>or Rust
yeah maybe for command line programs, but any graphical program or any program that has a state (something that borrow checkers hate), will be using RefCell and therefore be SLOWER.
How many graphical Rust programs have you used?

>>106532763
>RefCell
I'm not a tranny, I wouldn't know
>shared_pointer
it's known you can use custom allocators all throughout the std lib and you're trying to compare the generic use of a GC language to a very specific anti-pattern of manual memory management languages (heavy allocations) to make your argument sound better

>>106532790
This entire thread is about RefCell and reference counting and you say it is an "anti pattern"
yes it is, but we are talking about Rust forcing you to use this pattern and hence how GC langs are just better than Rust and you should not use Rust.

>>106532787
>because nobody in C++ uses std::shared_pointer
extremely shitty bait post. have a (You). now fuck off.

>>106532814
I accept your concession.

>>106532801
you brought c++ into this with false claims trying to support your distorted view of gc languages

>>106532364 (OP)
> "Programmers can NEVER be trusted to write safe code in an unsafe language, ever. So use Rust."
> look into any nontrivial Rust codebase
> unsafe fn
> unsafe extern
> unsafe { }
> unsafe
> unsafe impl function
> "When to Use Unsafe Code: "
> "Using unsafe to use one of the five superpowers just discussed isn’t wrong or even frowned upon"

>>106532832
unsafe is based because it is fast. RefCell is cringe because it makes your "ultra fast" Rust program slower than an equivalent Java program.

>>106532441
Linux and GTK are full of shared pointers. Wdym?

>>106532848
Gtk is C and Linux kernel has ZERO shared pointers (and is also C)

>>106532848
>linux
>gtk
>c++
shit bait 0/10 made me reply

>>106532787
Unique_ptr is just Box in Rust, except in Rust you do not have to pay for overhead of C++ move semantics. Box is truly zero cost in Rust.

>>106532868
https://docs.kernel.org/core-api/kref.html
https://docs.gtk.org/glib/reference-counting.html

Why do cniles always speak about this as they have 0 idea about? It literally takes 5min to check this.

>>106532868
>Linux kernel has ZERO shared pointers
same retard who said >>106532787
huh?
kek

>>106532894
>this as
*things

>>106532894
>https://docs.kernel.org/core-api/kref.html
Aha, so THIS is why Linux is so fucking slow lately

>>106532894
it's possible that he took a look in gtk git page and went "yep, C", not knowing that glib reimplements OOP-ware in most blasphemous way that somehow works

>>106532441
>if you ever used a fork might as well chop off your hands and replace them with forks

>>106532918
Worst analogy itt award

>>106532699
>>106532717
>dumb retards that don't understand the actual purpose of refcell, reference counting, or GC, and that refcell is orthogonal to the other two

>>106532983
doesn't matter, overhead is the same
Rc counts number of "owners", RefCell counts the number of "mutable references"
It is all the same thing and has the same overhead
In C++ one could just use raw pointers to bypass this overhead.

>>106532832
Uh-huh, sure buddy, let's see
https://lib.rs/std most popular rust crates

>https://github.com/serde-rs/serde
41k lines, 3 unsafes
>https://github.com/serde-rs/json
17k LoCs, 12 unsafes
>https://github.com/dtolnay/thiserror
4.5k LoCs, 0 unsafes
>https://github.com/rust-random/rand
>11k LoCs, 17 unsafes

>>106533016
>RefCell counts the number of "mutable references"
no it doesn't
>It is all the same thing and has the same overhead
no it isn't
>In C++ one could just use raw pointers to bypass this overhead.
in C++ you could just use a raw pointer to corrupt your data, yes

>>106533046
Why does serde take over 200MB of my storage space? json-c only takes a couple of KB

>>106533059
Because Dave Tolnay hates you.

>>106533059
Why are you moving the goalposts?

>>106533091
I just want to hate on Rust without bringing in trannies because it makes it seem as though I have no actual argument.

>>106533059
>compiling binaries takes storage
News at 11.

>>106533351
Yes, now why does it take MORE storage than every other json library in existance? that is the real question, isn't it?
Another example, Gson library, one of the most extensive (perhaps bloated?) Json libraries in existance. The JAR is 280KB in size ...
https://repo1.maven.org/maven2/com/google/code/gson/gson/2.13.1/gson-2.13.1.jar

>>106533059
filtering poor people

>>106533059
>>106533406
Serde is not a json library. It's a fully fledged backend for making serialization libraries.

>>106532441
>If you use Rc, RefCell or std::shared_pointer EVER
What if I have multiple detached threads reading the same resource that I want to be deleted when all the threads are done

>>106534094
You don't need refcounting for that either, because typically when your main thread is done processing, it will just wait for the other threads to finish. And after that, you free the resources.
The pthread_join() function waits for the thread specified by thread to terminate. If that thread has already terminated, then pthread_join() returns immediately. The thread specified by
thread must be joinable.

>>106533406
because, assuming we're talking about serde_derive, it generates a lot of intermediate code and a resultant .so/.dll that rustc dynamically links and executes to transform your serde marked structs into rust code. both C++ and Rust have a tendency to build massive binaries, most if it being symbols or debug information.

>>106534115
and what if the threads are detached. you seem to be having some difficulty understanding problems that refcounted types solve.

>>106534115
>detached threads
The type of thread you start up, detach, and let the OS close them. Main thread never joins
I like using them for writing to disk

>>106534223
>>106534212
Don't detach them, there is no reason to.

>>106534198
The serialization/deserialization routines do not end up in final binary unless you use them. They can still take space in intermediaries though

A lot of binary bloat in Rust could be eliminated if they realized that runtime reflection is sometimes kind of good, actually.

>>106534232
how? unless you're proposing structured concurrency, which rust is probably the only implementation that is actually valid and correct.

>>106534256
I'm aware, but retard-kun asked why his compiler output folder was big. I'm merely pointing out compiler output from LLVM frontends will always be fuckhuge.

>>106534232
>there's NO USECASE for A
>what about B
>ok well that might need A, but there's NO USE CASE for B
>what about C
>ok well that might need B, but there's NO USE FASE for C

>>106534809
lol, oops.

>>106534266
That's true zero cost abstractions bloat binary with monomorphisations. But it's often better to trade storage space for runtime performance, up to a point ofc.

>>106533053
having multiple mutable references in a single thread is safe, rust is just retarted and doesn't allow you to do this without unsafe

usecase for coding stream?

>>106532951
>if you have an appropriate use for this tool EVER you need to start exclusively using it and remove any ability to use a different one
seems apt to me

>>106537099
>having multiple mutable references in a single thread is safe
That's an undefined behavior.

>>106532585
Maybe there is currently no way for the borrowchecker to do that, but there should be a way, patches welcome

>>106532441
> you can never use anything once, you must always use everything all the time no matter what

>>106537099
Yes, dangling pointers are impossible in a single-threaded context.

>>106537099
retard

>>106532848
>>106532868
>>106532873
Gtk uses GObject which is basically a shared pointer and OOP inheritance implementation in C

>>106533046
Your data does not match what lib.rs reports.

What happens if you include tokio, and the 15 most popular crates, and the 15 most starred Github projects?

And when you write
>unsafes
does that refer to occurrences of the unsafe keyword or the number of lines contained in each unsafe block? Some unsafe blocks can be ridiculously long.

https://github.com/rust-lang/rust/tree/master/library/core/src/slice/sort

>>106533046
https://materialize.com/blog/rust-concurrency-bug-unbounded-channels/

>>106532713
This is basic CS knowledge though.

>>106542532
>// SAFETY: we made sure that

Cnile sisters, I don't feel so good...

>>106542584
I once saw a case of UB in the standard library of Rust, where the UB was in the section of code with lots of SAFETY comments.

https://github.com/rust-lang/rust/commit/71f5cfb21f3fd2f1740bced061c66ff112fec259

SAFETY comments do not magically make the code correct or free of UB.

What in the name of fuck is ebussi doing? Don't you dare tell me he is rewriting gtk in Rust.

Rust is for people too stupid to learn how to manage memory themselves. Historically these kind of people were filtered out of the industry once they started doing anything non trivial. Now they have shit like Rust, Java, Js, Python etc etc which allows them to continue shitting out garbage code because they do not have to worry about the memory layout or structure of their program, the language does it for them, albeit, poorly. This results in a subclass of programmers that are about as good as 1st year CS undergrads who proceed to shit out more and more garbage software while giving said people an over abundance of confidence which is not warranted. This is true in almost every domain and it's part of the reason why the world is in a rush to the bottom. It will never get better until society cracks under the collective incompetence of the work force and greed of the pay masters.

>>106542532
>does that refer to occurrences of the unsafe keyword or the number of lines contained in each unsafe block? Some unsafe blocks can be ridiculously long.
occurences of unsafe keyword,most of which were single-line to call a single function, most of which was std::str::from_utf8_unchecked
>What happens if you include tokio, and the 15 most popular crates, and the 15 most starred Github projects?
how the fuck should I know you want more data get it yourself

>>106542596
yes, but they explicitly explain whatever invariants you are aiming to enforce, which then you can verify or scrutinize, rather than leaving it as an undocumented emergent property of multiple disjointed elements
>>106542584
well they did

>>106543796
Nice cherrypicking then, and you never explained why your data is different from the website.

>colorful shell
oot, but isn't gnomedev hate that shit

>>106543846
And not all SAFETY comments are checked, and considering the UB in the Rust standard library >>106542596, they might do more harm than good in some cases if they lure developers into a false sense of security. And unsafe Rust is harder than C++, in part due to the no aliasing requirement.

>>106532519
GNOME Builder

>>106532364 (OP)
qrd on RefCell?

>>106544958
It allows mutation through a shared reference.

>>106544302
I just went to the repo, put unsafe in search bar and counted

>>106544975
I see. The borrow checker should have allowed mutable shared references when in a single thread context.
The justifications I've read that about why it's not like that are retarded. Things like iterators and side effects orderings. Iterator safety should simply be ensured by another mechanism and likewise the side effect ordering thing shouldn't be a concern for the borrow checker.

>>106545433
>The borrow checker should have allowed...
in the first place.

>>106545433
>The borrow checker should have allowed mutable shared references when in a single thread context.
no

>>106545433
>hurr durr
push_all(&vec, &mut vec)
dumb retard

>>106545444
argument or stfu
>>106545461
what does it do?

>>106545433
>The borrow checker should have allowed mutable shared references when in a single thread context.
That's an undefined behavior

>>106545479
that's not an argument
if it's in a single thread, you can very well store a (mutable reference) pointer to a dynamic array in some data structure, and at the same time pass a mutable reference pointer to a function that will append elements to the array. There isn't any memory issue with that, even if a realloc happens, as long at array is boxed.

If the shared reference is the raw pointer to the array then it make sense to forbid reallocs if there is more than one reference, but mutation of the elements of the array itself is perfectly fine, in a single thread.

>>106545535
>There isn't any memory issue with that, even if a realloc happens, as long at array is boxed.
let el = &vec[0];
vec.push(0);
*el = 5; // potential dangling pointer


>mutation of the elements of the array itself is perfectly fine, in a single thread.
You can have mutable references to multiple different elements of an array.

>>106545656
i don't know how y'all argue with people who haven't even heard of basic shit like iterator invalidation.
https://www.geeksforgeeks.org/cpp/iterator-invalidation-cpp/
>The borrow checker should have allowed mutable shared references when in a single thread context. Just remember an indefinite set of rules to stay safe like us totally bug-free coding cpp geniuses do. Rust borrow checker is hard. cpp is easier....

>>106545700
but >>106545433 mentioned iterators

>>106545656
That's not mutation, that's moving the object somewhere else. Mutation is fine, but moving is not.
I don't care if Rust calls moving a mutation, the fact is that if you have an array of numbers, mutating the number at index [0] doesn't cause any problem.

>>106545754
none of what you wrote makes any sense. stick to fizzbuzz, retard.

>>106545764
tell him to write a non-Send/Sync pointer wrapper and share it with us instead ;)

>>106545764
2 different references can perfectly mutate a the fields of a struct or elements of a fixed sized array, in a single thread, without any safety issue whatsoever.

This is irrefutable, shut the fuck up inbred.

>>106545882
ok, nobody cares though.

>>106545882
you can do this in Rust
https://doc.rust-lang.org/stable/std/primitive.slice.html#method.get_disjoint_mut
let v = &mut [1, 2, 3];

if let Ok([a, b]) = v.get_disjoint_mut([0, 2]) {
*a = 413;
*b = 612;
}

assert_eq!(v, &[413, 2, 612]);

>>106545890
Apparently you do.

>>106545731
and?
>Iterator safety should simply be ensured by another mechanism
what another mechanism? the toothfairy checking the binary?
>you shouldn't need a parachute when skydiving, your safety should be ensured by another mechanism, I have no fucking clue what that would be, but it should be something different
come up with a solution and we'll tell you why it's shit

>>106545967
>what another mechanism?
you could check for invalidation at runtime with a generation counter.
>come up with a solution and we'll tell you why it's shit
dumb retard, I'm not disagreeing with you.

>>106545967
>what another mechanism? the toothfairy checking the binary?
inside the body of the loop, disallow mutations to the thing that is iterated over
wow that was hard

>>106545990
you could, at a cost
U can implement this in rust btw

>>106545996
that's what rust does though

>>106545996
what about not iterating?
what about containers in containers?
what about people that work around it by iterating indicies, then taking a reference to the ith element, then mutating the container?

>>106546006
>more bad faith
Lol ok. You're proving that once again, Rust shilling is not based on technical grounds.

>>106546050
>get btfo with facts and logic
>noooooooo! that's bad faith
keep crying, cnile

>>106544335
Is pointer aliasing not also UB in C++? Or are you referring to a different kind of aliasing?

>>106545923
you can split/chunk with many methods. a special mention of `slice.as_chunks_mut::<1>()` ;)

I always thought that GNOME devs don't use their DE, but macs. However, it looks like ebussy mains it. What do I think of this..?

>>106546080
why are you talking about gnome in a Rust thread?

>>106546057
cope and seethe
>>106546032
>what about containers in containers?
This doesn't change anything.
>what about people that work around it by iterating indicies, then taking a reference to the ith element, then mutating the container?
this is too fucking vague to be either true or false

>>106546088
nta. look at op picrel.
even if that's not ebussy (don't care to know), there is glib in the code ;)

>>106546104
you seem smart and i appreciate your novel ideas in this thread.
can you share a demo of one of these ideas? tia

>>106546057
>>get btfo with facts and logic
No, that's what I did. You lost but you won't admit it because you're a paid shill.
klll yourself

>>106546119
>novel ideas
it's pointers 101, literally

>>106546145
but Rust has pointers. are you just seething because the borrows check told you that your code is shit?

Imagine sacrificing mutability, doubly linked list and graphs so that your language can have safe iterators.

>>106546222
https://doc.rust-lang.org/stable/std/keyword.mut.html
https://doc.rust-lang.org/stable/std/collections/struct.LinkedList.html
https://github.com/Qiskit/rustworkx

>>106545754
>That's not mutation
Pushing elements to a vector requires mutable access to it.

>you have an array of numbers, mutating the number at index [0] doesn't cause any problem.
You can have mutable references to multiple different elements of an array.

>>106546252
Because const and linked lists do not exists in other languages?

>>106532446
It doesn't though. The JVM is strongly typed and the information is preserved and influences bytecode interpretation on the host machine.

>>106545923
You can also just use destructuring to splt the references however you wish

struct Foo {
a: i32,
b: bool,
}

fn main() {
let mut arr = [
Foo { a: 1, b: true },
Foo { a: 2, b: false },
Foo { a: 3, b: true }
];

let &mut[
Foo { ref mut a, .. },
Foo { ref mut b, .. },
Foo { a: ref mut c, b: ref mut d }
] = &mut arr;

*a = 4;
*b = true;
*c = 5;
*d = false;
}

>>106546276
https://kotlinlang.org/docs/generics.html#type-erasure

>>106546250
>You can have mutable references to multiple different elements of an array.
You can't mutliple mutable references to the same elements of an array.

>>106546335
That would be undefined behavior.

>>106544958
>>106544975
Runtime checking, if you mess it up, your program might panic.

>>106546350
For you.

>>106545152
And that's not the only data you had, thus you again never explained it.

>>106546367
so? panicking is memory safe.

>this scares the Rustroon
int *array = malloc(16 * sizeof(int));

int *a = &array[0];
int *b = &array[0];

*a = 1;
*b = 2;

free(array);

>>106545461
That example is, depending on what push_all does, a bug. And the borrow checker catching that bug is a good thing and speaks in favor of borrow checking. However, the borrow checker is not free for the design of the programming language or toolchains or programmers, and it disallows a number of correct programs as well, similar to static type checking in other programming languages. Are the trade-offs worth it? Personally, I hope for a successor language to C++ and Rust.

>>106545433
>>106545479
>>106545535
>>106545656
>>106545700
Monologue?

>>106546430
meds

Rust BTFO
https://antelang.org/blog/safe_shared_mutability/

>>106545700
>Rust borrow checker is hard. cpp is easier....
Low-IQ troll, are you truly too incompetent and stupid to differentiate between unsafe and the borrow checker? Off yourself.

>>106546402
nope, see >>106545923

>>106537694
The problem is that rust prohibits this even if you put it in a reference counted wrapper.

>>106546493
what is this supposed to be? there is so much UB in there, I can't even.

>>106546585
what does reference counting have to do with mutability?

>>106546586
It's an example of why you can't have "mutliple mutable references to the same elements of an array."
The anon I replied to did not believe this would be an undefined behavior.

>>106546493
You can perfectly have 2 mutable pointers to overlapping regions of memory but I never said that you should pretend they don't alias each other.
But hey, thanks for the heads up that "unsafe" is actually a code word for malicious.

>>106546537
you don't seem to understand what disjoint means

>>106546641
pointers and references are not the same thing, dummy. of course you can have multiple mutable pointers to overlapping regions of memory.

>>106546641
>You can perfectly have 2 mutable pointers to overlapping regions of memory but I never said that you should pretend they don't alias each other.
This is true, but references and pointers are not the same thing.
Rust mutable references do not alias each other by definition. And that's why creating such references is UB and leads to unpredictable behavior.
If you want to have multiple mutable pointers to same memory just use pointers, not references.

>it's yet another "cniles beclown themselves" thread
lamao, never gets old

>>106546060

C:
>Different-types no-aliasing: Always on, unless non-standard compiler flag is used. Linux kernel uses that flag with GCC.
>Universal no-aliasing: Opt-in by using the keyword "restrict". Rarely used. AFAIK, when Rust was created and began seeing usage, which uses this heavily, a number of undiscovered and old bugs related to this were fixed in LLVM.

C++:
>Different-types no-aliasing: Same as for C.
>Universal no-aliasing: Not available, considered too difficult by some AFAIK.

Rust:
>Different-types no-aliasing: Not available.
>Universal no-aliasing: Always on for references, not on for raw pointers.

>>106532429
No one ever says this though

>>106545656
>>106545923
>>106546307
what a disgusting, anti-human language. big tech pushes all these dumb concepts like "syntax sugar" and "code readability" and then go on to sponsor the most convoluted, dipshit attempt at reinventing the wheel

>>106546652
>>106546663
Rust UB == retardation/malicious, got it

>>106546232
>https://doc.rust-lang.org/stable/std/collections/struct.LinkedList.html
Oy mate.
https://doc.rust-lang.org/stable/src/alloc/collections/linked_list.rs.html
Now write it efficiently without unsafe.

>https://github.com/Qiskit/rustworkx
Oy mate.
That isn't even a Rust crate, just an internal Rust implementation. Try again.

And here comes the drooling retard.
Everyone cheer, it's the cnile!

>>106546261
Rust seems to be the odd one out here, being bothersome to implement something as basic as a doubly-linked list in efficiently, being more or less forced to use unsafe.

rust is the satire stroustrup interview taken seriously

>number of good and novel software written in Rust in the last 10 years:
>0
Empirical evidence is all that matters. Call me back when Rust is production-ready.

>>106546813
>Now write it efficiently without unsafe.
linked lists aren't efficient though
>That isn't even a Rust crate, just an internal Rust implementation. Try again.
https://crates.io/crates/rustworkx-core
Try not being a dumb retard.

>>106546377
And still a bug, and also implies runtime overhead even when not panicking.

>references are not pointer and can't alias
>but we compile references to pointers

>>106546832
>bothersome
Doubly linked list implementation is like 30 LoC. Git gud

>>106546442
Thank you for confirming. Yes, take your meds and off yourself, low-IQ troll.

>>106546862
>references are not pointer
nobody said that.

>>106546886
>low-IQ troll.
Said the idiot that pretends that some safe pointer operations aren't safe, because it's not OK?
>>106546459
>>106546402
>>106546222

>>106546898
With what's been said in this thread, your as-a-matter-of-fact statements don't mean much.

>>106532364 (OP)
Use case for ebussy streams?

>>106546933
People told you pointers and references are not the same thing, but that doesn't mean one can't be a specific case of other.
Bools are primitive types, but primitive types are not the same thing as booleans.
References are just very specific kinds of pointers.

>>106546493
Please paste that into Miri, the Rust online playground has an option to test with Miri.

>>106546965
What for? This is just UB demonstration. Miri will just detect it as well.

>>106546980
but there are at least two other UBs before you even get to the aliasing UB.

>>106546998
Yeah there is.
Compiling playground v0.0.1 (/playground)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.55s
Running `/playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/playground`
error: Undefined Behavior: trying to retag from <296> for Unique permission at alloc157[0x0], but that tag only grants SharedReadOnly permission for this location
--> src/main.rs:12:27
|
12 | let target = unsafe { std::mem::transmute::<&u64, &mut [u64; 3]>(&arr[0]) };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this error occurs as part of retag at alloc157[0x0..0x18]
|
= help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
= help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <296> was created by a SharedReadOnly retag at offsets [0x0..0x8]
--> src/main.rs:12:70
|
12 | let target = unsafe { std::mem::transmute::<&u64, &mut [u64; 3]>(&arr[0]) };
| ^^^^^^^
= note: BACKTRACE (of the first span):
= note: inside `main` at src/main.rs:12:27: 12:78

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error

>>106546964
And I told you that you can safely have 2 mutable references or pointers to the same heap cells, mutating this cell and it is perfectly safe if it's in the 2 references are in the same thread and if the compiler frontend/backend doesn't pretend they don't alias.
That's a fact, deal with it.

>>106546641
>>106546652
Ambiguity and lack of clear and easily distinguishable definitions ruin the day again.

Rust references and raw pointers are both pointer kinds in Rust. Raw pointers are often called pointers in Rust.

>>106547014
>you can safely have 2 mutable references to the same heap cells
That's undefined behavior as demonstrated above.

>>106546794
I don't those examples have ugly code, honestly. There are far uglier examples in Rust in my opinion.

>>106547014
sure, but there are good reasons that have already been stated multiple times in this thread why Rust disallows this.

>>106547029
>That's undefined behavior
I don't give a shit about the idiotic semantics of your idiotic language. Hardware pointers and as matter of fact even emulated pointers have a logic of their own and in this logic single threaded mutability is fine.

>>106547052
>Hardware pointers
>emulated pointers
lamo

>>106547052
this also holds for platonic references to heap cells in the platonic realm

Go makes trannies go -ACK

>>106547064
You're so thick that I don't know how to talk to you.

captcha: KYS4R

>>106547052
Rust is a high level language. The pointer variables do not reflect anything in hardware, they are purely abstract. Compiler is free to express them in any way it wants, as registers, memory locations, indexes or just optimize them away completely.
Also "hardware pointers" is not really a rigid term and might mean a lot of different things. Assembly is not even a typed language so it doesn't have a concept of pointers by itself. They are just another layers of abstraction programmers use to reason about their code.

>>106546841
what do you use for 2FA OTP?

>>106533059
Given how tedious and awful serialization and deserialization are in C, and how nice it is in rust, I would assume at least some of that space is used to make things actually good. It's also bigger than in Go and C++ because the parsing is all figured out at compile time rather than using runtime reflection and bloated dynamic data structures respectively.

>>106546847
>linked lists aren't efficient though
Low-IQ, dumb, moronic, retarded troll, cease your trolling, give an efficient implementation, and off yourself.

>https://crates.io/crates/rustworkx-core
>Try not being a dumb retard.
You didn't even give the right path to the crate on Github.
https://github.com/Qiskit/rustworkx/tree/main/rustworkx-core
And that is not even the actual Rust graph library used internally, it appears to be using petgraph. And petgraph does use unsafe.

Off yourself, dumb, retarded troll.

>>106546863
Try writing it without using unsafe.
And explain to me why rustaceans were forced to write a whole book just to explain to people how to write a doubly-linked list in Rust.
https://rust-unofficial.github.io/too-many-lists/
Off yourself, retarded, nitwit troll.

>>106546905
Are those your posts? Retarded, idiot, negative-worth troll, off yourself.

>>106533073
>>106533091
>>106533351
>>106533576
>>106534021
>>106547094
imagine not double-checking rust "storage" claims on /g/
cargo new serde-sz
cd serde-sz
cargo add serde-json
nvim src/main.rs


use serde_json::Value;

fn main() {
let j = serde_json::json!{{
"code" : 200,
"success": true,
}};
let b = serde_json::to_vec(&j).unwrap();
let Ok(Value::Object(m)) = serde_json::from_slice(&b) else { panic!() };
dbg!(&m["code"]);
}


cargo build --release
% du -sh target/release
20M target/release
% du -sh target/release/serde-sz
516K target/release/serde-sz

>>106547228
everything you said is dumb and retarded

>>106546145
can you provide a demo of your run-time iterator invalidation checker?
it sounds very interesting and you sound very knowledgeable.

>>106547248
>Try writing it without using unsafe.
Why move the goalpost?

>>106547265
Did you use derive macros though?

>>106547265
NTA, but some people were not happy with Rust serde.
https://soasis.org/posts/a-mirror-for-rust-a-plan-for-generic-compile-time-introspection-in-rust/

>>106547263
How much did they hurt you?

>>106547295
That is yourself that you are describing, zero-IQ, inept troll. Off yourself.

>>106547328
Yet I didn't, zero-IQ, negative-worth troll. >>106546832 . Off yourself.

>>106547360
Are you hallucinating? Off yourself, mentally ill, moronic, incompetent troll.

>>106547397
You were talking about doubly linked lists being "bothersome to implement" and now you are talking about unsafe. These things are not synonymous, unless you are a complete beginner who doesn't understand how unsafe works.

>>106546487
>>106546886
>>106547228
>>106547248
>>106547263
>>106547377
>>106547397
>>106547425

>>106547014
Based on what? Pretty sure it's not even kosher in C++ because of aliasing.

>>106547428
>>106547447
Both of these posts mention unsafe.
>>106547248
>>106546832
Now off yourself, moronic, idiot troll.

>>106547471
>>106546717

>>106547425
I see that you are projecting again,.

>>106547511
That is yourself you are describing. Now cease your trolling, low-IQ retard, and off yourself.

>>106547471
Based on reality you fuckwit.

>>106547543
What reality? Your delusional one? Multiple mutable references implies potential data race which implies UB, thus not ok and compiler may apply no aliasing specific optimizations.

>>106547347
#[derive(serde::Deserialize, serde::Serialize)]
struct Foo {
a: Option,
b: Option,
c: Option,
d: Vec
}

fn main() {
println!("{}", serde_json::to_string(&serde_json::from_str::("").unwrap()).unwrap());
}

% du -hs .\target\release\
21M .\target\release\
% du -hs .\target\release\serde-sz.exe
160K .\target\release\serde-sz.exe

>>106547530
Ask a concurrency expert if you need a mutex when you have 2 pointers to the same object in the same thread.

>>106532441
It should be illegal to be this retarded online

>>106547561
Data race in a single thread? Sir, this is a no nigger zone.

>>106547581
You are confusing me with someone else, zero-IQ, incompetent troll. Now take your meds and off yourself.

>>106547602
...yes? Are you retarded?

>>106547604
>>106547606
Thank you for confirming how much braindead you are.

>>106547662
Yet that is yourself, not me, you are describing. Off yourself, retarded, moronic troll.

>>106547662
Single thread doesn't mean anything
Signals
Concurrency

No reason to have multiple mutable references if your software is sequentially working through things anyway.

>>106547357
the C committee "muh imposter syndrome" nigger (real one) and his posse of mastoclown trannies (real ones) are not relevant people, nor are their manic fanatic mastoclown circlejerks are relevant in the real world.

>>106547602
>>106547662
>what is an interrupt

>>106547581
https://docs.rs/tokio/1.47.1/tokio/sync/struct.Mutex.html
Yes. Even in a single threaded executor. Tasks could race without explicit locking, thus why tokio provides sync primitives even for single threaded executors.

>>106547577
tbf 10x lies are quite on the low end when it comes to made up rust target sizes and compile times.
usually the made up numbers are 50x-100x.

>>106547734
Isn't most of the Rust community and large parts of the C and C++ communities on Mastodon? I don't hang out on Mastodon, though.

>>106547829
>Rust community
NTA, but from my experience it's usually Discord or Matrix.

>>106547829
Rust community is not a monolith, despite popular /g/eet beliefs.
For the Rust project itself, zulip is where all the "real" chat happens. Otherwise, you don't have to be anywhere.
I personally only use ##rust@libera for lowkey chat, and would never come near Discord/Xitter/Mastoclown/BlueSky/...

>>106547939
https://github.com/rust-lang/ lists Mastodon and Bluesky accounts, and no Twitter/X accounts.

>>106547759
>what is an interrupt
You're right, interrupts are out of scope and references inside an interrupt routine should be treated specially. In that case yes you would need some protection, but otherwise it is fine.

>>106547795
>Yes. Even in a single threaded executor.
bullshit
>Tasks could race without explicit locking
This can only happen if the taks run on multiple threads.

Do tasks needs synchronization? Sure. But if we're talking about single threaded concurrency, you don't a mutex to make the "synchronization" (state machine-like handling in reality) work.

>>106548111
so?
the single person behind these "announcements" accounts made the X account inactive a while ago.
i don't think a single person gives a fuck.
there are rust people on every platform. i don't even have to look to know that rust discourse in e.g. telegram is infinitely bigger than in bluesky.

>>106548245
>>Yes. Even in a single threaded executor.
>bullshit
>>Tasks could race without explicit locking
>This can only happen if the taks run on multiple threads.
Preemptive single threaded schedulers exist.

stop feeding the llm jeet info. next you're going to explain preemption to "it".
just make fun of it, or leave it alone.

>>106548288
>>106548289
prophetic

>>106548288
OK, I see that for a preemptive single threaded you have essentially the same problem than with an interrupt routine. But if the scheduler is not preemptive, it is fine.

I admit than I wasn't exactly aware of those issue before though, thanks for that. Although interrupts and preemption (via signals, via interrupts) are definitely not included by what I meant by "single threaded". And those ARE edge cases, if you're honnest.

>>106548438
>And those ARE edge cases
This is typical in systems programming.

>>106548249
How does the Rust activity in Telegram compare to the Rust activity in Reddit and Hacker News?

why are freetards such commies?

>>106548245
>>106548288
>>106548438
>>106548472
Jumping into the conversation.

Isn't async/await in Rust, and thus also Tokio, cooperative and not preemptive? Or is it different definitions of cooperative and preemptive in a different context that are being used?

>>106548543
why do you care?
if you're Russian or Brazilian in particular, and interested in rust, you're already there.
the world is much bigger than anglophone circlejerk/manufactured hype platforms.

>>106548751
Aren't most of the main developers in Rust situated in the USA or Europe, at least judging by Github Insights?

>>106532364 (OP)
ebussy streaming on twitch ? Would be funny if 'teens raided him with thugs

>>106548472
>>106548472
Even in an OS the majority of the code won't have to deal with mutable shared state between 2 threads, 1 thread and 1 ISR or 2 taks running on a preemptive scheduler.
So yes, it is an edge case in the type system. There is no need to cuck the type system for 99% of the code while the 1% that pose problem can't be dealt with specially. This is complete retardation.
And let's face it, Rust is used more for shit like ripgrep than for embedded OSes and hypervisors.

>>106548438
>honnest
ESL?

>>106548800
>while the 1% that pose problem can't be dealt with specially.
*can be dealt with specially
with special kinds of references made for dealing with concurrency

>>106548800
Why not answer >>106548605 ?

Are we talking preemptive/cooperative at the OS level, or the application or programming language runtime level?

Go is more or less preemptive AFAIK, while Rust's async/await is cooperative.

>>106548802
>things that don't matter
autism?

>>106548438
>>106548850
Off yourself, zero-IQ, nitwit troll.

>>106548602
They aren't. That same picture is a 4chan banner you know.
It is a joke

>>106548605
>>106548840
>Isn't async/await in Rust, and thus also Tokio
Dunno about Tokio, but embassy supports preemptive scheduling.

>>106548605
I don't know if Tokyo is cooperative, but if it is the anon is even more full of shit than I thought.
>Or is it different definitions of cooperative and preemptive in a different context that are being used?
Relevant question with this lot but no, there is only definition for those words in the context of concurrency.

>>106548840
Are we talking preemptive/cooperative at the OS level, or the application or programming language runtime level?
It's the same. You need timers and interrupts for preemption no matter at what level (OS, user space program), it's native code.
Erlang's preemptive scheduler manages to have userspace preemption without interrupts, by counting the number of bytecode instruction executed. It uses a conditional at each instruction to know if it needs to context switch to another task or not.

Go's preemptive scheduler work by having a thread do a timer with a system call and when it's up, it sends a signal the kill system call to the other threads. The other threads which have each their own scheduler do a context switch in their signal handlers.
see: https://www.sobyte.net/post/2022-01/go-scheduling/

>>106549018
*there is only definition for those words
*it sends a signal with the kill system call

>>106548800
>Even in an OS the majority of the code won't have to deal with mutable shared state between 2 threads, 1 thread and 1 ISR or 2 taks running on a preemptive scheduler.
As soon as you have async, all the data shared between any two tasks will have to take synchronization into account.

>>106549080
Thanks, that's sums it up nicely.

>>106532364 (OP)
>glib
RefCell or some type of Rc is required due to Cnility

>>106549383
RefCell is not a type of Rc(reference counting).

>>106549396
I know it's interior mutability but It's commonly wrapped in an Rc. Dynamic borrow checking sucks but probably can't be helped in the pOOP patterns glib wants

>>106532364 (OP)
this syntax is the most pajeet-looking shit I've seen in my life

>>106549688
Why?

>>106532364 (OP)
Does a grown man really need all these dots?

>>106532364 (OP)
>build a community that constantly talks about memory safety
>implying they care about more safe programs
>fall for the rust meme, finally check it out
>to install it you run a bunch of random scripts in the shell
>ok weird but I'm just going to go ahead and learn anyways
>the entire community that talks about memory safety just tells you to install 50000 crates instead of answering your questions

why is the language that always talks about safety so okay with packages from random chinese developers that have very low level access to your system?

something smells glowy about rust. Also it's not fun to write.

>>106550201
I use dots too for visible whitespace but they're lighter in my theme.

>>106532364 (OP)
Rust is King.

>>106550323
Tcl is a lot more vital than Rust.

>>106550201
I use the rainbow indent extensions, they're much easier to differentiate, and they highlight the indents that aren't properly formatted.

>>106532364 (OP)
Tbh, if you have problems understanding the intricacies of Rust, you can just some AI like ChatGPT or Grok to explain them to you. They're both trained on official docs and can answer any question you have. Example prompt: "Explain Rust's borrow checker to me like I'm 12 years old."

>>106547092
>no reply
lol

>>106532364 (OP)
>>106532441
he's using glib, so he's refcounting all over the place anyway

why do you torture yourself with Rust when C++ exists? or even C (if you are this kind of person).