Zig self hosted compiler is now capable of building itself

Post by reitzensteinm » Sun, Apr 17, 2022, 1:08 AM UTC

PaulDavisThe1st wrote: post #196

AndyKelley wrote: post #21

Earlier quoted context omitted.

Thanks :) The new Zig implementation is certainly more well designed than the C++ implementation, for several reasons: * It's the second implementation of the language * It did not have to survive as much evolution and language churn * I leveled up as a programmer over the last 7 years * The Zig language safety and debugging features make it possible to do things I would never dream of attempting in C++ for fear of f…

> * a Digital Audio Workstation ORLY? Maybe you can put together a better, faster team (like Presonus managed to do for Studio One), but most current DAWs have been in existence for 20 years or more. Catching up with that is a challenge, and if you don't catch up then it's an interesting toy or half-a-DAW. So why? ps. obviously I am biased.

Post by _3u10 » Sun, Apr 17, 2022, 1:53 AM UTC

varajelle wrote: post #115

coder543 wrote: post #50

Earlier quoted context omitted.

> because automatic deallocations lead to hard-to-predict lifetimes (excess memory usage, and bugs for resource handles that are destructed at hard to predict moments). I don't really feel this is the case in Rust.

But it is. If you have a String on the stack, it's memory is only reclaimed at the end of the scope, while it often could be free'd before. This is especially bad in async code around await point since it means the memory need to be kept alive more than needed.

Post by charcircuit » Sun, Apr 17, 2022, 2:07 AM UTC

RustyConsul wrote: post #111

charcircuit wrote: post #52

Earlier quoted context omitted.

The lifetime of the memory a smart pointer manages is very predictable. It will have the same lifetime as the smart pointer itself (this is ignoring moves).

I think what he's saying is there is a way to carelessly use smart pointers in rust. pub enum List { Empty, Elem(i32, Box ), } instead of : pub struct List { head: Link, } enum Link { Empty, Some(Box ), } struct Node { elem: i32, next: Link, }

Post by varajelle » Sun, Apr 17, 2022, 2:26 AM UTC

_3u10 wrote: post #204

varajelle wrote: post #115

Earlier quoted context omitted.

But it is. If you have a String on the stack, it's memory is only reclaimed at the end of the scope, while it often could be free'd before. This is especially bad in async code around await point since it means the memory need to be kept alive more than needed.

Stacks are a fixed size. Unless you are running out of stack space there is no point in “freeing” memory from the stack. Where in the stack the stack pointer points has no bearing on stack size for any OS I’m aware of. I’m assuming by string you mean a stack allocated array of char and not a std::string.

Post by varajelle » Sun, Apr 17, 2022, 2:42 AM UTC

______-_-______ wrote: post #201

coder543 wrote: post #152

Earlier quoted context omitted.

I definitely wish that Non-Lexical Lifetimes would eagerly drop anything that doesn't implement Drop. It would probably be a breaking change to automatically call an explicit Drop implementation anywhere other than the end of the current scope, so I think that would have to be left as-is. String doesn't implement Drop, so it could easily be dropped eagerly within the scope as soon as it won't be referenced again. Suc…

100%. I would actually go further and say every value should be dropped immediately after its last use, including temporaries in the middle of statements, whether or not it implements Drop. Reuse the same rules that NLL uses. Breaking change yes, so do it next edition. It would lower memory usage in general and solve so many little pain points, not least of which is holding strings across await points.

    fn foo(xx : &Mutex) {
        let lock = xx.lock();
        let ptr = &mut *lock as *mut String;
        unsafe { use_from_c(ptr) }
    }