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

71–80 of 292 posts

Re: Zig's Incremental Compilation Internals

#71

Post by steveklabnik »

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…

> But have you considered that it may be unkind to have written more than half of the words on a thread about a Zig performance feature?

Inherently? No! I commented specifically because I was really glad to see this post. This work that Zig is doing is very good, and I wanted to call that out, in part specifically because I am on "the other side" in whatever sense that is. Why would it be unkind for kind words to be coming from me?

Re: Zig's Incremental Compilation Internals

#72

Post by steveklabnik »

brabel wrote: post #57
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…

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…

Maybe I'm just old, but I want to focus on engineering outcomes, not "trolling." If that means "can't take a joke," that's fine, but also "haha I'm just joking" is often what people use to try and hide behind their actual intentions.

I don't even work on Rust anymore, and in fact started this thread with a criticism of Rust. There are lots of good criticisms of Rust. There is a difference between "this criticism isn't good" and "every criticism is an offense."

Re: Zig's Incremental Compilation Internals

#73

Post by IshKebab »

pron wrote: post #32
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…

So that could be a clear definition, but for it to be "table stakes" it needs to have some universal value and it doesn't (in fact, that very same definition could also classify even C as "memory safe"): https://news.ycombinator.com/item?id=49087458

I'm not exactly sure what you mean by "universal value", but I would say to be "table stakes" (i.e. not optional), it has to have overwhelming value. I think outside some fairly niche areas (e.g. programs that don't process untrusted data at all), it very very clearly has overwhelming value.

Now you might argue that the other features of Zig, like `defer`, are so good that they reduce the chance of memory errors and therefore memory safety has less value for Zig. But that seems highly dubious to me, especially for use-after-free. I guess we'll find out when Zig has more widespread use.

Re: Zig's Incremental Compilation Internals

#74

Post by hardwaregeek »

brabel wrote: post #57
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…

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…

[dead]

Re: Zig's Incremental Compilation Internals

#75

Post by chaz72 »

steveklabnik wrote: post #71
chaz72 wrote: post #65

Earlier quoted context omitted.

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…

> But have you considered that it may be unkind to have written more than half of the words on a thread about a Zig performance feature? Inherently? No! I commented specifically because I was really glad to see this post. This work that Zig is doing is very good, and I wanted to call that out, in part specifically because I am on "the other side" in whatever sense that is. Why would it be unkind for kind words to be…

I do see that you often have kind words for Zig and some attempt to more precisely define the differences.

What I mean is a bit different though, it’s that these arguments you get drawn into end up drowning out any real discussion of Zig’s progress. I don’t think that’s your intent but it is frustrating. I should be clear, I don’t think it’s wrong for you to defend yourself from accusations etc., I just wish it didn’t look like this.

I wonder how much better HN would be if they took a page from other forum systems that said “you know what, this whole branch of stuff should be moved over here and renamed so the original topic can move on”.

Sorry, all this may be unhelpful, I don’t know where the line should be, I’m just thinking out loud about the problem.

Re: Zig's Incremental Compilation Internals

#76

Post by steveklabnik »

saghm wrote: post #64
steveklabnik wrote: post #49

Earlier quoted context omitted.

I think that there is a general desire to work with the system, and since that is how other systems languages have generally done it, doing it the same way feels good. You don't necessarily want to innovate on everything all at once. It is true that for various reasons, Rust can't take as much advantage as say, C can. > I'm guessing this is related to what you mean by potentially being able to do something differentl…

Interesting. My perception for why other systems languages generally compile things to libraries is that they tend to use dynamic linking from a single instance of libraries on a system. I would have expected that when static linking is the default, the argument for having standalone intermediate libraries is much weaker, since the deviation from the other systems languages has already been decided. Maybe I'm missing…

> My perception for why other systems languages generally compile things to libraries is that they tend to use dynamic linking from a single instance of libraries on a system.

This is both true and not the whole story. In C, the file (okay if you want to get REALLY technical it's not the file but I'm talking about 99.9% of computers and not some old mainframe platforms) is the compilation unit. You pass a .c in, you get a .o (or whatever for your platform) out. Producing a final binary is where the static vs dynamic choice really comes into play, but you end up with these intermediate artifacts because that is how the language is defined.

> I would have expected that when static linking is the default, the argument for having standalone intermediate libraries is much weaker,

It is weaker, sure. But that doesn't mean there aren't other advantages. For example, you can more easily parallelize a large workload by breaking it up into multiple intermediate libraries, and compiling those simultaneously, whereas doing it all in one compilation/translation unit requires compiler support for said parallelization. Especially if you're already writing a batch compiler, this is a much easier win than rearchitecting the whole thing.

Re: Zig's Incremental Compilation Internals

#77

Post by applfanboysbgon »

joshuamorton wrote: post #67
applfanboysbgon wrote: post #59

Earlier quoted context omitted.

> those two groups are three orders of magnitude apart They aren't necessarily, though. Supposing that Zig were "10 issues per MLoC" (with just as much handwaving as the original poster), it would be equidistant from Rust and C. Java may also be more than one order of magnitude away from Rust; we say ~0 but is it 0.01, 0.001, 0.0001...? And why is "1 issue per MLoC" the acceptable metric that delineates what constitu…

> Or would you say your arbitrary delineation point is worth more than mine? Yes for the reasons I already gave. I think that at the point that you're having to stretch the numbers from their post to the breaking point to remove the pretty clear order of magnitude differences it's not really a constructive way to engage. I think you have two groups with one at ~.1 and one on ~100. You seen to either disagree with tha…

I think it is absolutely arbitrary. First because I believe every order of magnitude is significant. You handwave away that one order of magnitude difference is fine but three is bad. I think this is hypocritcal, and that if you want to be a memory safety purist who ignores all tradeoffs and declares a language fundamentally unusable on safety grounds, even a single order of magnitude of additional issues should clearly be unacceptable. And simultaneously you group them arbitrarily -- what is your actual basis for suggesting that Zig code is more likely to be 100 than 10, or that 10 somehow bares grouping at 100 rather than grouping .1 and 10 together at 1? You also fail to address that there may be more than one order of magnitude between Rust and Java. It is entirely plausible that Rust is closer to Zig than to Java.

---

Rate-limit edit replying to below response:

> a variety of statements I haven't said

We are in a conversation thread specifically about statements of this nature, which I was contesting. The original poster of this thread called their arbitrary definition of memory safety "table stakes" and explicitly said that they rule out Zig as a language completely on this basis alone. If you don't agree with them, I'm not sure what we're discussing.

> you take issue with the assumptions I'm making ... but you could just state that instead of saying that I'm being hypocritical

The only assumption I disagreed with is assigning Zig to exactly 100 when a poster I was replying to originally asserted a range of "10 or 100"; and regardless of whether we agree on assigning a concrete lower/upper bound to that assumption, everything else is not an assumption but a value judgment given the condition "assuming the premise holds". Yet your position is taking those value judgments - which orders of magnitudes to accept, which to group together as being the same degree of memory safety - and asserting them as objectively correct boundaries with minimal rationalisation beyond "because I feel it is so".

Re: Zig's Incremental Compilation Internals

#78

Post by slopinthebag »

pron wrote: post #68
saghm wrote: post #61

Earlier quoted context omitted.

> I'm not interested in the definition so much as I am in calling it "table stakes", and so the fact that these languages satisfy their promises is uninteresting in isolation. What matters is the value of their promises. The majority of Rust programs I see, I wouldn't have written in a low-level language, so the fact that it offers memory safety for the things I don't need it to do does nothing for me. I mean, if you…

> I'd argue that the value of Rust is that it makes low-level viable for a lot of stuff that would otherwise require a lack of memory safety; a lot of it is stuff that might be written in a higher level language, but that's just because relatively few programs are impossible to write in higher level languages. Maybe, but I don't see making a low language viable for something it's not needed as offering much value. Lo…

I just wanna give my perspective since I came from high level languages and pretty much exclusively use Rust now, so perhaps I can articulate why I find value in the language. And my apologies if my input is not wanted, no need to respond if so.

First of all I respect your point of view - I'm not a Rust absolutist, I think that garbage collected languages are a massive advantage for a lot of things and would never criticise someone choosing a higher level language. Likewise I wouldn't criticise someone choosing Zig or Oden or Jai or even C for tasks where you really need that low level control.

For me, I like to have a single language that I can use for pretty much everything. Afaik there is no other language that is a) popular b) has a modern toolchain with integrated build, formatting & linting etc, and c) can be used both in the kernel and for developing websites. Rust might not be the best choice for most of the spectrum of software, but it's good enough for everything. I can write a low level service + a web server and UI in the same language, where with other choices I would need to use two separate languages. This matters to me because I don't have the time to maintain mastery of multiple languages, I find a lot of value in focusing deeply on one language and learning it completely.

Now I also don't write a lot of low level rust, I've never written a block of unsafe before and I probably write "unidiomatic" rust with too much copying, too many Arc>'s etc. But I like knowing that I can if I need to.

Rust has a lot of other things going for it. A good type system with plenty of nice language constructs that are missing in a lot of higher level languages. It has Cargo and a healthy ecosystem (although I do worry about the number of dependencies used sometimes). And a large community of very smart people. I'm not saying this is exclusive to Rust, but as a whole Rust is a unique language with no alternatives if you value the things I do.

So I would say that it's approach to memory safety threads the needle where it can be used (although not the very best choice) for when you'd use a higher level language, but also gives enough control that you can do plenty of low level stuff in it safely, and with clearly delineated unsafe sections where you really can do anything.

Re: Zig's Incremental Compilation Internals

#79

Post by steveklabnik »

chaz72 wrote: post #75
steveklabnik wrote: post #71

Earlier quoted context omitted.

> But have you considered that it may be unkind to have written more than half of the words on a thread about a Zig performance feature? Inherently? No! I commented specifically because I was really glad to see this post. This work that Zig is doing is very good, and I wanted to call that out, in part specifically because I am on "the other side" in whatever sense that is. Why would it be unkind for kind words to be…

I do see that you often have kind words for Zig and some attempt to more precisely define the differences. What I mean is a bit different though, it’s that these arguments you get drawn into end up drowning out any real discussion of Zig’s progress. I don’t think that’s your intent but it is frustrating. I should be clear, I don’t think it’s wrong for you to defend yourself from accusations etc., I just wish it didn’…

Ah, I see what you're saying. Oh, trust me, it's very frustrating for me as well. It is especially frustrating in these specific circumstances because I know that Ron and I will not come to an agreement, so...

Re: Zig's Incremental Compilation Internals

#80

Post by hibra1 »

squeek502 wrote: post #48
dundarious wrote: post #35

Earlier quoted context omitted.

Not quite true, there is already a capable C compiler written in Zig (Aro/arocc), and a plan to transition to it for C compilation: https://codeberg.org/ziglang/translate-c Using this native (written in Zig) C compiler to translate C source into Zig source as a part of the build, would presumably lend itself trivially to all the incremental logic in TFA, as updating C would update the generated Zig, and the increment…

> a plan to transition to it for C compilation That's not planned AFAIK (see https://github.com/ziglang/zig/issues/16269 ). `translate-c` is really only intended for header translation, not C source code. See https://github.com/ziglang/zig/issues/20875 for the (not fully fleshed out yet) plans around C compilation.

Zig already uses arocc! https://codeberg.org/ziglang/zig/src/branch/master/lib/compi...
Post reply on HN