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
>uses tool in the language to do something
what did OP mean by this?

>>106532364
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
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
i've never seen this text editor. what's this?

>>106532364

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.

File: as I suspected.gif (1.22 MB, 453x344)

1.22 MB GIF

>>106532364
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.

File: 1757426589489.png (18 KB, 671x71)

18 KB PNG

>>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

File: 1757426702767.png (35 KB, 1243x121)

35 KB PNG

>>106532699

>>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

File: 1747938294475268.jpg (99 KB, 576x960)

99 KB JPG

>>106532364
> "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)

File: 1740726455947090.jpg (218 KB, 1048x1080)

218 KB JPG

>>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

File: 1757444819030.jpg (21 KB, 460x460)

21 KB JPG

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