5 ms·

I get it. Languages are where major security gains are going to be made. Everyone knows that. That being said, the proselytizing is obnoxious.

roca 7y ago
That's fair. I'm probably guilty of that sometimes. Personally, I find it obnoxious when people start new projects in C code because they're comfortable with the language and unwilling to learn something better, and those projects contribute to the toxic cesspool of vulnerable software that is undermining civilization.
- youdontknowtho 7y ago
  Sure, but the toxic cesspool that is undermining civilization has less to do with software and more to do with the way that we have organized civilization. I can understand what you mean, though. It's really lame to hear "that's how we've always done it". My personal opinion, however, is that language's like Rust are still taking the wrong approach because we should be making the computers manage the memory for us. Much of the guarantees from Rust's type system could also be gained by more advanced garbage collection or designing hardware in conjunction with garbage collectors to get around some of the thornier issues in that field. If you could take out the perceived drawbacks of garbage collection, then there isn't a reason to do manual memory management. That's my personal soapbox, though, and I could go on. Cheers.
  - steveklabnik 7y ago
    One of the key differences here is that there are resources other than memory. GCs can help you manage memory, but not other kinds of resources that also need managed.
    - youdontknowtho 7y ago
      I don't mean to sound dense, but couldn't all resource management be automated to a large degree? It's not my area, so I am really asking, not trying to be a smart a.
      - steveklabnik 7y ago
        That's what languages like Rust are trying to accomplish, yes. But it attempts to do so by unifying the systems used to manage these resources; what you're advocating is using GC for memory, which means you need two systems now: the GC for memory, and something for everything else. Languages like Rust say "that's too complex, let's use one system for all things."
        youdontknowtho 7y ago
        I get that, but why couldn't you use something like GC for resource management. Maybe I sound stupid here, but it seems like the kind of task that machines would be better at than humans.
        steveklabnik 7y ago
        You can! The performance is not as good. For many applications, you don't have to care about performance. Rust is specifically designed to get maximum performance, so it can't be the default mechanism. (Swift basically does what you're talking about, for example)
        youdontknowtho 7y ago
        Sweet. Thanks, pal.
  - roca 7y ago
    I agree that not having to reason about lifetimes can lower the cost of software development. However, GC is a very well-developed field, both in research and in practice, and I don't expect any game-changing breakthroughs there in the forseeable future. All GCs impose significant performance tradeoffs --- forcing you to take a hit on at least one of (worst-case) latency, throughput, and memory overhead. Apart from pure reference-counting, they require some sort of runtime support and make it difficult to write code that can be used as a library by non-cooperative applications (e.g. C programs). (Hardware support for GC can be interesting but then you have the problem that there's no one-size-fits-all GC that works well for all languages and workloads.) I agree that for some applications the overheads of GC are fine and wrangling lifetimes is tricky enough you should use a GC-based language, not Rust (and probably not Swift either, since it's easy to write Swift-style reference counting in Rust). However --- Rust lifetimes are about more than just memory safety and performance. They also enable data race freedom and strong control over aliasing, which prevent other kinds of bugs and can enable higher degrees of optimization. They enable affine types, which let you write APIs with very nice static guarantees, e.g. that a Nonce value is only used once. I don't think we're fully exploiting Rust lifetimes yet. It's also important to remember that for many applications Rust lifetimes are hardly any burden at all. For lots of code I write --- serial, synchronous code manipulating off-the-shelf data structures where the overall shape of the heap is tree-ish, or DAG-ish and reference counting is acceptable --- I hardly have to think about them at all.
- dmitrygr 7y ago
  > I find it obnoxious when people start new projects in C Indeed, how dare they spend their own free time doing things you find obnoxious? The scoundrels! > and unwilling to learn something better They also seem to not be willing to blindly accept your judgement instead of their own in terms of how best to implement things they wish to! How inconsiderate of them!
  - roca 7y ago
    > Indeed, how dare they spend their own free time doing things you find obnoxious? That's not the obnoxious part. The obnoxious part is where their vulnerable software gets deployed and subverted to harm to third parties. > They also seem to not be willing to blindly accept your judgement I certainly wouldn't ask anyone to blindly accept anyone else's judgement. The evidence is in.
    - dmitrygr 7y ago
      Okay. Don't use their software. Unless somebody is making you? You are entirely free to write your own versions in whatever language you want. Speaking the way you do, though, you just sound like an ingrate. Take a moment to thank all those people writing that software you use, instead of telling them that they are being obnoxious.
      - roca 7y ago
        When someone writes a buggy C library and someone deploys that library in some set of devices, which are compromised and used as part of a botnet that DDoSes my site, I'm hurt through no choice that I made. When I buy something from a shop and their database gets hacked via some bug and my data is extracted, I'm hurt even though I had minimal control over the situation. Vulnerable software is a negative externality, like air pollution.
        dmitrygr 7y ago
        You are free to not buy any product or use any service that uses code not written in the language of your choice.

roca 7y ago

That's fair. I'm probably guilty of that sometimes. Personally, I find it obnoxious when people start new projects in C code because they're comfortable with the language and unwilling to learn something better, and those projects contribute to the toxic cesspool of vulnerable software that is undermining civilization.

youdontknowtho 7y ago
Sure, but the toxic cesspool that is undermining civilization has less to do with software and more to do with the way that we have organized civilization. I can understand what you mean, though. It's really lame to hear "that's how we've always done it". My personal opinion, however, is that language's like Rust are still taking the wrong approach because we should be making the computers manage the memory for us. Much of the guarantees from Rust's type system could also be gained by more advanced garbage collection or designing hardware in conjunction with garbage collectors to get around some of the thornier issues in that field. If you could take out the perceived drawbacks of garbage collection, then there isn't a reason to do manual memory management. That's my personal soapbox, though, and I could go on. Cheers.
- steveklabnik 7y ago
  One of the key differences here is that there are resources other than memory. GCs can help you manage memory, but not other kinds of resources that also need managed.
  - youdontknowtho 7y ago
    I don't mean to sound dense, but couldn't all resource management be automated to a large degree? It's not my area, so I am really asking, not trying to be a smart a.
    - steveklabnik 7y ago
      That's what languages like Rust are trying to accomplish, yes. But it attempts to do so by unifying the systems used to manage these resources; what you're advocating is using GC for memory, which means you need two systems now: the GC for memory, and something for everything else. Languages like Rust say "that's too complex, let's use one system for all things."
      - youdontknowtho 7y ago
        I get that, but why couldn't you use something like GC for resource management. Maybe I sound stupid here, but it seems like the kind of task that machines would be better at than humans.
        steveklabnik 7y ago
        You can! The performance is not as good. For many applications, you don't have to care about performance. Rust is specifically designed to get maximum performance, so it can't be the default mechanism. (Swift basically does what you're talking about, for example)
        youdontknowtho 7y ago
        Sweet. Thanks, pal.
- roca 7y ago
  I agree that not having to reason about lifetimes can lower the cost of software development. However, GC is a very well-developed field, both in research and in practice, and I don't expect any game-changing breakthroughs there in the forseeable future. All GCs impose significant performance tradeoffs --- forcing you to take a hit on at least one of (worst-case) latency, throughput, and memory overhead. Apart from pure reference-counting, they require some sort of runtime support and make it difficult to write code that can be used as a library by non-cooperative applications (e.g. C programs). (Hardware support for GC can be interesting but then you have the problem that there's no one-size-fits-all GC that works well for all languages and workloads.) I agree that for some applications the overheads of GC are fine and wrangling lifetimes is tricky enough you should use a GC-based language, not Rust (and probably not Swift either, since it's easy to write Swift-style reference counting in Rust). However --- Rust lifetimes are about more than just memory safety and performance. They also enable data race freedom and strong control over aliasing, which prevent other kinds of bugs and can enable higher degrees of optimization. They enable affine types, which let you write APIs with very nice static guarantees, e.g. that a Nonce value is only used once. I don't think we're fully exploiting Rust lifetimes yet. It's also important to remember that for many applications Rust lifetimes are hardly any burden at all. For lots of code I write --- serial, synchronous code manipulating off-the-shelf data structures where the overall shape of the heap is tree-ish, or DAG-ish and reference counting is acceptable --- I hardly have to think about them at all.
dmitrygr 7y ago
> I find it obnoxious when people start new projects in C Indeed, how dare they spend their own free time doing things you find obnoxious? The scoundrels! > and unwilling to learn something better They also seem to not be willing to blindly accept your judgement instead of their own in terms of how best to implement things they wish to! How inconsiderate of them!
- roca 7y ago
  > Indeed, how dare they spend their own free time doing things you find obnoxious? That's not the obnoxious part. The obnoxious part is where their vulnerable software gets deployed and subverted to harm to third parties. > They also seem to not be willing to blindly accept your judgement I certainly wouldn't ask anyone to blindly accept anyone else's judgement. The evidence is in.
  - dmitrygr 7y ago
    Okay. Don't use their software. Unless somebody is making you? You are entirely free to write your own versions in whatever language you want. Speaking the way you do, though, you just sound like an ingrate. Take a moment to thank all those people writing that software you use, instead of telling them that they are being obnoxious.
    - roca 7y ago
      When someone writes a buggy C library and someone deploys that library in some set of devices, which are compromised and used as part of a botnet that DDoSes my site, I'm hurt through no choice that I made. When I buy something from a shop and their database gets hacked via some bug and my data is extracted, I'm hurt even though I had minimal control over the situation. Vulnerable software is a negative externality, like air pollution.
      - dmitrygr 7y ago
        You are free to not buy any product or use any service that uses code not written in the language of your choice.