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

251–260 of 292 posts

Re: Zig's Incremental Compilation Internals

#251

Post by pron »

afdbcreid wrote: post #246
bluecalm wrote: post #208

Earlier quoted context omitted.

Yeah but that doesn't work for any kind of performant code which is the reason people who write those data structures use unsafe. This is one very annoying thing about Rust community. The language sucks for coding self-referencing data structures with unpredictable free patterns. This is a fact and the reason number of people on this very forum posted long articles about moving away from Rust for those purposes. Your…

No, you really can. You can use GC crates and the performance will be like Java, or you can use Rc and the performance will be like Swift. The only reason Rust people use unsafe for data structures (and they do not always do) is that for them, Java/Swift-level performance is just not enough.

> No, you really can. You can use GC crates and the performance will be like Java

It won't be anywhere near Java's. Those GCs are mark-and-sweep collectors. Java uses moving collectors. Moving collectors are used to avoid the high overheads of malloc/free in the C runtime (or of any free-list-based mechanism). They're a performance optimisation. Heap allocations in Java behave more like arenas than like heap allocations in languages with non-moving memory management, whether it's C, Rust, Python, or Go. Other runtimes that use moving collectors are Google's V8 and Microsoft's .NET, except that Java's ZGC has no GC pauses.

Re: Zig's Incremental Compilation Internals

#252

Post by johnlorentzson »

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

> Fil-C is the worst of all worlds here. Like C, it forces you to manually manage your own memory. Can you expand on this?

As far as I know calling free is optional with Fil-C. It can prevent situations where some memory is no longer needed but isn't freed due to some remaining pointer to it sitting around somewhere, but it's not required. The GC will act like a GC if given the opportunity.

Re: Zig's Incremental Compilation Internals

#253

Post by chaz72 »

imtringued wrote: post #192
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…

>Steve, even you - I don’t believe I have ever seen you say an unkind word. 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? You're accusing steve of what pron is doing... I mean look at how much text pron wrote, it is much more than steve wrote, and how pron is constantly skirting the edges of the HN guidelines.

My reasoning, which you may not agree with, is that I think that I have seen pron say unkind words before and I thought I had a better chance of persuading Steve to let it go. (Sorry pron, that’s how I was thinking of it. No, I have no specific examples.)

The fact is that every thread about Zig is filled with this kind of battle, and I’m tired of it, and it doesn’t represent any community, it’s so much worse on HN than anywhere else, and it’s all just defensiveness and crap.

Re: Zig's Incremental Compilation Internals

#254

Post by uecker »

dwattttt wrote: post #177
uecker wrote: post #154

Earlier quoted context omitted.

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

> Regarding the silly point: Fil-C is less of a rock than Safe Rust as everything in C just works. I'm going to challenge this. Is this from your experience? InvisiCaps, which Fil-C is based on, turns out of bounds accesses into panics. You're saying that turning any "benign" out of bounds into "abort the program" in all the C you? anyone? everyone? uses Just Works? I'd rather the majority of those failure modes be c…

It certainly works in my C programs. And Fil-C demos imply that this also works for a lot of other complex real world programs, i.e. a basic Linux distribution with libreoffice on top... So yes, I would say this just works. I agree that catching this at compile-time is better, and to some degree this also works: https://godbolt.org/z/sse74vK9o

Rust does not offer compile-time guarantee that an out-of-bounds access does not panic either.

Re: Zig's Incremental Compilation Internals

#255

Post by hexane360 »

mbrock wrote: post #237
steveklabnik wrote: post #233

Earlier quoted context omitted.

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.

https://codeberg.org/ziglang/zig/issues/36237

>introduce an actually memory safe (unlike borrow checking) compilation mode inspired by Fil-C

Re: Zig's Incremental Compilation Internals

#256

Post by iczero »

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

https://news.ycombinator.com/item?id=49097320

You think this is reasonable? I have also seen strange people on twitter support Fil-C while claiming that Rust is a language for [slur]s. I suppose by your "reasoning" that these people directly represent you and your project?

Re: Zig's Incremental Compilation Internals

#257

Post by pron »

throwaway2037 wrote: post #220
pron wrote: post #16

Earlier quoted context omitted.

> I believe memory safety is table stakes I'm not sure what that means. Java lets you do many things programs may want to do in a memory-safe way but not everything. Rust lets you do fewer things than Java in a memory-safe way, but more things than Zig. Zig lets you do fewer things in a memory-safe way than Rust, but more than C. So among these four languages we already have four levels of memory safety, none of them…

> Java lets you do many things programs may want to do in a memory-safe way but not everything. Can you give an example of Java lets you do that is not memory-safe? Honestly, I don't really count the crazy off-heap tricks that some people use. It's almost like writing a Python library in pure C, intead of Python, then complaining that Python allows you to do non-memory-safe things.

With FFM you can do unsafe things, such as call native code and directly manipulate memory read from or written to by native code.

Re: Zig's Incremental Compilation Internals

#258

Post by pron »

nextaccountic wrote: post #111
pron wrote: post #16

Earlier quoted context omitted.

> I believe memory safety is table stakes I'm not sure what that means. Java lets you do many things programs may want to do in a memory-safe way but not everything. Rust lets you do fewer things than Java in a memory-safe way, but more things than Zig. Zig lets you do fewer things in a memory-safe way than Rust, but more than C. So among these four languages we already have four levels of memory safety, none of them…

safe Rust is actually more memory safe than Java, since it guards against data races (in Java data races are not UB, but they are still one of the worst kinds of bugs because it leads to logically impossible program states) Also note that Java has unsafe, but doesn't have the culture of plainly stating safety invariants like Rust. The unsafe features of Java are less widely used, but when they are you rarely know if…

> safe Rust is actually more memory safe than Java, since it guards against data races

No, it isn't. First of all, data races in Java are memory-safe, as guaranteed by the Java memory model. Second, even if that were safer in some sense it is only by dint of restricting the capabilities of the safe subset further, thus requiring more unsafe code, not less (e.g. because of that data race restriction in Rust, benign races, which are rather common in concurrent code and are not only safe but also deterministically correct, also require unsafe code).

The major challenge with safety is how to offer it without complicating the language much and not restricting the safe subset. It becomes much easier if you do one or both, and Rust compromises heavily on both, which comes at a price (correctness may suffer if the language is complicated, and safety and/or performance suffer when the safe subset is restricted). Some may find that tradeoff attractive, but it should be clear why others don't.

> Also note that Java has unsafe, but doesn't have the culture of plainly stating safety invariants like Rust. The unsafe features of Java are less widely used, but when they are you rarely know if a Java library has unsafe internals for performance, and if they do, it may be hard to audit

Quite the opposite. First, Unsafe is being removed altogether (https://openjdk.org/jeps/498), and overall, the remaining unsafe operations are now restricted to a very narrow, well-defined set of APIs (basically FFM, the FFI API). Second, Java's integrity guarantees (you can think about integrity as generalised memory safety) - as well as requesting exceptions to them (e.g. permissions to use FFM) - are handled in a more centralised, well-integrated, and auditable way than in any other well-known language: https://openjdk.org/jeps/8305968

Re: Zig's Incremental Compilation Internals

#259

Post by steveklabnik »

afdbcreid wrote: post #245
steveklabnik wrote: post #236

Earlier quoted context omitted.

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.

That is of course true, but if anything that just proves more what I said. Also that too is part of the "common wisdom" (that as I said, is not always true).

I wasn’t trying to disagree at all :)

Re: Zig's Incremental Compilation Internals

#260

Post by pron »

duped wrote: post #70
pron wrote: post #31

Earlier quoted context omitted.

That framing may seem intellectually satisfying, but it's not useful in practice. Consider the extreme edge case of C: We can clearly mechanically delineate between the empty program and a non-empty one, we call the empty program safe and any program that isn't empty unsafe (i.e. C is memory-safe if you want to do nothing and not if you want to do anything). And so, we also have this property that in C you can't do a…

People find it immensely useful in practice, though.

They find it immensely useful in practice only when the safe subset is useful. In C, you could say that the same definition of memory-safety exists, only the safe subset is empty, and in that case people don't find the fact that C could be described as memory-safe in that way useful at all.

And that's exactly my point. The safe subset of Rust doesn't sufficiently cover the very things that I choose a low-level language for in the first place, and the parts it does cover I can do at least as well in even safer high-level languages.

Now, I'm not saying there aren't programs where Rust's precise mix of safety and unsafety is better than the alternatives. For example, I've never written a browser rendering engine, and it's possible that I would find Rust to be the best fit for that task. I don't know that I would, but I also have no experience with that domain to suggest that I wouldn't.

Post reply on HN