Solving Rust’s biggest problem

Рет қаралды 58,156

Күн бұрын

Unveiling the most significant improvement to the Rust compiler yet. Witness how Rust is overcoming it's compilation hurdles and solidifying its position as a top-tier programming language.
Free Rust cheat sheet: letsgetrusty.com/cheatsheet

Пікірлер: 198

@letsgetrusty 3 ай бұрын

📝Get your *FREE Rust cheat sheet* : letsgetrusty.com/cheatsheet

@OrbitalCookie 3 ай бұрын

Slow build aren't because of rust "carefully checking the program". You can use "cargo check" and see how fast that is. It's slow because of colossal pile of unoptimized intermediate code it dumps on LLVM and says "here buddy, have fun, I know you are good at this". Problem is exacerbated by any use of generics or smart macros. Try to use small alternatives for clap and serde_json, and you will see huge improvement to compile times. Since this comment has blown up, this was what I remembered from the olden rust days. Now there is MIR representation in the compiler with possible optimizations before the LLVM.

@ITSecNEO 3 ай бұрын

"unoptimised IR Code" 😂 Well tell that to the compiler team and see their reactions xD

@ME0WMERE 3 ай бұрын

@@ITSecNEO It _is_ unoptimised. That's kind of the point. LLVM is the one optimising it, not the front end

@OrbitalCookie 3 ай бұрын

@@ITSecNEO Well this is nothing new to them, it was a design decision from the start to leave optimisation to LLVM

@naturalworm 3 ай бұрын

Way to sneak "unoptimised ir code" code in there. I doubt the rust proj homies would let that slide.

@letsgetrusty 3 ай бұрын

Good point! I didn't mean to imply that checking the program for correctness is the only or even most significant reason for long compile times

@MichaelZimmermann 3 ай бұрын

0:50 "when people complain about slow builds, they're almost always talking about the slow release build" Do you have a source for that? Because it surprises me a lot. I only care about debug build times because they need to be done often. Release builds are done rarely and run in CI so I don't really care how long they take.

@7Dev. 3 ай бұрын

Tal cual pibe, tenes razon

@binary_gaming113 3 ай бұрын

This! I was gonna write the same comment, I couldn't agree more.

@kevinmcfarlane2752 3 ай бұрын

Yes, I thought that was odd too.

@LtdJorge 3 ай бұрын

Yes, I’m doing API dev with Tokio, Diesel (async), bb8, Axum, etc and the compiles every time I change something are pretty long, for compiling with 32 threads and linking with mold.

@legeorgelewis3530 3 ай бұрын

This video is terrible. full of misinformation

@pcfreak1992 3 ай бұрын

Sure it takes long to compile, but do you rather scroll Facebook waiting for the build to finish or do you want to chase a bug down a rabbit hole, trying to figure out why some variable is undefined?

@Virtuoso883 3 ай бұрын

Well when you put it like that, i prefer to chase a bug down a rabbit hole.

@shinobuoshino5066 3 ай бұрын

Ah yes, the most obscure and most impossible to fix bug: undefined variable.

@OrbitalCookie 3 ай бұрын

Hey where is the excitement of all the busy work figuring out why undefined is not an object or a function? Where is the glory putting out fires of our own creation? You are no fun.

@jayrulez 3 ай бұрын

Are those the only 2 options?

@vaisakhkm783 3 ай бұрын

Facebook... old man detected...

@perfectionbox 3 ай бұрын

instead of rustc the compiler could have been called crust 🤣

@jongeduard 3 ай бұрын

Good point. :P Maybe a great name for the Crablang fork? 🦀 :P

@weirdalchemy 3 ай бұрын

"Eats personal time" No shot I'm letting compile time eat my personal time. Shit compiles on the clock.

@_Aarius_ 3 ай бұрын

I am working on a perf critical app at work, in Rust, so even my dev/debug has to use release optimisations so I can find regressions immediately. Compile times suck lmao

@tatoute1 3 ай бұрын

Your regressions are release specific? How come?

@kebbil 3 ай бұрын

they're using the trust_me! macro@@tatoute1

@darxoonwasser 3 ай бұрын

@@tatoute1 I assume performance regressions?

@isaaclyman8024 3 ай бұрын

They should rewrite the compiler in Rust. Then it would be super fast and completely memory sa-*I walk face first into a sliding glass door*

@jongeduard 3 ай бұрын

Huh? Well, it already is written in Rust. In the long ago past it was written in OCaml (also a great language by the way), but nowadays Rust is obviously compiling itself, like a proper compiler should always be able to do.

@cernilia3211 3 ай бұрын

i think this suppose to be a joke. with the sliding glass door and everything

@jay.rhoden 3 ай бұрын

Can't decide if it's sarcasm or a joke. (Perhaps its both)

@adsick_ua 3 ай бұрын

"compilation time decreased from about ten seconds (9.57) to about eight seconds (8.28)" you sound like it's 2 sec improvement whereas it's actually 1.29 sec, dude. don't be like that, off by 47%

@paladynee 3 ай бұрын

hah, not even a single order of magnitude. such precision is not needed. i was off by 1e1e15 once.

@ZoeSoutter 3 ай бұрын

The exact values are 1.29 seconds, but he likely rounded both figures before subtracting. I'm not saying you're wrong, I'm just saying he isn't really either

@letsgetrusty 3 ай бұрын

Fair points, not the best example to showcase this feature

@Jiftoo 3 ай бұрын

The parallel frontend is consistently slower on (most) of my personal projects, by about one or two seconds. The only time it was actually faster for me is building the tokio repo (about a second of improvement in debug and half a second in release). I guess it only speeds things up in niche situations, like workspace builds(?)

@oefzdegoeggl 3 ай бұрын

Building a large program in "Borland C++ 1.0" was a pain in the ass compared to the then super-fast TurboPascal. I don't find rusts's debug compile times thaaat dramatic. For release, yes, especially with LTO turned on. But I do release build when ... well, releasing only, so not a big issue for me.

@MiesvanderLippe 3 ай бұрын

Alternatively, think more and compile less. It is not Python :)

@AdamFiregate 3 ай бұрын

I do just that. I think that could even out productivity vs. compile time. 👍🌞💛

@TehKarmalizer 3 ай бұрын

Observing the effects of modified code is sometimes the e best way to facilitate thinking about it.

@ShrirajHegde 3 ай бұрын

Except the parsing and semantic analysis is also done constantly inside the language server. This means you have to complete your full thought and type the whole thing before the typing debounce kicks in. This statement is kind of like "if your code is bad, just make it good"

@ShrirajHegde 3 ай бұрын

Also, python is an interpreted language. And the compilation to bytecode is practically instant. What the hell are you compiling? 😂

@chonkusdonkus 3 ай бұрын

additionally*

@dirac7233 3 ай бұрын

As long as they don't sacrifice some runtime performance for conpile-time fastening, I'm ok with the new improvement. I always set `codegen-units` to `0`.

@KSmifune 3 ай бұрын

Tauri needs this update

@theelmonk 3 ай бұрын

We used to have slow compile times for *everything*. This was a real pain for C because the compiler is bad at getting out of sync and producing spurious errors. You could analyse the messages so far and then they became meaningless. So there was a tendency to fix the first error or two then recompile and re-evaluate. This avoided wasting time fixing errors that were really only parse failures. Now if you have better error messages due to more static typing and less loss of sync, it's worth considering more of the reported errors before giving up and recompiling. This increases productivity by getting more work done in the edit phase and requiring less compile cycles. Does Rust provide this advantage ? if you work differently, do you get similar edit/compile time ratios that you would with fast compilation ? Also, remember xkcd:303

@exciting-burp6613 3 ай бұрын

Cranelift is going to be a bigger boost. LLVM is one of the slowest parts of the compiler. The biggest issue _by far_ is the use of ld, you can get a significant boost by configuring lld (or mold) today.

@adsick_ua 3 ай бұрын

love Cranelift

@khhnator 3 ай бұрын

i din't knew that cranelift was a thing, this certainly help things if the compile times are that bad in debug build

@theLowestPointInMyLife 3 ай бұрын

I was excited to hear about this a while ago but upon trying it out, the threaded option is actually slower than single threaded. 24 core Ryzen 5900x normal: 23.4s threads: 26.8s the results are very consistent, around 15% slower with threads

@SaHaRaSquad 3 ай бұрын

Did you use 8 threads like recommended in the video or all available? It may be possible that there's a sweet spot and adding more doesn't make it faster. Years ago I once benchmarked a program on a CPU with 4 cores & threads and for some reason it ran the fastest with 32 threads. Going higher or lower would make it run slower. Performance is weird.

@Luxalpa 3 ай бұрын

As they wrote in the blog post, it strongly depends on the project, particularly how the dependency tree looks like

@theLowestPointInMyLife 3 ай бұрын

@@SaHaRaSquad yh, tried with 8 and 12, same results

@diadetediotedio6918 3 ай бұрын

@@theLowestPointInMyLife Maybe it is the code you are compiling tho, or even a bug in the implementation (as it is nightly).

@theLowestPointInMyLife 3 ай бұрын

@@diadetediotedio6918 yeah, its not uncommon, ive seen many people reporting the same thing, I dont really care tbh, its a non issue for me, my 23s is compiling from clean, when im changing some code with cargo watch running, it only takes about 4s, mildly annoying at worst

@SimoLPers 3 ай бұрын

Why does this feel like a dejavu? Is this a reupload by any chance?

@norude 3 ай бұрын

Please, make a video, explaining the nightly-only feature, that will never come in to prod

@CitizensCommunity 3 ай бұрын

The more threads and faster you run the compile, the less optimization it can do and the slower the resulting binary. It is a trade off between speed of the compile, vs speed of your code, which is more important to you?

@theelmonk 3 ай бұрын

Unfortunately, because of Moore's Law, in 90% of commercial environments in a tradeff between speed of compilation (and other development) and speed of execution, speed of execution loses hands down. And has done for 40 years.

@MikeM8891 3 ай бұрын

I would have preferred if you tried a Bevy hello world fresh compile. That takes about 5 minutes on my computer.

@v0idmatr1x 3 ай бұрын

Mold linker and sccache speed up comp times for me

@bruceritchie7613 3 ай бұрын

I just did a test on a codebase I work on. With this flag on nightly 10:24. On stable without the flag 11:09.

@StefaNoneD 3 ай бұрын

Rust compilation is IMHO still much faster than C++ compilation without C++ modules.

@jeffg4686 3 ай бұрын

@0:18 - good, the compiler. I thought it might have been a lawsuit when you said "taking them seriously". That's cool about the compile times. They weren't that bad before actually for typical projects but always welcome news.

@SaHaRaSquad 3 ай бұрын

Compile times vary a LOT based on the number and kind of dependencies in your project.

@jeffg4686 3 ай бұрын

@@SaHaRaSquad- but only first compile, which is no biggie

@SaHaRaSquad 3 ай бұрын

@@jeffg4686 No, some dependencies can actually cause even recompilation to be 30 seconds or longer. I don't know how that's possible but it's happened to me in the past.

@DavidAlsh 3 ай бұрын

Dynamically loaded rlibs plz (for plugins)

@PoopSqueezenuts 3 ай бұрын

Awh yeah, lets get that ISO standard going and make that compiler lightning fast

@ferdynandkiepski5026 3 ай бұрын

-Zthreads=8 has been available for quite some time already. Is there a timeline for when this flag will be stabilized?

@theLowestPointInMyLife 3 ай бұрын

it has never worked, actually compiles slower

@wiono 3 ай бұрын

compile time = coffee break. I don't see a problem.

@Boxing_Gamer 3 ай бұрын

Yes lol but you cant take a coffee break every 5 minutes

@diadetediotedio6918 3 ай бұрын

@@Boxing_Gamer It's not needed every 5 minutes, most of the slowest compiles comes from specific structural changes in the project, the other types of compilations are usually sufficiently fast (like 1-5s max).

@ggsap 3 ай бұрын

thats not an excuse. and coffee makes me sleepy

@abdullahmertozdemir9437 3 ай бұрын

@@ggsap what kind of metabolism do you need to get sleepy from coffee

@SteinGauslaaStrindhaug 3 ай бұрын

@@abdullahmertozdemir9437 for me I think it's my ADHD, caffeine has no psychoactive effect on me, it only very slightly increases heart rate and it helps migraines. But it is a warm drink, and warm drinks make me sleepy. 😅

@sunofabeach9424 3 ай бұрын

it's funny you mentioned Rayon. its error messages are insane

@carlosmspk 3 ай бұрын

insane as in incredibly unhelpful or insane as in incredibly useful?

@sunofabeach9424 3 ай бұрын

@@carlosmspk first. It correctly indentifies the problem (type mismatching) but the problem is detected at method call, not at struct creation (where it actually occures), so you spend your time trying to fix a correct piece of code because you trust Rust's compiler. In other languages, it is just a regular error message, but since it's Rust we're talking about, I expected it to be as usually precise. Luckily, people on Stack Overflow are accustomed to Rayon and know how to deal with it from experience

@SaHaRaSquad 3 ай бұрын

In my experience Rust's error messages are outstanding until the code gets too generic or macro-heavy, at which point the quality plummets noticeably. There are even situations where the compiler incorrectly throws an error in 100% valid macro code. That and readability in general are the reasons I usually avoid abstractions and generics and it's a very pleasant experience - but I can only do that because I write Rust in my free time.

@sunofabeach9424 3 ай бұрын

@@SaHaRaSquad yeah but if you are not the only person who writes that code or even if you're alone but your code gets complex and is about to scale more, it becomes a shltshow

@pmmeurcatpics 3 ай бұрын

@@SaHaRaSquadoh that's definitely true. I've also noticed it with custom structs of iterator functions, like Difference, Union, Iterable etc. - you know you're screwed the moment the error messages start looking like "ATypeOfTypesOfLifetimeATypesOfdynTypes doesn't implement ATraitOfTypeIntoAType"

@follantic 3 ай бұрын

A rust interpreter for development would be nice.

@Boxing_Gamer 3 ай бұрын

Didn't have a problem when using the mold linker and dynamic linking.. I'm not sure there is a problem anymore really

@WorstDeveloper 3 ай бұрын

Isn't mold very limited though?

@Boxing_Gamer 3 ай бұрын

@@WorstDeveloperDon't know. I've had no problems

@WorstDeveloper 3 ай бұрын

@@Boxing_Gamer Afaik it only supports linux, right? I know that they forked Mold and named it Sold, with the intention of making a paid version for Mac and Windows. But no one wanted to pay for it so I think the development of that fork is pretty dead now.

@Boxing_Gamer 3 ай бұрын

@@WorstDeveloper Too bad. I guess the only option for windows users then is to have a Linux machine or partition while using Rust.

@Seacrest. 3 ай бұрын

installing trunk takes about 10 minutes

@thegoldenatlas753 3 ай бұрын

Took me 20s. You sure pc isn't just trash?

@1____-____1 3 ай бұрын

@@thegoldenatlas753There will always be devs that compile on a potato and complain about it.

@alexray4969 3 ай бұрын

@@1____-____1 I would rather have it be slow on my computer, than completly disregarded performance and expecting my clients computer to be just as fast as mine. It's like activating artificial network speed throttling in the web devtools, so you develop the website from the start in a way that works on slow networks as well.

@markmanning2921 3 ай бұрын

My forth compiler compiles over 4 megabytes of source per scond and is SINGLE threaded. On my 12900k it would probably be much faster and unlike rust Forth is actually a readable language :)

@dupdrop 3 ай бұрын

Doesn't most of the compiler slowness come from llvm, and generating bloated LLVM IR?

@buffer0xaa555 3 ай бұрын

No, the Lexer is bottleneck of frontend part in the compiler.

@dupdrop 3 ай бұрын

@@buffer0xaa555 I was not talking about the compiler frontend, but the whole compiler as whole. Even non optimized lexers are super fast programs, lexing is very simple.

@zweitekonto9654 3 ай бұрын

Wait, it still isn't self hosted?

@buffer0xaa555 3 ай бұрын

@@dupdrop Logically simple but it take a lot instruction to the computer.

@diadetediotedio6918 3 ай бұрын

@@zweitekonto9654 Obviously it is self hosted, but as most languages the final process of the machine code generation and optimizations is done by the old good LLVM.

@defender2212 3 ай бұрын

If I don't have to wake up at 4am then I don't have any problem with compile time. ❤

@krux02 3 ай бұрын

If the only approach on tackling compile times is parallelizing and incremental compilation, then it is good night for high performance compilation. Other languages compile many orderes of magnitude faster than rust, and still don't use parallel builds or incremental compilation at all. just to name some: Vlang and Jai

@ITSecNEO 3 ай бұрын

JAI and Vlang are not full of useful features yet lol. Wait until their compilers get more complex and you will See the exact same Problems xD

@ruanpingshan 3 ай бұрын

2:52 Wait, did it actually use 14 GB of RAM for compilation?

@illusion466 3 ай бұрын

doubtful. Windows ram always looks like that

@darwinikii9589 3 ай бұрын

trt1 turkey mentioned

@torarinvik4920 3 ай бұрын

I have an issue with when using vectors of some enum I cannot see the values in the debugger even though they are there. It's a bit frustrating not having the ability to see the values in my code. I have to use print statements, but I cannot use those in the unit tests. I never had this issue in any other programming language. I love rust but this is really annoying.

@avsaase 3 ай бұрын

Cargo swallows prints to stdout by default. Run your tests with `cargo test -- --nocapture` to override that.

@antelope6826 3 ай бұрын

I’d rather have longer compile times than a night of debugging a dumb programming mistake

@rmbl349 3 ай бұрын

I compile on a ryzen 7950. What's your problem?

@replicadse 3 ай бұрын

The biggest problem with Rust is the Rust Foundation and its policies.

@ScienceMinisterZero 3 ай бұрын

evcxr could replace ipython for data science if only it weren't so laggy.

@luquini8246 3 ай бұрын

tell me if I'm wrong. I have a REST API made with Actix and SQLx. It builds in... 10 seconds max. I never saw it as an issue. I can check my email, change the music, make myself a coffee, etc. It's a real problem for you guys? or you are experiencing larger building times?

@georgehelyar 3 ай бұрын

Yea I don't really have a problem with it, maybe because microservices are individually small. The main thing that makes me not care is that I don't need to compile to see compile errors though, they show up immediately in the editor as I'm typing.

@ITSecNEO 3 ай бұрын

They should just change the default linker, the most bottleneck in all of this. The frontend is already pretty fast, its the backend that scks

@Tumbolisu 3 ай бұрын

i just want to mention xkcd comic 303

@MoonrayMurray 3 ай бұрын

Good video!

@tulsatrash 3 ай бұрын

Armature Science.

@rusmemes 3 ай бұрын

I do not understand this problem at all. Why not having a cup of coffee (tea|bear|vodka|whatever you like) while compilation process???

@shinobuoshino5066 3 ай бұрын

Because I'm not a drug addict and don't want to ruin my kidneys in a day.

@lgasc 3 ай бұрын

@@shinobuoshino5066 A fruit then?

@valcubeto 3 ай бұрын

Specially when using Tokio

@llFike 3 ай бұрын

God, sexbots even in programming related channels? jesus

@thingsiplay 3 ай бұрын

At least they don't even try to hide and makes it easy to ignore. Thank god they have these images. I don't even need to read the text. Wait until they are all upgrading to AI and actually try to look like a human being. That's when KZfaq comments really die.

@cls880 3 ай бұрын

It knows the Rust demographic

@thingsiplay 3 ай бұрын

@@cls880They are everywhere, regardless of the content.

@andrewdunbar828 3 ай бұрын

What does "cut by a factor of 3 mean"? It now runs in 1/3 of the time? Or 1/3 of the time was cut so it now runs in 2/3 of the time?

@Diragonix 3 ай бұрын

1/3

@danielhalachev4714 3 ай бұрын

It means it's three times faster now.

@ethan82714 3 ай бұрын

I think what it meant was that 1/3 of the time was removed, meaning it takes 2/3 the time.

@danielhalachev4714 3 ай бұрын

@@ethan82714 No, "by a factor of 3" means "three times" and you can see the new column chart is at roughly a third of the old chart's height. Anyway, why does it even matter so much?

@ethan82714 3 ай бұрын

@@danielhalachev4714 oh ok

@CKidder80 3 ай бұрын

Honestly, this is a tempest in a teakettle. I could not care less about how long it takes to compile. Make Hello World take 30 seconds if that means the compiler does a great job, checks the code thoroughly, and the resulting executable is as optimized as possible. The compile time is the least of my worries. I'd like my programs to work properly and quickly. That's the #1 goal. Compile speed is cool and all but that worry comes after most everything else. So, I think Rust got it right. It checks programs thoroughly, it tries to optimize well. After that's all said and done, sure, let's get it compiling faster too. But, calling that it's biggest problem is actually a GREAT sign. If we're down to "it takes 10 seconds too long to compile" then obviously things are in excellent shape.

@ryleitdept 3 ай бұрын

C++ numbawan!

@Randych 3 ай бұрын

Anyone complaining about cargo build times is welcome to run cabal build on 0 imports project.

@johnjakson444 3 ай бұрын

inserting that clip of that loathsome kanye was stupid, didn't come here to see that kind of crap

@bot. 3 ай бұрын

If the compiler is too slow then just... rewrite it in rust?

@svenyboyyt2304 2 ай бұрын

The problem is that it uses LLVM which has a lot of work put into it, so the end result might not be as good and not as many targets would be supported. It should be done, but it's not easy.

@viniciusataidedealbuquerqu2837 3 ай бұрын

problem with rust compile time is llvm or the backend. making the frontend faster is only 30% of the job. the other 70% is moving off of llvm at dev cycle. only use llvm when build --release is enabled

@rodrigosouto9502 26 күн бұрын

Nice!

@GeorgeFosberry 3 ай бұрын

Rust compile times are very pleasant already when you.compare them to a medium to large C++ project. Full clean build can take 30 minutes or more, not your pesky seconds.

@kevinmcfarlane2752 3 ай бұрын

If we only had C++ in this space then maybe there would be less concern about slow compile. But there’s the fast Go. Yes, their application domains aren’t coincident but they do overlap considerably. So that provides an incentive to speed things up.

@GeorgeFosberry 3 ай бұрын

@@kevinmcfarlane2752 Well, the only thing *I* have available to me at work is C++14. And that's not going to change any time soon. "Muh compile times!" cries seem just inane to me. Like, really?

@iaphlnt 3 ай бұрын

It takes seconds for a trivial project in either language, the problems arise as the codebase gets bigger

@akbulutm4 3 ай бұрын

As bayrakları as as 🇹🇷🇹🇷🇹🇷

@lightprogrammer 3 ай бұрын

less compile time = less coffee time, so its a loss

@metatechnologist 3 ай бұрын

I mean really I need to check messages anyway....

@adriankal 3 ай бұрын

The difference is too small to make any dev more productive.

@doods_0 Ай бұрын

Maybe the benefit is when installing cargo packages for normal usage.

@no-bias- 2 ай бұрын

1 second faster from 9 seconds. How about make it 1 second from 9 seconds instead of "1 second faster"?

@idwtgymn 3 ай бұрын

I have a hard time seeing how you end up compiling so often it becomes an actual productivity issue. Sounds like people are throwing spaghetti at the wall to try to fix bugs, I don't see how else you compile so frequently you have a problem with sub-minute delays. Maybe those long waits will give them a chance to do what they should, and fix their bugs by actually reading their code.

@sunhsiang6644 Ай бұрын

Coding 2 minutes,building 2 hours 😂

@Pushons-gg2nw 3 ай бұрын

for development and testing code we could use jit or interpreted and for publishing and bundling we could use the traditional compiling 🤔

@svenyboyyt2304 3 ай бұрын

No, that's not the issue. Creating the machine code is not the slow down, it's mainly the checks.

@dmitriidemenev5258 3 ай бұрын

@@svenyboyyt2304 Also proc macros.

@diadetediotedio6918 3 ай бұрын

@@svenyboyyt2304 What is the source of your claims that creating machine code is not one of the biggest slowdows? We know this is a problem even for zig, as they are creating their own compiler backend for debug mode just because LLVM is slow.

@danielhalachev4714 3 ай бұрын

@@diadetediotedio6918LLVM isn't slow, C++ also uses it and it compiles at a very decent speed. It really is mostly because of the borrow checker.

@martg0 3 ай бұрын

what happened to the rust foundation drama?

@yoni532s9M5w 3 ай бұрын

Rust's biggest problem is its syntax

@CoDEmanX47 3 ай бұрын

A bit disappointed that the video is about the compiler and not that it is extremely hard to properly parallelize code.

@user-le8gc3th8x 3 ай бұрын

Its not biggest problem of rust. His biggest problem is impossibility to make more than one mut borrow. As result writing any tree-like structure to complex. So even c++ better than rust for gamedev. And its reason why crutch like RefCell exist.

@patrickmiharisoa5501 3 ай бұрын

More than one mutable borrow can potentially lead to data race

@svenyboyyt2304 3 ай бұрын

No, that's by design. Using things like RefCell isn't bad.

@diadetediotedio6918 3 ай бұрын

Lol, this is like almost the whole reason of why Rust is considered memory safe, you cannot make crazy things like borrowing an item from an array and then trying to clear the array while it is in use (or overwrite the item or anything). And for game dev, you have bevy which abstracts on top of the Rust limitations and gives you a safe interface for handling game logic, you would not need to worry about that in games because usually you would build things in a more unsafe manner and just expose the safe abstractions.

@hayden.A0 3 ай бұрын

Rust preventing you from using multiple mut borrows is essentially forcing you to do things the right way. Things like multiple mutable borrows are a big cause of memory errors and security holes in programs using C or C++. Rust is thus "harder" to program with but gives much better guarantees about memory safety. It's the whole point of Rust.

@tablettablete186 3 ай бұрын

Isn't it Arc used for this exact scenario?