6 ms·

I think it makes sense for some segments of the programming world and not others. On Google Earth, garbage collection pauses weren't really acceptable, but we

I think it makes sense for some segments of the programming world and not others. On Google Earth, garbage collection pauses weren't really acceptable, but we also wanted to add new functionality without being slowed down. Rust is great for a lot of reasons, but as many know, it can be slower on the feature velocity front. In some AAA games, they need much more flexibility than the borrow checker thinks is appropriate. At some point, one has so many unsafe blocks that undermine the guarantees of surrounding code, that it makes more sense to use a different paradigm. I know it's taboo to say this, but in many real world use cases, memory safety bugs aren't that bad and have the severity of any other logic error. Having a few more bugs per release might be worth it, if it means not dealing with the borrow checker's restrictions around abstraction, encapsulation, and polymorphism. You just fix them and push a new release. Also, the problem is nicely mitigated by tools like Address Sanitizer, and will get even better with upcoming advances such as memory tagging and generational references, all which detect memory problems with surprising efficacy and accuracy. In short, manual memory management is the right choice when Rust's drawbacks are a bit too much, and benefits aren't enough, for a particular situation. Just my two cents!

Kranar 4y ago
>I know it's taboo to say this, but in many real world use cases, memory safety bugs aren't that bad and have the severity of any other logic error. I don't think it's true of many real world use cases and if anything is only true of perhaps trivial use cases, where an application is run on a computer that has no other sensitive information and is not connected to the Internet. I think what's true is that many programs don't ever reach a point where they're popular enough that someone can reliably exploit it. The threat of memory related errors has not much to do with use case and more to do with whether someone cares enough to identify that error, can reliably reproduce it, and whether the application that exhibits that error is on enough computers that exploiting it is profitable. If those three conditions are satisfied then it matters not whether the program is a video game, a word processor, an image viewer or whatever.
- throwawaymaths 4y ago
  > I don't think it's true of many real world use cases and if anything is only true of perhaps trivial use cases, If you're running a single threaded cloud lambda, you could allocate into an arena and never free, so you don't get UAF or DF.
- verdagon 4y ago
  A lot of apps don't need internet access, or only communicate with a single (trusted) website, with no data exchanged with other users. I might even say most apps.
  - deleted 4y ago
    [deleted]
  - woodruffw 4y ago
    Regardless of whether this is true (I don't think it is), it's probably not the right metric: even if Microsoft Word was completely offline and had no way to make Internet connections (it does), memory unsafety in it is exploitable by getting a user to open a file. (And the funny thing about "trusted" communications: they're trusted until an attacker figures out how to store and forward untrusted data, at which point a logic error in the server itself is now nicely composable with code that "didn't need" to be particularly memory safe.)
  - tempodox 4y ago
    Isn't the whole point of an exploit to go beyond what the software was originally built to do?
adamnemecek 4y ago
> Also, the problem is nicely mitigated by tools like Address Sanitizer, and will get even better with upcoming advances such as memory tagging and generational references, all which detect memory problems with surprising efficacy and accuracy. It would be nice if languages had Address Sanitizer built into the language. Maybe some sort of system of checking who owns and borrows memory at any point in time.
- kaba0 4y ago
  Isn’t Zig’s debug mode something similar?
nine_k 4y ago
A memory safety error usually leads to some kind of exploit, with a bit of bad luck, to an RCE. This may not be a big deal for a toy game like Tetris. In a multiplayer AAA game it could lead to a bunch of bitter consequences though, from malware pwning customers' computers to ruined multiplayer experience because the bug would affect the server. I'd say that a memory safety bug is not like a blemish on the surface of a building, unsightly but tolerable. It's more like a crack in the foundation, which may look tiny on the surface, but who knows how deep it goes.
- deleted 4y ago
  [deleted]
- verdagon 4y ago
  Sure, I don't contest that memory unsafety has some large drawbacks of its own. I'm glad that languages are innovating in memory safety. My comment was about the tradeoffs we make for our memory safety guarantees, and whether they're always worth it.
lumost 4y ago
Modern low latency GC like Shenandoah/golang and to a lesser extent g1 mitigate the pause issue pretty substantially. It’s impossible to verify, but some of the workarounds in very large c apps seem like they have about as much overhead as A modern GC.
- eklavya 4y ago
  You missed ZGC, that’s great.
  - dralley 4y ago
    Shenandoah and ZGC are roughly at par with each other (although ZGC has greater reach because Oracle), but yes that is true with ZGC as well.
- verdagon 4y ago
  That's probably acceptable for most use cases. On Google Earth, even sub-millisecond pauses would have been too much, we had to fight pretty hard for every sliver of performance we could get.
  - jcelerier 4y ago
    That's not acceptable in any GUI or multimedia case, which is, by far, what most people do with their computers. Current screens have a 240hz refresh rate, deadline for a frame is 4ms (and more realistically 2-3ms because your program isn't the only one hogging the cpu) ; 1ms GC stall is up to half of your time budget.
- jandrewrogers 4y ago
  At a prior job (writing database kernels in C++), code commits were automatically rejected if any core operation had an observed tail latency of 1 millisecond under stress tests. Also a way to become unfortunately familiar with storage firmware behavior. A GC with a worst-case latency in low milliseconds is a big improvement over the bad old days I remember, but that is still too high for data infrastructure performance-engineering. The effectiveness of some key optimizations were sensitive to how tight we could make tail latencies for important operations, so a GC always had an unacceptable cost to the extent it occasionally introduced a stall at an inopportune moment. If GC stalls were more like 10 microseconds, consistently, that would be much more viable. I have no idea if that is realistically achievable.
dralley 4y ago
>On Google Earth, garbage collection pauses weren't really acceptable, but we also wanted to add new functionality without being slowed down. Rust is great for a lot of reasons, but as many know, it can be slower on the feature velocity front. I have some doubt that Rust feature velocity is meaningfully worse than C++ or C. I would bet good money the other way to be honest.
- verdagon 4y ago
  I've found it depends on what paradigm one is using. The borrow checker is great in some architectures that agree with it, but pretty incompatible with a lot of basic abstractions and can therefore impose more artificial complexity and refactoring in many situations. It also depends on one's familiarity with the languages, I've used both pretty extensively and can't comment on the velocity when just learning. Just my experience, YMMV.
  - dureuill 4y ago
    > Just my experience, YMMV. Indeed. IME (around 10y C++, mostly c++14 and c++17, and 6y Rust), I measure x2-x3 velocity in Rust, a lot of which comes from the tooling, a part of which from ub-freedom and much easier and safer parallelism, and the rest from the expressive type system and functional polish. This is for initial development. Factoring in the maintenance over the years I suspect it tends to an order of magnitude of difference.
  - kouteiheika 4y ago
    > It also depends on one's familiarity with the languages, I've used both pretty extensively and can't comment on the velocity when just learning. When you're just learning it Rust can definitely be a lot less productive and a lot more frustrating. But once you get to an expert level I think there's just no contest, and you can churn out code high quality code significantly faster than you can in C++. (At least that's how it is for me, and I've been programming C++ for over 10 years and I'm don't intend to ever go back.)
kaba0 4y ago
I recently wrote a toy JVM implementation in Rust where basically the whole Java-semantic memory management has to happen without the borrow-checker’s guarantees. But contrary to expectations, I didn’t have many unsafe usages — they were all hidden under some abstraction (like allocate_object function of an ObjectPool), there is perhaps 7-8 in the whole (semi-partial) implementation? (Though it doesn’t yet have a GC, so there is that). So all in all, in my anecdotal experience one can reasonably well hide the unsafe usages and then use the good expressivity of the language to combine these APIs in strictly safe ways. I also ran the program regularly through MIRI (a rust AST interpreter, which is similar to Valgrind in goals for my use-case) and whenever I found a memory bug I could pin-point it to a few lines of code at most, greatly speeding up debugging.
- evnix 4y ago
  do you have it somewhere on github? I would definitely want to check it out

Kranar 4y ago

>I know it's taboo to say this, but in many real world use cases, memory safety bugs aren't that bad and have the severity of any other logic error. I don't think it's true of many real world use cases and if anything is only true of perhaps trivial use cases, where an application is run on a computer that has no other sensitive information and is not connected to the Internet. I think what's true is that many programs don't ever reach a point where they're popular enough that someone can reliably exploit it. The threat of memory related errors has not much to do with use case and more to do with whether someone cares enough to identify that error, can reliably reproduce it, and whether the application that exhibits that error is on enough computers that exploiting it is profitable. If those three conditions are satisfied then it matters not whether the program is a video game, a word processor, an image viewer or whatever.

throwawaymaths 4y ago
> I don't think it's true of many real world use cases and if anything is only true of perhaps trivial use cases, If you're running a single threaded cloud lambda, you could allocate into an arena and never free, so you don't get UAF or DF.
verdagon 4y ago
A lot of apps don't need internet access, or only communicate with a single (trusted) website, with no data exchanged with other users. I might even say most apps.
- deleted 4y ago
  [deleted]
- woodruffw 4y ago
  Regardless of whether this is true (I don't think it is), it's probably not the right metric: even if Microsoft Word was completely offline and had no way to make Internet connections (it does), memory unsafety in it is exploitable by getting a user to open a file. (And the funny thing about "trusted" communications: they're trusted until an attacker figures out how to store and forward untrusted data, at which point a logic error in the server itself is now nicely composable with code that "didn't need" to be particularly memory safe.)
- tempodox 4y ago
  Isn't the whole point of an exploit to go beyond what the software was originally built to do?

adamnemecek 4y ago

> Also, the problem is nicely mitigated by tools like Address Sanitizer, and will get even better with upcoming advances such as memory tagging and generational references, all which detect memory problems with surprising efficacy and accuracy. It would be nice if languages had Address Sanitizer built into the language. Maybe some sort of system of checking who owns and borrows memory at any point in time.

kaba0 4y ago
Isn’t Zig’s debug mode something similar?

nine_k 4y ago

A memory safety error usually leads to some kind of exploit, with a bit of bad luck, to an RCE. This may not be a big deal for a toy game like Tetris. In a multiplayer AAA game it could lead to a bunch of bitter consequences though, from malware pwning customers' computers to ruined multiplayer experience because the bug would affect the server. I'd say that a memory safety bug is not like a blemish on the surface of a building, unsightly but tolerable. It's more like a crack in the foundation, which may look tiny on the surface, but who knows how deep it goes.

deleted 4y ago
[deleted]
verdagon 4y ago
Sure, I don't contest that memory unsafety has some large drawbacks of its own. I'm glad that languages are innovating in memory safety. My comment was about the tradeoffs we make for our memory safety guarantees, and whether they're always worth it.

lumost 4y ago

Modern low latency GC like Shenandoah/golang and to a lesser extent g1 mitigate the pause issue pretty substantially. It’s impossible to verify, but some of the workarounds in very large c apps seem like they have about as much overhead as A modern GC.

eklavya 4y ago
You missed ZGC, that’s great.
- dralley 4y ago
  Shenandoah and ZGC are roughly at par with each other (although ZGC has greater reach because Oracle), but yes that is true with ZGC as well.
verdagon 4y ago
That's probably acceptable for most use cases. On Google Earth, even sub-millisecond pauses would have been too much, we had to fight pretty hard for every sliver of performance we could get.
- jcelerier 4y ago
  That's not acceptable in any GUI or multimedia case, which is, by far, what most people do with their computers. Current screens have a 240hz refresh rate, deadline for a frame is 4ms (and more realistically 2-3ms because your program isn't the only one hogging the cpu) ; 1ms GC stall is up to half of your time budget.
jandrewrogers 4y ago
At a prior job (writing database kernels in C++), code commits were automatically rejected if any core operation had an observed tail latency of 1 millisecond under stress tests. Also a way to become unfortunately familiar with storage firmware behavior. A GC with a worst-case latency in low milliseconds is a big improvement over the bad old days I remember, but that is still too high for data infrastructure performance-engineering. The effectiveness of some key optimizations were sensitive to how tight we could make tail latencies for important operations, so a GC always had an unacceptable cost to the extent it occasionally introduced a stall at an inopportune moment. If GC stalls were more like 10 microseconds, consistently, that would be much more viable. I have no idea if that is realistically achievable.

dralley 4y ago

>On Google Earth, garbage collection pauses weren't really acceptable, but we also wanted to add new functionality without being slowed down. Rust is great for a lot of reasons, but as many know, it can be slower on the feature velocity front. I have some doubt that Rust feature velocity is meaningfully worse than C++ or C. I would bet good money the other way to be honest.

verdagon 4y ago
I've found it depends on what paradigm one is using. The borrow checker is great in some architectures that agree with it, but pretty incompatible with a lot of basic abstractions and can therefore impose more artificial complexity and refactoring in many situations. It also depends on one's familiarity with the languages, I've used both pretty extensively and can't comment on the velocity when just learning. Just my experience, YMMV.
- dureuill 4y ago
  > Just my experience, YMMV. Indeed. IME (around 10y C++, mostly c++14 and c++17, and 6y Rust), I measure x2-x3 velocity in Rust, a lot of which comes from the tooling, a part of which from ub-freedom and much easier and safer parallelism, and the rest from the expressive type system and functional polish. This is for initial development. Factoring in the maintenance over the years I suspect it tends to an order of magnitude of difference.
- kouteiheika 4y ago
  > It also depends on one's familiarity with the languages, I've used both pretty extensively and can't comment on the velocity when just learning. When you're just learning it Rust can definitely be a lot less productive and a lot more frustrating. But once you get to an expert level I think there's just no contest, and you can churn out code high quality code significantly faster than you can in C++. (At least that's how it is for me, and I've been programming C++ for over 10 years and I'm don't intend to ever go back.)

kaba0 4y ago

I recently wrote a toy JVM implementation in Rust where basically the whole Java-semantic memory management has to happen without the borrow-checker’s guarantees. But contrary to expectations, I didn’t have many unsafe usages — they were all hidden under some abstraction (like allocate_object function of an ObjectPool), there is perhaps 7-8 in the whole (semi-partial) implementation? (Though it doesn’t yet have a GC, so there is that). So all in all, in my anecdotal experience one can reasonably well hide the unsafe usages and then use the good expressivity of the language to combine these APIs in strictly safe ways. I also ran the program regularly through MIRI (a rust AST interpreter, which is similar to Valgrind in goals for my use-case) and whenever I found a memory bug I could pin-point it to a few lines of code at most, greatly speeding up debugging.

evnix 4y ago
do you have it somewhere on github? I would definitely want to check it out