Live data from Hacker News

Zig's Incremental Compilation Internals

mlugg.co.uk

161–170 of 292 posts

Re: Zig's Incremental Compilation Internals

#161
post #145

Earlier quoted context omitted.

Everything it's doing it clear and readable. It's just not as easy to write. It streams the bytes to stdout using the default IO interface, and it can fail. Alternatively, here's a simpler version (prints to stderr). const std = @import("std"); pub fn main() void { std.debug.print("Hello, world!\n", .{}); } In practice, you normally don't want to print messages to stdout. So the increased friction here actually pushe…

the given complicated version's complexity actually just comes from the fact that it's a "more correct" way to write a hello world program, as it manually acquires the stdout File object and acknowledges that printing to stdout can fail. the complexity has nothing to do with stdout vs stderr, you could just use `.stderr()` instead of `.stdout()` (same "friction", it's even the same number of characters). `std.debug.p…

I meant that the convenient interface only works for stderr. So you aren't accidentally sending debug messages to stdout and if you want to send bytes to stdout you have to do so intentionally and use the right interface.

Re: Zig's Incremental Compilation Internals

#162
post #128

Earlier quoted context omitted.

Macros can be, but in part because they can produce new items (top level declarations, to sort of make the same handwave as the article does) and so that means you have to do macro expansion and stuff before you can even start to check some things, and similar issues. See the link I posted above for some details on a related issue. There's also stuff around name resolution. Proc macros are just an inherently very slo…

A really dumb 1 AM question. If there is a lot of work thrown away because stuff is compiled even if not needed, would making every function generic and delaying compilation until instantiation help here? Note that it's not a serious suggestion, but I wonder what effect it would have on build times.

The downside of this is that if two crates use the same function each of them will have to codegen it, duplicating the work needed for those functions.

As always this could be avoided with some extra complexity, but that require lot of work and testing that hasn't been done.

So for now this is useful only in crates that have a lot of unused functions, so even if one function is codegenned multiple times you still save time overall.

Re: Zig's Incremental Compilation Internals

#163
post #11

Zig's toolchain work is continually impressive. While I still don't plan to write software in it, given that I believe memory safety is table stakes, all of this stuff is very, very good. Before the incremental work, it was the toolchain and cross-compiler work. The toolchain stuff has continually been fantastic. I'm very curious to see what they come up with next! > Semantic analysis is the most difficult part of th…

10 years ago, I commented on the Rust issue for "Incremental recompilation", where it was suggested that Rust could at least adopt Haskell GHC's model of incrementality, which is currently file-level: https://github.com/rust-lang/rust/issues/2369#issuecomment-1... This would already help a lot. I recommend anybody who's interested in incremental recompilation to read what GHC does, because the effort to achieve that…

> GHC currently needs to parse+typecheck+codegen a file before it can process other files that import it. Codegen is slow. Thus, there's currently demand split compilation into "stages", so that the next file can be typechecked after its imports have been just typechecked (not codegenned).

> I would also enjoy if recompilation avoidance were to happen at the function level, not the file level.

This sounds like Rust is already doing a lot more incremental then GHC then. Rustc only needs to parse, expand macros and do name resolution. Everything else is incremental after that, on a very granular level.

Re: Zig's Incremental Compilation Internals

#165

[flagged]

Neither of those links involves Klabnik.

And the second one (about swatting a linux dev) says "Others think someone from the Rust (programming language, not video game) development community was responsible due to how critical René has been of that project, but those claims are entirely unsubstantiated."

--

Also wild to complain about botting when I've seen half a dozen accounts that didn't exist an hour ago all pop up to criticize Klabnik.

Re: Zig's Incremental Compilation Internals

#167

Earlier quoted context omitted.

> GC languages are slower This is not necessarily true. It depends on a language, e.g. Go is slow, Nim[0] is extremely fast with conventional GC and slightly faster with ARC/ORC[1]. GC programs can be faster than manually managed ones in some cases. It's just manual memory management gives you more control of where and when free is called. And a good type system is a privelege that gives Nim more control with destruc…

You can always use things like arenas in C and get similar speed ups without GC overhead. If you know your memory lifetimes in advanced, avoiding granular malloc/free calls is pretty straightforward. A GC language doesn’t usually offer such options.

Sure it does, D just to give one example.
Post reply on HN