4 ms·

> I suppose you could work around that by adding lifetime annotations in zig comments. you can make a no-op function that gets compiled out but survives AIR

> I suppose you could work around that by adding lifetime annotations in zig comments. you can make a no-op function that gets compiled out but survives AIR > rust knows when it can Drop. and its possible to cause problems if you aren't aware where rust picks to dropp. > And rust can put noalias everywhere in emitted code. zig has noalias and it should be posssible to do alias tracking as a refinement. > But if you want static memory safety in a low level systems language, its probably much easier to just use rust. don't use that attitude to suck oxygen out of the air. rust comes with its own baggage, so "just using rust because its the only choice" keeps you in a local minimum.

josephg 5mo ago
> and its possible to cause problems if you aren't aware where rust picks to drop. Can you give some examples? I've never ran into problems due to this. > don't use that attitude to suck oxygen out of the air. rust comes with its own baggage Yeah, that's a totally fair argument. One nice aspect of the approach you're proposing is it'd give you the opportunity to explore more of the borrow checker design space. I'm convinced there's a giant forest of different ways we could do compile time memory safety. Rust has gone down one particular road in that forest. But there's probably loads of other options that nobody has tried yet. Some of them will probably be better than rust - but nobody has thought them through yet. I wish you luck in your project! If you land somewhere interesting, I hope you write it up.
- dnautics 5mo ago
  > Can you give some examples? I've never ran into problems due to this. If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. thank you. Unfortunately in the last few weeks i've been too busy with my startup to put as much work into it. We'll see =D
  - josephg 5mo ago
    > If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. Yeah, I've heard of people being surprised that when they make massive collections of Box'ed entries, then get surprised that it takes a long time to Drop the whole thing. But this would be the same in C or Zig too. Malloc and free are really complex functions. Reducing heap allocations is an essential tool for optimisation. The solution to this "unexpected performance regression" in rust is the same as it is in C, C++ and Zig: Stop heap allocating so much. Use primitive types, SSO types (SmartString and friends in rust) or memory arenas. Drop isn't the problem.
    - brabel 5mo ago
      In zig the solution is to use an arena allocator. That’s about as easy as it gets. Maybe Rust also allows doing that, I don’t know.
      - staticassertion 5mo ago
        You can use arenas in Rust, it's just not as trivial to swap allocators generally. But there are plenty of crates for it.
    - dnautics 5mo ago
      no, in zig it's never unexpected, because if you're freeing memory the freesite is known, it's a function call.
      - josephg 5mo ago
        Right; because in zig the default behaviour is to leak memory. Rust adds an invisible free() call. Leaking is something you have to do explicitly. I understand zig's philosophy here. But I prefer rust's default behaviour.
        dnautics 5mo ago
        yeah, IMO generally explicit is better. It's hard to take something implicit and increase the visibility (I'm aware there are tools to show you lifetimes in rust). But another option is to statically analyze the code (or the IR) and have something else check that you aren't leaking.

josephg 5mo ago

> and its possible to cause problems if you aren't aware where rust picks to drop. Can you give some examples? I've never ran into problems due to this. > don't use that attitude to suck oxygen out of the air. rust comes with its own baggage Yeah, that's a totally fair argument. One nice aspect of the approach you're proposing is it'd give you the opportunity to explore more of the borrow checker design space. I'm convinced there's a giant forest of different ways we could do compile time memory safety. Rust has gone down one particular road in that forest. But there's probably loads of other options that nobody has tried yet. Some of them will probably be better than rust - but nobody has thought them through yet. I wish you luck in your project! If you land somewhere interesting, I hope you write it up.

dnautics 5mo ago
> Can you give some examples? I've never ran into problems due to this. If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. thank you. Unfortunately in the last few weeks i've been too busy with my startup to put as much work into it. We'll see =D
- josephg 5mo ago
  > If it's doing a drop in the hot loop that may be an unexpected performance regression that could be carefully lifted. Yeah, I've heard of people being surprised that when they make massive collections of Box'ed entries, then get surprised that it takes a long time to Drop the whole thing. But this would be the same in C or Zig too. Malloc and free are really complex functions. Reducing heap allocations is an essential tool for optimisation. The solution to this "unexpected performance regression" in rust is the same as it is in C, C++ and Zig: Stop heap allocating so much. Use primitive types, SSO types (SmartString and friends in rust) or memory arenas. Drop isn't the problem.
  - brabel 5mo ago
    In zig the solution is to use an arena allocator. That’s about as easy as it gets. Maybe Rust also allows doing that, I don’t know.
    - staticassertion 5mo ago
      You can use arenas in Rust, it's just not as trivial to swap allocators generally. But there are plenty of crates for it.
  - dnautics 5mo ago
    no, in zig it's never unexpected, because if you're freeing memory the freesite is known, it's a function call.
    - josephg 5mo ago
      Right; because in zig the default behaviour is to leak memory. Rust adds an invisible free() call. Leaking is something you have to do explicitly. I understand zig's philosophy here. But I prefer rust's default behaviour.
      - dnautics 5mo ago
        yeah, IMO generally explicit is better. It's hard to take something implicit and increase the visibility (I'm aware there are tools to show you lifetimes in rust). But another option is to statically analyze the code (or the IR) and have something else check that you aren't leaking.