News for hackers. Stuff that matters.
Re:Implications of Rewriting a Browser Component in Rust by rwmj on Thursday February 28, 2019 @08:16PM (#19277140)
This was also my experience. It's a fine language if you can't (or more usually "won't" for spurious reasons) use a garbage collector. However a lot of things are just easier to do using a GC, and I suspect in many, not all, of the use cases of Rust, a GC would be just fine.

(Also I have to rant here a bit: Yes I know the GC you used in Java or Emacs in 1997 was terrible, but modern GCs are very good indeed)

Re:Implications of Rewriting a Browser Component in Rust by tasty_freeze on Thursday February 28, 2019 @10:47PM (#19277768)
The garbage collector in 80s MS BASIC was incredibly inefficient. The routine was written on to minimize the amount of memory to perform the GC, something like 8 bytes.

It would simply iterate through every entry in the temp string stack and then all the entries in the symbol table to find the string with the lowest address above whatever was the previous lowest address. After that full sweep, it would move that string to its new home and adjust pointers to it, then set the new low bound to the string just identified. It would keep iterating until all strings had been visited.

As a result, it required (n2)/2 sweeps of memory (n=# of strings). Having BASIC lock up for 30 seconds every once in awhile was just how it went.

[ and in case someone is going to correct me, it might have swept from top of memory to bottom, I have forgotten the details ]

Re:Implications of Rewriting a Browser Component in Rust by woolvalley on Friday March 01, 2019 @01:57AM (#19278506)
Graphs are OK in reference counting languages like swift / objective-c, it doesn't have to be done with a GC.

I think you could use Rc<Thing> in rust too if you want to solve it using rust, but then you have "swift with more boilerplate" as one friend said.

Re:Implications of Rewriting a Browser Component in Rust by rwmj on Friday March 01, 2019 @12:52PM (#19283451)
Ref counting is a poor kind of garbage collection. In particular it has a very large overhead: typical GC has an overhead of a couple of bits per allocation, but ref counting usually wants to allocate an extra word (eg. 32 or even 64 bits) per allocation.

Another actually more serious problem is that typical ref counting implementations mix the allocated data with the references, so that when you inc/dec the reference you dirty a cache line containing the data. There exist implementations which improve on this by storing the references in a separate part of memory, but they are not how it's commonly implemented.