3 ms·

> Your systems programming language should be capable of interop with other languages but probably shouldn't require calling into C just to provide full functio

> Your systems programming language should be capable of interop with other languages but probably shouldn't require calling into C just to provide full functionality, such as interacting with the kernel. Why tho? Like, that's how C and C++ do it, right? > All you can do is live with it and realize that if you are that low on memory, the OS is likely going to be killing processes anyway. That said, I don't like the way Rust is inconsistent here. Rust normally enforces correctness, yet turns around and treats memory as an inexhaustible resource, ignoring or handicapping a lot of potential use cases for the language. I think it would be more accurate to say that this is an issue of the standard library, not the language. And it's true, if you want to write certain types of software you need to throw away std. > You can, at least in this particular case, have your cake and eat it, too. Emphasis on "in this particular case" ? "Macros are a mistake" is a very broad, sweeping statement. I think it would be more accurate to say "Macros should not be a replacement for other forms of metaprogramming". Having a native, supported language for compile time reflection is a powerful thing. If Rust one day gets it, that will be cool. I don't think macros are going to be a mistake on that day, they have gotten us extremely far at a very low implementation cost.] > But at this point I just don't see anyone realistically switching to a std-2.0. Well, to be fair, I think the vast majority of developers using Rust do not care about linking to libc or handling allocation errors and actually prefer things this way. I agree that comptime would be cool. Personally, I don't think I'd want the other changes - I definitely prefer Rust stays on Github, for example.

Strom 3y ago
> Well, to be fair, I think the vast majority of developers using Rust do not care about linking to libc or handling allocation errors and actually prefer things this way. I’d say it’s about the deceptive marketing. Rust is talked about as a safe systems language. I don’t think I’ve ever seen it followed by a disclaimer that this only applies to systems with unlimited memory. It doesn’t of course stop at the marketing slogan. Problems like these aren’t sufficiently promoted in the documentation either. I think that being more open about these problems would help enable a solution.
- Ygg2 3y ago
  > I don’t think I’ve ever seen it followed by a disclaimer that this only applies to systems with unlimited memory. So, a Turing machine? Why Rust doesn't prevent memory leaks - answer is simple. It's too much pain for modicum of gain. People crow about lifetime being hard, now imagine how much people would complain if you add another orthogonal system to track memory allocation.
  - tialaramex 3y ago
    You couldn't meaningfully "prevent memory leaks", and that's what Rust's Leakpocalypse was about. Suppose I have decided to model marriage. My Person type has a spouse: Option<Rc<Person>> and when you marry() another Person it fills out both spouse references. Now I make Bob and Alice, and marry them off, so Alice contains a reference to Bob, while Bob has a reference to Alice. Romantic. Next, I throw away my only Alice reference, but that's OK, I have a Bob, and Bob has a spouse field with a reference to Alice, so Alice isn't destroyed. Then I throw away Bob, likewise Alice has a reference to Bob, so Bob isn't destroyed either. I have now leaked two Persons. I have no way to get them back but they exist forever (well, until program termination).
- dralley 3y ago
  Rust is a "memory safe" systems programming language. That has a specific meaning which does not include the method of allocation failure handling. I would bet money that the majority of C code doesn't check the return code from malloc. What Rust does is strictly better than that. For people that do care, the APIs for fallible allocation are being added over time.
  - tialaramex 3y ago
    > I would bet money that the majority of C code doesn't check the return code from malloc. There's a difference between "I was trying to load this 1 pixel = 1mm scale image of central Paris into memory but I don't have 1.3TB of RAM" and "Allocating 4kB of RAM to grow my Vec was impossible". In the latter case you are definitely screwed, and Rust's choice here is fine, any imagined recovery is a fantasy, somewhere something else will also need some RAM and it'll blow up and everything is on fire, aborting now was the right choice unless you're a space probe or something (in which case you should have not been written to go around dynamically allocating memory all over the place) In the former case it'd be nice to notice OK, that's unreasonable, I don't have that kind of RAM so we shouldn't attempt this. But, wait, is it OK to allocate say, all remaining RAM except 16kB? That wouldn't strictly fail but it sounds like a bad idea too. So maybe we actually want a configurable limit. It might be reasonable to say for example, we're an image loader, we will by default allow up to 50% of our RAM to be image data, in the same way that many thread pools assume it's OK to have about N threads if you have N CPU cores by default.

Strom 3y ago

> Well, to be fair, I think the vast majority of developers using Rust do not care about linking to libc or handling allocation errors and actually prefer things this way. I’d say it’s about the deceptive marketing. Rust is talked about as a safe systems language. I don’t think I’ve ever seen it followed by a disclaimer that this only applies to systems with unlimited memory. It doesn’t of course stop at the marketing slogan. Problems like these aren’t sufficiently promoted in the documentation either. I think that being more open about these problems would help enable a solution.

Ygg2 3y ago
> I don’t think I’ve ever seen it followed by a disclaimer that this only applies to systems with unlimited memory. So, a Turing machine? Why Rust doesn't prevent memory leaks - answer is simple. It's too much pain for modicum of gain. People crow about lifetime being hard, now imagine how much people would complain if you add another orthogonal system to track memory allocation.
- tialaramex 3y ago
  You couldn't meaningfully "prevent memory leaks", and that's what Rust's Leakpocalypse was about. Suppose I have decided to model marriage. My Person type has a spouse: Option<Rc<Person>> and when you marry() another Person it fills out both spouse references. Now I make Bob and Alice, and marry them off, so Alice contains a reference to Bob, while Bob has a reference to Alice. Romantic. Next, I throw away my only Alice reference, but that's OK, I have a Bob, and Bob has a spouse field with a reference to Alice, so Alice isn't destroyed. Then I throw away Bob, likewise Alice has a reference to Bob, so Bob isn't destroyed either. I have now leaked two Persons. I have no way to get them back but they exist forever (well, until program termination).
dralley 3y ago
Rust is a "memory safe" systems programming language. That has a specific meaning which does not include the method of allocation failure handling. I would bet money that the majority of C code doesn't check the return code from malloc. What Rust does is strictly better than that. For people that do care, the APIs for fallible allocation are being added over time.
- tialaramex 3y ago
  > I would bet money that the majority of C code doesn't check the return code from malloc. There's a difference between "I was trying to load this 1 pixel = 1mm scale image of central Paris into memory but I don't have 1.3TB of RAM" and "Allocating 4kB of RAM to grow my Vec was impossible". In the latter case you are definitely screwed, and Rust's choice here is fine, any imagined recovery is a fantasy, somewhere something else will also need some RAM and it'll blow up and everything is on fire, aborting now was the right choice unless you're a space probe or something (in which case you should have not been written to go around dynamically allocating memory all over the place) In the former case it'd be nice to notice OK, that's unreasonable, I don't have that kind of RAM so we shouldn't attempt this. But, wait, is it OK to allocate say, all remaining RAM except 16kB? That wouldn't strictly fail but it sounds like a bad idea too. So maybe we actually want a configurable limit. It might be reasonable to say for example, we're an image loader, we will by default allow up to 50% of our RAM to be image data, in the same way that many thread pools assume it's OK to have about N threads if you have N CPU cores by default.