6 ms·

> In Rust, I can be 100% confident that I will not have memory-unsafe code. Not 98%-and-I’d-better-check-those-last-2%-really-closely. One hundred percent. That

> In Rust, I can be 100% confident that I will not have memory-unsafe code. Not 98%-and-I’d-better-check-those-last-2%-really-closely. One hundred percent. That’s a game-changer. Also achievable, and far more easily, with a tracing GC. Do you know all those people worrying about memory safety in Lisp decades ago? Me neither.

marijn 7y ago
Not all invariants relate to allocation. Rust protects you from a whole class of shared-mutable-state issues that JavaScript and Lisp are zero help with.
- atilaneves 7y ago
  > Rust protects you from a whole class of shared-mutable-state issues Rust is not alone in this. I think Pony is a good example.
zaarn 7y ago
Except in some situations you don't have a GC or can't afford one (hard realtime, embedded devices, osdev).
- pjmlp 7y ago
  Hard realtime, I do agree, there you can even afford any kind of memory allocation, everything needs to be statically defined usually. Embedded devices, depends on the use case, PTC, Aicas, MicroEJ, Astrobe have plenty of happy customers. Same applies to OSDEV, Midori did not have any big problems powering a couple of Microsoft systems before the powers to be decided it wasn't going to be a Windows replacement.
  - jstimpfle 7y ago
    > Midori did not have any big problems powering a couple of Microsoft systems. I will believe that when I see the performance under load with my own eyes, and when I can convince myself that the code is not more cumbersome than manual memory management would be.
    - pjmlp 7y ago
      You are free to belive whatever you wish, meanwhile the world moves on.
  - zaarn 7y ago
    GC in osdev has quite a large number of problems, performance being one of them, the other being that some resources simply can#t be handled cleanly by a language that can't opt out of a GC. You somewhat need the option to atleast manage some memory very very manually. And of course, the GC needs to work without allocating memory (ie, true in-place GC) otherwise you're going to blow of your kneecaps of fairly spectacularly (this goes double when you need to initialize memory management, which can't rely on a memory allocator being present or free memory being available)
    - pjmlp 7y ago
      Yet it has been achieved multiple times. The only thing missing is having companies like Apple and Google are doing with their mobile OSes, "my way or nothing". Usually those that have enjoyed GC aware OSes know what they were capable of, and those that never have, think they know how bad they were.
      - zaarn 7y ago
        There is a difference between "can be done" and "can be done well enough to be market ready".
        pjmlp 7y ago
        Politics and money.
- atilaneves 7y ago
  These situations exist and in those, something like Rust is a very good idea. I maintain that these situations are far rarer than most people imagine (and I've had to deal with more than a few).
dgb23 7y ago
I agree. Memory safety is a problem solved 60 years ago and adopted by most mainstream languages, or rather most languages period. Rust doesn't solve memory safety, it just lets you do it in a more performant way. But the compiler does quite a bit more than just allow for performant memory safety. It enforces rules around mutability and handling errors which are usually only seen in functional languages. None of these things are special about Rust. The special thing is that Rust can do these things with less computer resources while asking more of the programmer. And this is a general truth. Type systems add friction and force programmers to deal with details from the very beginning. In the long term this might often be a good thing, but it certainly isn't ergonomic.
- carlmr 7y ago
  >Type systems add friction and force programmers to deal with details from the very beginning. In the long term this might often be a good thing, but it certainly isn't ergonomic. In Rust, I agree, but I find coding in C#/F# which are decently typed, but with GC, is much faster for me than using e.g. Python. Typescript is much easier than Javascript. Lack of types usually leads to worse auto completion, errors maybe only found on some edge cases which I didn't try and a huge slow down if I need to add a feature when I've forgotten about the code, since they provide a lot of documentation where you know that it's not stale. I wouldn't use python at all if it didn't have pandas.
  - shpongled 7y ago
    Totally agree. If I'm writing anything nontrivial then it's going to be in a statically and explicitly typed language. There can be some friction, but the additional tools and speed in refactoring make up for it, IMO. At this point I only use python for pandas and matplotlib, or for sending small psuedocode snippets to coworkers
  - dgb23 7y ago
    Auto-completion for some dynamic languages has gotten much better with the right tools/editors/plugins. I get where you are coming from but I would argue that there is a bit of a perception issue here. You can surely write fast in typed languages but you also have to write more and think more. But I fully agree with the benefits. Errors, changing/refactoring and documentation. I wonder if we can have the best of both worlds some day. Prototype dynamically and then add types and abstraction progressively in the same language and code base. In theory this is doable with Lisps, but only in a self-imposed, possibly unstructured way.
tus88 7y ago
What is 2% of the Rust code is in unsafe blocks so you do something useful?
- timw4mail 7y ago
  Rust unsafe blocks are generally a few different things: * Calls to C functions (which can't be checked for safety) * Cycles or mutable access which can't be checked for safety by the compiler * Performance-sensitive code, which ignores bounds checking (again, which can't be checked for safety by the compiler) The point of `unsafe` is to fence in the memory danger into the smallest possible points.
sacado2 7y ago
This is not memory-safety per se, but Rust goes further, though. You can't have 2 objects that can modify the same object at the same time, for instance, as in: l1 = [1, 2, 3]; l2 = l1; l2.push(0); // Oops, I also modified l1, was it expected?
- deleted 7y ago
  [deleted]
- atilaneves 7y ago
  This depends on the language. The one with GC I know best, D, would reallocate l2 when pushing to it so l1 wouldn't be modified.

marijn 7y ago

Not all invariants relate to allocation. Rust protects you from a whole class of shared-mutable-state issues that JavaScript and Lisp are zero help with.

atilaneves 7y ago
> Rust protects you from a whole class of shared-mutable-state issues Rust is not alone in this. I think Pony is a good example.

zaarn 7y ago

Except in some situations you don't have a GC or can't afford one (hard realtime, embedded devices, osdev).

pjmlp 7y ago
Hard realtime, I do agree, there you can even afford any kind of memory allocation, everything needs to be statically defined usually. Embedded devices, depends on the use case, PTC, Aicas, MicroEJ, Astrobe have plenty of happy customers. Same applies to OSDEV, Midori did not have any big problems powering a couple of Microsoft systems before the powers to be decided it wasn't going to be a Windows replacement.
- jstimpfle 7y ago
  > Midori did not have any big problems powering a couple of Microsoft systems. I will believe that when I see the performance under load with my own eyes, and when I can convince myself that the code is not more cumbersome than manual memory management would be.
  - pjmlp 7y ago
    You are free to belive whatever you wish, meanwhile the world moves on.
- zaarn 7y ago
  GC in osdev has quite a large number of problems, performance being one of them, the other being that some resources simply can#t be handled cleanly by a language that can't opt out of a GC. You somewhat need the option to atleast manage some memory very very manually. And of course, the GC needs to work without allocating memory (ie, true in-place GC) otherwise you're going to blow of your kneecaps of fairly spectacularly (this goes double when you need to initialize memory management, which can't rely on a memory allocator being present or free memory being available)
  - pjmlp 7y ago
    Yet it has been achieved multiple times. The only thing missing is having companies like Apple and Google are doing with their mobile OSes, "my way or nothing". Usually those that have enjoyed GC aware OSes know what they were capable of, and those that never have, think they know how bad they were.
    - zaarn 7y ago
      There is a difference between "can be done" and "can be done well enough to be market ready".
      - pjmlp 7y ago
        Politics and money.
atilaneves 7y ago
These situations exist and in those, something like Rust is a very good idea. I maintain that these situations are far rarer than most people imagine (and I've had to deal with more than a few).

dgb23 7y ago

I agree. Memory safety is a problem solved 60 years ago and adopted by most mainstream languages, or rather most languages period. Rust doesn't solve memory safety, it just lets you do it in a more performant way. But the compiler does quite a bit more than just allow for performant memory safety. It enforces rules around mutability and handling errors which are usually only seen in functional languages. None of these things are special about Rust. The special thing is that Rust can do these things with less computer resources while asking more of the programmer. And this is a general truth. Type systems add friction and force programmers to deal with details from the very beginning. In the long term this might often be a good thing, but it certainly isn't ergonomic.

carlmr 7y ago
>Type systems add friction and force programmers to deal with details from the very beginning. In the long term this might often be a good thing, but it certainly isn't ergonomic. In Rust, I agree, but I find coding in C#/F# which are decently typed, but with GC, is much faster for me than using e.g. Python. Typescript is much easier than Javascript. Lack of types usually leads to worse auto completion, errors maybe only found on some edge cases which I didn't try and a huge slow down if I need to add a feature when I've forgotten about the code, since they provide a lot of documentation where you know that it's not stale. I wouldn't use python at all if it didn't have pandas.
- shpongled 7y ago
  Totally agree. If I'm writing anything nontrivial then it's going to be in a statically and explicitly typed language. There can be some friction, but the additional tools and speed in refactoring make up for it, IMO. At this point I only use python for pandas and matplotlib, or for sending small psuedocode snippets to coworkers
- dgb23 7y ago
  Auto-completion for some dynamic languages has gotten much better with the right tools/editors/plugins. I get where you are coming from but I would argue that there is a bit of a perception issue here. You can surely write fast in typed languages but you also have to write more and think more. But I fully agree with the benefits. Errors, changing/refactoring and documentation. I wonder if we can have the best of both worlds some day. Prototype dynamically and then add types and abstraction progressively in the same language and code base. In theory this is doable with Lisps, but only in a self-imposed, possibly unstructured way.

tus88 7y ago

What is 2% of the Rust code is in unsafe blocks so you do something useful?

timw4mail 7y ago
Rust unsafe blocks are generally a few different things: * Calls to C functions (which can't be checked for safety) * Cycles or mutable access which can't be checked for safety by the compiler * Performance-sensitive code, which ignores bounds checking (again, which can't be checked for safety by the compiler) The point of `unsafe` is to fence in the memory danger into the smallest possible points.

sacado2 7y ago

This is not memory-safety per se, but Rust goes further, though. You can't have 2 objects that can modify the same object at the same time, for instance, as in: l1 = [1, 2, 3]; l2 = l1; l2.push(0); // Oops, I also modified l1, was it expected?

deleted 7y ago
[deleted]
atilaneves 7y ago
This depends on the language. The one with GC I know best, D, would reallocate l2 when pushing to it so l1 wouldn't be modified.