Note that this is still very much a WIP :) I guess I should also mention my inspiration, the C++ dyno library (https://github.com/ldionne/dyno) I don't really see how this is relevant to typeclasses though ^^
fwiw, the defers apply to scopes in Zig (similar to D's scope(exit) and scope(failure)) and thus are always static, not dynamic like Go's.
Not quite, the linkers (at least ELF and PE which I am familiar with) will "free" parts of the file (when a block needs to be reallocated because the decl code gets too big, or when a decl is removed) and reuse them…
No, some parts of the binary file will be unused in the final executable if you keep updating it incrementally. The linkers will do what they can to reuse all previously freed blocks of the file, but you can imagine a…
This is just not true, the master build is literally the first thing you see on the download page. Don't get me wrong, it should be clarified on the ziglearn website anyway.
> Rust's generics are complex and incur significant compilation overhead but they're also incredibly powerful. Zig doesn't have generics in the strictest sense of the word. What it provides is compile time execution and…
While I am not terribly familiar with the LLVM codebase, this kind of improvement would probably require massive internal changes. One example of this is the fact that codegen needs to be aware of the linker to emit…
Hi, I don't necessarily disagree with you, however master builds are available for download for tier 1 targets on zig's website. The ziglearn website explicitly points to the website for this reason, although I agree it…
Supporting some kind of semantic server that will provide type information and information about comptime computations is one of the goals of the self hosted compiler. Currently no work has been done on this as the…
Yes, the compiler will open the binary and only emit modified/new code and possibly change some values in a global offset table. As noted in the article, the same strategy will be used for hot code swapping, which is…
Note that this is still very much a WIP :) I guess I should also mention my inspiration, the C++ dyno library (https://github.com/ldionne/dyno) I don't really see how this is relevant to typeclasses though ^^
fwiw, the defers apply to scopes in Zig (similar to D's scope(exit) and scope(failure)) and thus are always static, not dynamic like Go's.
Not quite, the linkers (at least ELF and PE which I am familiar with) will "free" parts of the file (when a block needs to be reallocated because the decl code gets too big, or when a decl is removed) and reuse them…
No, some parts of the binary file will be unused in the final executable if you keep updating it incrementally. The linkers will do what they can to reuse all previously freed blocks of the file, but you can imagine a…
This is just not true, the master build is literally the first thing you see on the download page. Don't get me wrong, it should be clarified on the ziglearn website anyway.
> Rust's generics are complex and incur significant compilation overhead but they're also incredibly powerful. Zig doesn't have generics in the strictest sense of the word. What it provides is compile time execution and…
While I am not terribly familiar with the LLVM codebase, this kind of improvement would probably require massive internal changes. One example of this is the fact that codegen needs to be aware of the linker to emit…
Hi, I don't necessarily disagree with you, however master builds are available for download for tier 1 targets on zig's website. The ziglearn website explicitly points to the website for this reason, although I agree it…
Supporting some kind of semantic server that will provide type information and information about comptime computations is one of the goals of the self hosted compiler. Currently no work has been done on this as the…
Yes, the compiler will open the binary and only emit modified/new code and possibly change some values in a global offset table. As noted in the article, the same strategy will be used for hot code swapping, which is…