Re:Rust and the Future of Systems Programming [video]
by worik on Wednesday November 16, 2016 @03:43PM
(#12971307)
"C also doesn't provide latency guarantees, as the same pathological programs can exist in C as well."
But you have to code them. They are predictable, or you let them in by allowing data structures to grow indefinitely
With C you can make latency guarantees. You can write code that does not have such guarantees but it is your choice
With GC you are not in control so there are fewer choices. You will not be able to make guarantees.
Re:Rust and the Future of Systems Programming [video]
by naasking on Wednesday November 16, 2016 @03:53PM
(#12971405)
> With GC you are not in control so there are fewer choices. You will not be able to make guarantees.
Not true. Hard and soft realtime GCs with sub-microsecond latencies exist. Latency is a property of a runtime, not of manual vs. automatic storage reclamation.
Re:Rust and the Future of Systems Programming [video]
by worik on Wednesday November 16, 2016 @05:36PM
(#12972257)
That is a misunderstanding of latency.
"Very fast" is still latency.
Re:Rust and the Future of Systems Programming [video]
by naasking on Thursday November 17, 2016 @12:43AM
(#12974685)
"No latency" is a fiction. The only question of any relevance is how much latency is tolerable for a given domain. And describing latency in worst-case timings is standard, so I understand latency just fine thanks.
Re:Rust and the Future of Systems Programming [video]
by steveklabnik on Wednesday November 16, 2016 @02:54PM
(#12970823)
What is the pathological case with lifetimes? You're saying it takes "time proportional to the number of dead objects to free", but as the parent said, lifetimes are a compile-time construct, so they have no runtime properties.
(I'm not saying that for sure there are none, I'm saying that it seems like you're talking about refcounting only, the lifetime bit is unclear to me.)
Re:Rust and the Future of Systems Programming [video]
by Rusky on Wednesday November 16, 2016 @02:58PM
(#12970879)
I suspect they're referring to graphs of Drop implementors, based on the sibling thread. If you for some reason have a linked-sea-of-nodes data structure that has to traverse itself on drop, that can behave similarly to dropping an Rc graph, though it still doesn't use lifetimes.
Re:Rust and the Future of Systems Programming [video]
by steveklabnik on Wednesday November 16, 2016 @03:01PM
(#12970907)
I guess that would make sense, but I'm not sure it's lifetime-specific though. C++ doesn't have lifetimes but would still have this problem.
Re:Rust and the Future of Systems Programming [video]
by naasking on Wednesday November 16, 2016 @03:09PM
(#12970983)
Yes, C/C++ would also have this problem. The point I was trying to make is that incrementality/latency is a property of a runtime. If your program has deep ownership graphs, any kind of naive reclamation procedure is going to have high latency, even if it's written in C/C++.
Re:Rust and the Future of Systems Programming [video]
by steveklabnik on Wednesday November 16, 2016 @03:18PM
(#12971064)
Quite fair! Thanks for elaborating.
I never said they did, I said lifetimes and reference counting both have this pathological case.
C also doesn't provide latency guarantees, as the same pathological programs can exist in C as well. It's a total myth that you need C in realtime domains due to "latency".
Maximum pause times are a property of a particular runtime, not a language.