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

131–140 of 292 posts

Re: Zig's Incremental Compilation Internals

#131

Post by josephg »

ethin wrote: post #105
slopinthebag wrote: post #69

Earlier quoted context omitted.

> It seems Rust people just can’t take a little criticism, even when it comes from a clearly trolling language I think this is a case of people who can dish it out but can't take it. As far as I'm concerned if you troll someone you should expect to get trolled back.

Might get downvoted but was thinking this exact thing when reading this debate. Rustations have this very bad habit (IMO) of pushing the "my language is better than yours" to an extreme that I haven't seen elsewhere (but I don't frequent a huge number of language circles so...). Yet when it is done to them they get all upset about it.

> Rustations have this very bad habit (IMO) of pushing the "my language is better than yours" to an extreme

It’s funny, I’ve heard people claim this about rust developers for years. But I’ve seen very little evidence of it. Where are all these toxic comments? Look at Klabnik’s comments in this thread. He’s lovely.

—-

A son comes home to his poverty stricken family with a spring in his step. “Mum! Dad! All that time at community college paid off! I got a job!”. Dad immediately snaps - “so what, now you have a job, you think you’re better than us?”

What happened? Dad is unconsciously projecting a belief onto his son. Something like “unemployed people are shameful”. Then dad feels judged by the projected belief and he attacks the son for it. But it wasn’t the son’s belief in the first place. He just wanted his parents to be proud.

How does the son respond? It’s a tricky one. If the son defends himself by talking up how great it is to have a job, he reinforces the projection and dad will get more angry. If he says “there’s nothing to be proud of for having a job” then he’s lying about his values. It’s a trap.

When I’m feeling uncharitable, I project this same dynamic onto rust and C/C++ devs. “Mom! Dad! I figured out a way to get memory safety without sacrificing native execution and performance!” C: “So you think your language is better than ours? Why are you so toxic about it?”

I’m not really sure how to respond to comments like yours. I think you’re mad at ghosts.

Re: Zig's Incremental Compilation Internals

#132

Post by steveklabnik »

dminik wrote: post #128
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…

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.

I mean, the core thing is like, you have to have a compiler codebase (and language semantics) that's designed around being able to delay in the first place to be able to even try this, and once you've gotten that in place, well, it's not really about this specific idea anymore.

Re: Zig's Incremental Compilation Internals

#134

Post by jibal »

pron wrote: post #47
steveklabnik wrote: post #44

Earlier quoted context omitted.

Okay so: in general, as a rule of thumb: anything that makes stuff have more memory safety is good. And experiments towards that end are also good. What I do not like, primarily comes down to how the project is talked about and marketed. First, because it promotes an "us vs them" mindset, instead of a "we're all trying to improve memory safety" mindset, and second, because in doing so, it also overstates its case. Th…

> it promotes an "us vs them" mindset, instead of a "we're all trying to improve memory safety" mindset But you did the same thing when, on the spectrum that ranges from C to ATS, with Zig, Rust, and Java somewhere in the middle (though all closer to C than to ATS), you declared the exact compromise that Rust makes "table stakes"! [1] Zig improves on C's memory safety when it comes to spatial safety, possibly the mor…

> But you did the same thing

So your defense is a tu quoque fallacy? Note that "the same thing" is an admission.

Re: Zig's Incremental Compilation Internals

#135

Post by panstromek »

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.

There's a language called Unison that does that - and the "content" is the AST, so all functions that have the same shape are the same function. It's pretty interesting.

Re: Zig's Incremental Compilation Internals

#136

Post by panstromek »

dminik wrote: post #128
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…

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.

Yes, and there is some compiler flag to do this, even though it's not 100% intended for this use (I think it's something like mir-inline-trheshold=0).

There's also -Zhint-mostly-unused flag.

The tradeoff is that these functions then have to be encoded in metadata for downstream crates, so it's not necessarily faster.

Re: Zig's Incremental Compilation Internals

#137

Post by josephg »

mi_lk wrote: post #29
steveklabnik wrote: post #21

Earlier quoted context omitted.

I'll say the same thing I said to you as I said to Andrew, last time he and I talked about this: the way that everyone talks about memory safety (with maybe two exceptions, one okay (go) and one I dislike (fil-c)) is that "memory safe language" is about there being a clear delineation between what is memory safe and what is not, and that the unsafe aspect is a superset. Rust and Java both are memory safe, except wher…

Would you mind sharing some thoughts about fil-c? AFAICT its claims mostly check out so besides implementation details (GC?) it seems directionally good.

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 freeing memory. The GC automatically frees objects when they're no longer referenced. This makes programming much much easier. The downside of using a garbage collector is that it hurts performance at runtime. GC languages are slower and use more RAM.

Fil-C is the worst of all worlds here. Like C, it forces you to manually manage your own memory. But you still pay the performance cost of having a runtime garbage collector. And that cost is (apparently) really high. The only performance numbers I've seen showed ~2x worse CPU performance and ~4x worse memory performance. There's no way Fil-C can compete with C, Zig and Rust for performance.

So with Fil-C, you have a language that's much slower than C, and much more difficult to program in than C#, Java, Go or Typescript.

Fil-C still has some wonderful uses. Fil-C could be a fabulous debugging tool for C programs. It could be a wonderful teaching tool if it had nice visualisations on top of the GC's view of the world. And it could be a great way to run legacy C code.

But it's not a "rust killer". Fil-C programs run too slowly to be able to compete head to head with rust. And Fil-C doesn't offer the language benefits of a GC that you get in C#, Go, and friends. It seems like a really bad deal.

Re: Zig's Incremental Compilation Internals

#138

Post by lsuresh »

afdbcreid wrote: post #117

This post is really interesting. As a member of the rust-analyzer team, I cannot avoid comparing it to the situation in Rust land. Rust famously has not less (or even more) sophisticated system for incremental compilation, yet its compilation is way slower. I attribute that to two main things: - Language design. Zig was designed for fast and incremental compilation, Rust is just not. For instance, the post states tha…

Isn't most of Rust's compilation overhead from the llvm backend?

Re: Zig's Incremental Compilation Internals

#139

Post by archargelod »

josephg wrote: post #137
mi_lk wrote: post #29

Earlier quoted context omitted.

Would you mind sharing some thoughts about fil-c? AFAICT its claims mostly check out so besides implementation details (GC?) it seems directionally good.

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 destructors.

Another scarecrow of safe languages is GC pauses, which is also not a thing in Nim, see table in [2].

[0] - https://nim-lang.org/

[1] - https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

[2] - https://nim-lang.github.io/Nim/mm.html

Re: Zig's Incremental Compilation Internals

#140

Post by seanmcdirmid »

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…

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.
Post reply on HN