The reason I get a use-after-free is because I put my method on the wrong struct.
-
-
Replying to @steveklabnik
in a GC'd language, this code would work, but would use more memory, and the design issue would still be there
1 reply 1 retweet 11 likes -
Replying to @steveklabnik
i think this is sort of what
@withoutboats often says about ownership and lifetimes, it's not really *just* about low-level issues1 reply 1 retweet 25 likes -
Replying to @steveklabnik @withoutboats
in this case, rust is making my design better and faster
2 replies 1 retweet 10 likes -
Replying to @steveklabnik
Do Rust people measure time spent doing frees? IIRC GC'd langs can be faster than non-GC'd counterparts due to memory mgmt optimizations
5 replies 0 retweets 4 likes -
Replying to @tenderlove @steveklabnik
I think a lot of the performance benefit you get in Rust is from cache locality, which GC languages struggle with.
1 reply 0 retweets 8 likes -
there are just a lot *less* allocations, in Rust than in Java or a dynamic language, regardless of how they're managed
1 reply 1 retweet 6 likes -
Replying to @withoutboats @tenderlove
yup.
@wycats has been talking about this a lot lately2 replies 0 retweets 0 likes -
Go might be an exception since I believe they do more to try to stack allocate values (and in general are doing a lot on GC perf)
2 replies 0 retweets 2 likes -
Replying to @withoutboats @steveklabnik and
Go doesn’t do any more to stack allocate values than Java does. Go just depends on it a lot more because of poor (IMHO) GC design.
1 reply 0 retweets 4 likes
(Specifically, Go optimizes for low latency above all else, which results in at least 10x slower malloc than typical industry GCs.)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.