Rust
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
Why did it fail, /g/?
>>51747029
SJW tbf (to be frank)
>>51747029
It didn't
>>51747029
Because the only language that can improve on C++ is... C++. It's never going away.
>>51747029
>Mozilla
It was doomed from the start.
>>51747029
They didn't bother proving safety formally so their claims are useless.
>>51747029
>wants to replace C
>garbage collection
for fucks sake
>>51747178
>garbage collection
>rust
>>51747148
I can let that slide. I'm more disappointed that they claim to be safety-oriented when their safety guarantees are hardly better than what you can already do with move semantics and integer templates in C++.
>>51747178
It has optional GC like Golang and C# and D.
>>51747178
>>51747328
You two have no idea what you're talking about
>>51747178
It's almost like your just finding out C is a shit language.
>>51747178
daily reminder that a gc is faster and more reliable than you free'ing and malloc'ing everything yourself
>>51747483
>faster
Nope.
>more reliable
Not with a good type system. I'm talking about one that's far stronger than Rust's, here, by the way.
>>51747029
Why did meme language XYZ fail? Because it's not needed, not supported, and can practically do nothing because it has no useful library.
>>51747029
We have more than enough languages. We don't need extras.
>>51747515
It is faster almost always.
free() and malloc() are low-level primitives. You need to build higher forms like arenas, deletion queues, and so forth in order to attain good performance.
In the end, garbage collection has 50 years and counting of research and development - something few programmers have.
>>51747708
>You need to build higher forms like arenas, deletion queues, and so forth in order to attain good performance.
And what part of that is implied by "garbage collection"?
>>51747029
>mozilla
are you nigging me? those fuckers couldn't deliver stable software if their lives depended on it
>>51747735
Garbage collection algorithms have become very advanced and incorporate ideas similar to these in many cases. Look up the Copying algorithm to see an example of Arena-style management in a GC.
>>51747708
GC isn't faster, it can be detrimental to performance if you are a horrible programmer
JIT compilation however is a miracle of modern engineering that c programmers wrongly accuse of causing bad performance
>>51747178
Rust uses RAII, not garbage collection.
>>51747483
Speed depends entirely on the garbage collector. As for reliability, I would highly val that into question. Garbage collectors are nondeterministic, while RAII can guarantee that memory and other resources will always be freed up when no longer in use.
>>51747762
Still, explicitly- or at least deterministically-operated custom allocators, picking the right type for a given scenario, are far more efficient than that kind of GC.
>>51747852
Highly call that into question.*
Goddamn autocorrect.
>>51747762
>>51747867
And I'm actually still dubious about a Cheney GC being faster than even naive malloc() and free(). There's a lot involved in making that copy, especially if you don't want to invalidate pointers and have it be thread-safe.
>>51747178
ffs educate yourself on a topic before you post about something.
RUST DOES NOT DO GARBAGE COLLECTION. RUST DOES NOT EVEN DO RUNTIME REFERENCE COUNTING.
RUST DOES COMPILE-TIME REFERENCE COUNTING, AND CUES WHEN MEMORY WILL BE RELEASED BY INFERRING WHEN IT IS NO LONGER REQUIRED
this is basic shit.
>>51747946
The point is, it's not manual management where the programmer actually knows what he's doing.
>>51747946
>RUST DOES NOT EVEN DO RUNTIME REFERENCE COUNTING.
but Rust does use RC shared pointers as need be, anon...
not everything falls perfectly into std::unique_ptr<T> and T& use cases.
>>51747868
>using a phone
I'm starting to dislike you more and more.
>>51747762
And most of the advanced GC techniques are impossible for systems languages.
>>51747708
>It is faster almost always.
that's a bullshit narrative pushed by the D, Java, etc. crowds that conflates various aspects of what "fast" means.
what they really mean is that frees (and subsequent heap maintenance) can be pushed off to a separate thread outside the critical path loop of a program, which can indeed improve throughput.
however, this is a well known technique that is by no means exclusive to GCs, and it sidesteps and obscures the issues of system pauses for GC sweeps.
for some users, "fast" may mean guaranteed worst case latency to process a message, 99% percentile time, etc.
nobody gives two shits about vidya framerates going from 30 to 35 fps if it introduces quarter-second stutters every minute or two, and nobody in market trading cares about average throughput if a system can see random millisecond-level stalls.
>>51749922
It's not wrong though. It's almost always faster.
Not everything is directed towards HFT.
>>51747070
/thread
>>51750146
holy shit, this is currynigger-tier retardation.
literally the only trick GC can claim to provide is out-of-banding heap reclamation, which is more effective on a manually managed memory system anyway.
everything else about GC is highly detrimental to speed, particularly the way that it bloats memory footprints by typically ~2x and trashes all the CPU's caches whenever it does a scan or trace.
please just don't parrot Walter Bright.
even D backpedaled on the issue and added the 'nogc' directive last year since performance was falling even further behind modern C++ techniques and heap implementations.
>>51747708
Yeah, and with C++ you can still write your custom allocators if you want to achieve better performance. Note: it doesn't have to always call malloc and free on every new and delete. Still no gc.
