The Case for Rust (in the base system)

cracauer@ said:
The problem with garbage collecting C and C++ is that objects are not allowed to move.
Click to expand...
Maybe not entirely true. This guy
Code: 
https://m.youtube.com/watch?v=mbdXeRBbgDM
did it. Go to 21:15 or so.
 
cracauer@ said:
The problem with garbage collecting C and C++ is that objects are not allowed to move.
Click to expand...
Indeed. std::move is such a stupid name.

What you end up with many GC APIs is a pointer to a pointer. Other languages hide this well but with C, C++ and i.e Rust, it is fairly clunky.
One of the better attempts I have seen with C++ is C++/clr's ^. But granted that is a language extension rather than merely a library.
 
msplsh said:
Why would you do this?
Click to expand...
Because there are some cases that you have to use tracing garbage collector, for exmaple vm of gc language, ui library(because of complex components relationship) and entity component system. Sometimes you can't determine which reference is primary and which is secondary, and you can't determine which should be destructed first.
 
cracauer@ said:
The problem with garbage collecting C and C++ is that objects are not allowed to move. So there is no compaction for better cache and TLB hit rates and you still have to fill fragmentation holes, Worst of all worlds, really.
Click to expand...
Maybe I'm misunderstanding or overlooking something, but isn't it possible to move physical page keeping its virtual address by OS?
It shoul not work for kernel level, but for application level, programs uses virtual address and runs regardless its physical address (to which physical address a virtual address is mapped cannot be known by application unless an API exists to request the data).
 
It won't help. You may have objects spread throughout 100s of MB to GBs of memory, with a fair bit of garbage objects in between. Most objects die young so for example, if you have 90% garbage objects, you are using up 10 times as many pages (and you will have 10 times as many TLB misses). On most modern machines a cacheline is 64 bytes, which a cons cell in Lisp would be likely 16 bytes so when objects are not packed tightly you are also wasting a lot of cache lines. There has been a lot of research in this area if you are interested! Another deep rabbithole!
 
T-Aoki said:
Maybe I'm misunderstanding or overlooking something, but isn't it possible to move physical page keeping its virtual address by OS?
It shoul not work for kernel level, but for application level, programs uses virtual address and runs regardless its physical address (to which physical address a virtual address is mapped cannot be known by application unless an API exists to request the data).
Click to expand...
If the hardware has an MMU and substantial OS; certainly.

But this does eliminate much embedded hardware.
 
T-Aoki said:
Maybe I'm misunderstanding or overlooking something
Click to expand...
Overlooking, possibly. Cache lines are set associative, meaning you have N lines available for data that come from a certain address pattern. With the correct access pattern you can render almost all caching futile. Also, if all your data is small but aligned at 64 byte boundaries, you dramatically increase the memory bandwidth requirements. The cache will always read a complete line, and not care how much you actually need of that.
 
I personally find the rust documentation too overwhelming. The specification is too thick .. It feels like a language only for really very intelligent persons.
sbcl,gerbil,zig,nim,crystal,haxe,ocaml,ada,idriss2 do a better thing on this subject.
It's not only for gods but also for mortals.
 
Alain De Vos said:
I personally find the rust documentation too overwhelming. The specification is too thick .. It feels like a language only for really very intelligent persons.
sbcl,gerbil,zig,nim,crystal,haxe,ocaml,ada,idriss2 do a better thing on this subject.
It's not only for gods but also for mortals.
Click to expand...
Instead, it is for normal persons who aren't sure about they are correct. C/C++ is for very very intelligent persons. Rust is complex because it wants to ensure that you always do everything correctly, even if you know what you are doing, in this case, its syntax will seem very boilerplate and redundant.
 
I don't think the amount of documentation is a good guide here. Things with literal tons of documentation are falling apart and things with no documentation carry on and on...
 
kpedersen said:
Amusingly Rust has loads of documentation and books. Purely because the culture of Rust users is that they love to talk about Rust more than actually writing software using it.
Click to expand...

I thought the problem is that there is too much software moving to Rust :)
 
kpedersen said:
Amusingly Rust has loads of documentation and books. Purely because the culture of Rust users is that they love to talk about Rust more than actually writing software using it.
Click to expand...
More amusingly, the 737 can not carry the documentation of the bird when it would be printed out. But then if it can't fly it won't matter if the wheels do come off...
 
Crivens said:
But then if it can't fly it won't matter if the wheels do come off...
Click to expand...
Sounds like a safe solution.

A very good point. So it turns out that Rust's #1 safety feature isn't the borrow checker. Instead it is the fact that people are too busy writing about it rather than potential bugs with it.
 
You must log in or register to reply here.
Back
Top