Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig's Incremental Compilation Internals

mlugg.co.uk

Post reply on HN
Print view View original

151–160 of 292 posts

Re: Zig's Incremental Compilation Internals

#151

Post by upboatsy »

chaz72 wrote: post #65
brabel wrote: post #57

Earlier quoted context omitted.

I’ve been watching this debate online and in my opinion both sides are guilty. Fil is intentionally trying to be funny or at least “interesting “ when he makes his points and I, for one, enjoy his humor, which includes having a go at Rust and other languages. It seems Rust people just can’t take a little criticism, even when it comes from a clearly trolling language! Yes it’s true Rust has an escape hatch, and we’ve…

Yes! I think Fil is great so far but I think as he gets a bigger audience he should, well, consider that and focus on clarity a little more than humor. You can see Andrew’s growth in that respect. Rust folks, this whole thing is a thread about Zig’s new feature - not even a memory safety-related feature! - and we cannot spend the whole damn time talking about Rust. Steve, even you - I don’t believe I have ever seen y…

[flagged]

Re: Zig's Incremental Compilation Internals

#154

Post by uecker »

dwattttt wrote: post #109
uecker wrote: post #101

Earlier quoted context omitted.

> C (where the safe subset is effectively empty), Well, Fil-C and also Cheri show that C is a language that can be implemented with perfect memory safety for 99.9% of the language. This is not true for every language but is also not an accident in C. But also with the typical implementations of C such as clang and gcc you can essentially get spatial memory easily by using safe abstractions.

Very explicitly making a silly point; a rock is 100% memory safe. The serious point: I care about whether the program I write aborts regularly, whether due to a Rust panic or a capability violation.

Regarding the silly point: Fil-C is less of a rock than Safe Rust as everything in C just works.

I am not sure about what you mean by "aborts regularly". After a memory safety issue, I think one usually wants to abort quickly and not do anything else in the program as the program state is confused, so running specific sanitizers in trapping mode together with coding abstractions that avoid unchecked raw pointer access you can write spatially memory safe code in C without a problem. But yes, sometimes you may want to continue running, but this is much harder and needs a careful design of the system anyway, also in other languages.

Re: Zig's Incremental Compilation Internals

#155

Post by grottoov »

archargelod wrote: post #139
josephg wrote: post #137

Earlier quoted context omitted.

My main problem with Fil-C is that it combines the worst parts of C with the worst parts of a GC language. In a language like C (or Zig), you need to manually manage memory. This makes programming a lot more complex, and it's really easy to accidentally mess up. Especially in large projects which have a lot of separate modules. The biggest advantage of using a garbage collector is that you don't have to think about f…

> 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…

[flagged]

Re: Zig's Incremental Compilation Internals

#157

Post by afdbcreid »

norman784 wrote: post #37
jamiejquinn wrote: post #14

Earlier quoted context omitted.

That's interesting. Coming from C++ and Zig, the massive time "wasters" are metaprogramming features, i.e. Templates and comptime. Are Rust's macros the compile-time culprits?

The issue with Rust proc macros is that they are impure, so even with incremental compilation, you need to expand them every time.

That's only part of the issue. First, declarative macros are of course pure. Most procedural macros are pure too, although there are exceptions (an infamous case is sqlx). And while rustc does expand them every time (although a config for declaring "my macro is pure" was considered multiple times and the teams generally view it favorably), rust-analyzer just declares "we don't support impure macros" and caches them anyway.

Re: Zig's Incremental Compilation Internals

#158

Post by SkiFire13 »

nh2 wrote: post #11
steveklabnik wrote: post #7

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…

> Haskell GHC's model of incrementality, which is currently file-level

From what I see in Haskell files are the unit of compilation, and that's what allows incremental compilation to be file based (because it's really unit-of-compilation based)

I can see you can have circular dependencies between files with the `{-# SOURCE #-}` pragma, but I don't see documentation about how that affects incremental compilation.

A couple of issues I see with doing this in Rust are:

- in Rust the unit of compilaion is a crate, which can contain many fils/modules with circular imports, which is much more coarser than what can be done in Haskell.

- in Rust downstream crates can depend on function bodies upstream for running compile time functions; as such the crate/module interface is not enough to gate recompilation, but at the same time including all function bodies will also not give the wanted benefits. This is solvable but likely requires more work than what was done in Haskell.

In general you cannot take a language approach and blanket applying it to another one without considering their different quirks, which is likely why your proposal didn't get much attention. Or am I missing something that would make it easier to apply Haskell approach here?

Re: Zig's Incremental Compilation Internals

#159

Post by SkiFire13 »

xenadu02 wrote: post #127
steveklabnik wrote: post #17

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…

The traditional model of compilation is the biggest issue holding back fast incremental compilation IMHO. Swift suffers from this as well. Even a simple change to one file results in re-parsing the whole library because definitions come from anywhere and we have to obey the 1970s single file compilation model. The result is a driver spawns 8 threads and each one wastes time re-parsing every file in the library lookin…

> To me compilers should be content-addressed databases

Rustc already does something like this. The issues are:

- when you have to rehash everything to check that they indeed didn't change from the previous compilation. For big projects this takes _a lot_ of time.

- when small changes do indeed change the hash of a lot of seemingly unrelated code, which is more common than you might think.

Re: Zig's Incremental Compilation Internals

#160

Post by KingMob »

grottoov wrote: post #155
archargelod wrote: post #139

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…

[flagged]

complains about vote manipulation

user created an hour ago

Post reply on HN