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

231–240 of 292 posts

Re: Zig's Incremental Compilation Internals

#231

Post by steveklabnik »

mbrock wrote: post #197
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…

There is an unsafe call primitive in stdfil that was used to support constant time crypto functions when Fil-C didn't have support for inline assembly. Fil-C now has support for inline assembly, so it's not needed anymore, and I believe indeed the intention is to remove it, since Fil-C is not supposed to have any unsafe hatches. Fil-C is not Linux only by design, that's completely false. By the way, if you don't want…

> Fil-C now has support for inline assembly, so it's not needed anymore, and I believe indeed the intention is to remove it, since Fil-C is not supposed to have any unsafe hatches.

See, this is nuance! Nuance is good! But you can't go around saying "fil-c has no escape hatches" when it has one, even if that one is planned on being removed.

> Fil-C is not Linux only by design, that's completely false.

Can you explain to me how it would work on other platforms? It currently does not, and I don't see how it can. Or at least, not without more "escape hatches."

Re: Zig's Incremental Compilation Internals

#232

Post by steveklabnik »

pizlonator wrote: post #212
steveklabnik wrote: post #55

Earlier quoted context omitted.

> But you did the same thing when, I do not go around posting "omg Rust is SO MUCH BETTER than zig or fil-c, which are TRASH." I talk about engineering tradeoffs, and what matters to me personally. I do not say "if you use Zig, you are a bad person." I am not saying that any comparison is bad. I am saying that the way that the comparison is presented is bad. That is different. > you declared the exact compromise that…

Steve, be reasonable. I never said Fil-C is “so much better” (let alone with all caps) than anything. I never called Rust “trash”. I think you’re taking this all too personally

I will let others be the judge by reading what you've written.

Re: Zig's Incremental Compilation Internals

#233

Post by steveklabnik »

mbrock wrote: post #196
steveklabnik wrote: post #55

Earlier quoted context omitted.

> But you did the same thing when, I do not go around posting "omg Rust is SO MUCH BETTER than zig or fil-c, which are TRASH." I talk about engineering tradeoffs, and what matters to me personally. I do not say "if you use Zig, you are a bad person." I am not saying that any comparison is bad. I am saying that the way that the comparison is presented is bad. That is different. > you declared the exact compromise that…

> I do not go around posting "omg Rust is SO MUCH BETTER than zig or fil-c, which are TRASH." I talk about engineering tradeoffs, and what matters to me personally. I do not say "if you use Zig, you are a bad person." I am not saying that any comparison is bad. I am saying that the way that the comparison is presented is bad. That is different. Oh, who is saying things like that? Do you mean to imply that this kind o…

Yes, this kind of rhetoric comes out of the project itself and its supporters, regularly.

Re: Zig's Incremental Compilation Internals

#234

Post by steveklabnik »

eaurouge wrote: post #175
steveklabnik wrote: post #55

Earlier quoted context omitted.

> But you did the same thing when, I do not go around posting "omg Rust is SO MUCH BETTER than zig or fil-c, which are TRASH." I talk about engineering tradeoffs, and what matters to me personally. I do not say "if you use Zig, you are a bad person." I am not saying that any comparison is bad. I am saying that the way that the comparison is presented is bad. That is different. > you declared the exact compromise that…

> I do not go around posting "omg Rust is SO MUCH BETTER than zig or fil-c, which are TRASH." > While I still don't plan to write software in it, given that I believe memory safety is table stakes What exactly am I missing? You know you don't have to hijack Zig threads (repeatedly) with your thoughts on memory safety, right?

> What exactly am I missing?

My point in bringing this up is to strengthen my compliment. Even though I disagree with aspects of Zig's design, the stuff talked about in this post is excellent.

Re: Zig's Incremental Compilation Internals

#235

Post by steveklabnik »

tancop wrote: post #191
steveklabnik wrote: post #132

Earlier quoted context omitted.

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.

Would this work better in a language where generics are vtable based by default and only monomorphized as a form of LTO? If you have a Zig style machine IR where function calls are a "fake instruction" you can decide between direct and virtual call at final codegen time. That would mean generics in shared libraries are possible without hacks but you can always choose to statically link and monomorphize for speed. Lib…

It really depends on a lot of things. This design is possible, yes, but it also means that you can't have some of the same features as Rust has. Rust's traits can be "non-dyn safe" (which used to be called "non-object safe"), because sometimes you cannot use them via a vtable, and must use them via monomorphization. So you can have languages that do things this way, but they make other tradeoffs (either performance ones or power ones, depending).

Re: Zig's Incremental Compilation Internals

#236

Post by steveklabnik »

afdbcreid wrote: post #173
simonask wrote: post #172

Earlier quoted context omitted.

Every analysis of the problem I've seen has concluded that the main problem is that rustc generates a lot of input to LLVM. Efforts to reduce compilation times are currently focused on doing more to the IR before converting it to LLVM IR. Rust as a language is even more reliant on monomorphization and inlining than C++, due to core language traits such as Deref, AsRef, From/Into, and so on. That said, in practice my…

See https://kobzol.github.io/rust/rustc/2024/03/15/rustc-what-ta... , which does an extensive analysis on that.

This analysis is great, and I don't mean to knock it, but one of the things that it doesn't capture is, what choices does the frontend make that impact the amount of work that the backend does. That is, some of the work attributed to the backend could be improved without touching the backend.

Re: Zig's Incremental Compilation Internals

#237

Post by mbrock »

steveklabnik wrote: post #233
mbrock wrote: post #196

Earlier quoted context omitted.

> I do not go around posting "omg Rust is SO MUCH BETTER than zig or fil-c, which are TRASH." I talk about engineering tradeoffs, and what matters to me personally. I do not say "if you use Zig, you are a bad person." I am not saying that any comparison is bad. I am saying that the way that the comparison is presented is bad. That is different. Oh, who is saying things like that? Do you mean to imply that this kind o…

Yes, this kind of rhetoric comes out of the project itself and its supporters, regularly.

Not really. I mean if you want to make that claim, use actual quotes.

Re: Zig's Incremental Compilation Internals

#238

Post by mbrock »

steveklabnik wrote: post #231
mbrock wrote: post #197

Earlier quoted context omitted.

There is an unsafe call primitive in stdfil that was used to support constant time crypto functions when Fil-C didn't have support for inline assembly. Fil-C now has support for inline assembly, so it's not needed anymore, and I believe indeed the intention is to remove it, since Fil-C is not supposed to have any unsafe hatches. Fil-C is not Linux only by design, that's completely false. By the way, if you don't want…

> Fil-C now has support for inline assembly, so it's not needed anymore, and I believe indeed the intention is to remove it, since Fil-C is not supposed to have any unsafe hatches. See, this is nuance! Nuance is good! But you can't go around saying "fil-c has no escape hatches" when it has one, even if that one is planned on being removed. > Fil-C is not Linux only by design, that's completely false. Can you explain…

It would work basically the way it works on Linux? What makes you think it's somehow fundamentally Linux-specific?

Re: Zig's Incremental Compilation Internals

#239

Post by mbrock »

steveklabnik wrote: post #230
mbrock wrote: post #200

Earlier quoted context omitted.

Fil-C's understanding of memory safety is not "its own" idiosyncratic made up definition. Memory safety in the whole tradition that includes CHERI etc is defined in terms of objects and allocations. In C structs and arrays are not object boundaries. So CHERI will have the same semantics as Fil-C in your struct example, unless you enable a compatibility-breaking mode, which Fil-C could very plausibly acquire too, at t…

C absolutely has struct, array, and subobject boundaries. The example is already undefined behavior in C.

In the ISO standard, yeah, but that's not how C actually works.

Re: Zig's Incremental Compilation Internals

#240

Post by steveklabnik »

mbrock wrote: post #238
steveklabnik wrote: post #231

Earlier quoted context omitted.

> Fil-C now has support for inline assembly, so it's not needed anymore, and I believe indeed the intention is to remove it, since Fil-C is not supposed to have any unsafe hatches. See, this is nuance! Nuance is good! But you can't go around saying "fil-c has no escape hatches" when it has one, even if that one is planned on being removed. > Fil-C is not Linux only by design, that's completely false. Can you explain…

It would work basically the way it works on Linux? What makes you think it's somehow fundamentally Linux-specific?

On non-Linux platforms, you must go through a system provided shared library rather than make syscalls directly. fil-c has its own ABI, and so it has its own libc that uses it. You cannot recompile those other systems's libc (or equivalent) with fil-c, therefore, the strategy used on Linux cannot work.

This is one reason why Rust has unsafe: you have to interact with inherently unsafe APIs in order to do anything meaningful with the operating system. fil-c needs an equivalent of some kind, and so isn't better or worse here, it's just the reality of how these systems work.

Post reply on HN