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…
Zig's Incremental Compilation Internals
161–170 of 292 posts
Re: Zig's Incremental Compilation Internals
#162Earlier 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.
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
#163Zig'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…
> 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
#164[flagged]
Re: Zig's Incremental Compilation Internals
#165[flagged]
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
#166Re: Zig's Incremental Compilation Internals
#167Earlier 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.
Re: Zig's Incremental Compilation Internals
#168Re: Zig's Incremental Compilation Internals
#169Re: Zig's Incremental Compilation Internals
#170[flagged]