alexnask

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 when they can.

But in general, the final executable will not be the same, this is correct.

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 scenario where a function is updated but does not fit in the block that was previously allocated for it. In this case, a new block of the file will be allocated for this function.

If you then add a smaller function, it will occupy some portion of the old block. You can keep adding things into this block until some minimum amount of memory is reached (and as long as the declarations fit in there, obviously).

Repeating this process for all new declarations and for all the modifications of declarations, you can imagine some parts of the files will remain unused.

I hope this makes sense :)

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 types as first class values at compile time.

You can write arbitrary compile time code that generates any type you wish, either with the traditional syntax or by using the @Type builtin (for example if you wish to generate a struct with fields that are defined by parsing some protobuf code, or w/e your heart desires, it is easily achievable).

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 correct code depending on the type of executable that is being generated, since different strategies can and are used for different formats (for example, currently the x86_64 backend will generate different instructions for function calls on ELF and PE/COFF vs MachO).

I would totally get behind LLVM or other compiler toolchains working towards this kind of functionality, but this is hardly something Zig developers could implement in a massive project such as LLVM (which is precisely why we are building our own :))

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 should probably include some warning about using the latest tagged release and how some of the tests will break.

The fact that debug.warn was renamed to debug.print during this release cycle makes this extra unfortunate, since it affects the hello world program.

Anyway, thanks for pointing this out, I will make sure to PR ziglearn to clarify this.

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 focus is on the incremental linkers and codegen but I personally think we should be able to make a pretty solid tool that will not only provide langserv capabilities but also allow us to inspect and debug metaprograms with ease :)

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 one of the benefits of doing this.

This is indeed faster than generating new object files and relinking the whole executable. The video linked in the article shows a simple example with the current ELF incremental linker, where compiling the example program takes 1.5 ms while changing a string literal and updating the executable takes about 0.5 ms