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

261–270 of 292 posts

Re: Zig's Incremental Compilation Internals

#261

Post by iczero »

pizlonator wrote: post #218
josephg wrote: post #131

Earlier quoted context omitted.

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

This thread is evidence of it. The OP is about Zig and now there are 40+ mentions of Fil-C initiated mostly by Rust folks and those comments are largely criticizing me personally. That’s toxic AF!

Exactly what is your definition of "initiated mostly by" and why do you promote it as objective? It sure seems to me that Rust detractors see the word "Rust" and immediately spawn a flame war. You, of course, also seem awfully happy every time it happens.

Re: Zig's Incremental Compilation Internals

#262

Post by afdbcreid »

pron wrote: post #251
afdbcreid wrote: post #246

Earlier quoted context omitted.

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

I'm well aware. I don't know a moving GC crate for Rust, but I do know that building a safe moving GC crate for Rust is possible, using the same principles as existing GC crates. It will not be exactly as performant as Java, because you don't have compiler support for updating pointers, but it will almost be - pointers inside the data structures can be updated via derive, the only pointer that cannot is the pointer to the data structure itself, so you will need to heap-allocate the data structure (the GC root). Given that in Java everything is under indirection anyway, this will have the same efficiency or even better.

Re: Zig's Incremental Compilation Internals

#264

Post by iczero »

pizlonator wrote: post #216
Maxatar wrote: post #54

Earlier quoted context omitted.

There's a distinction between claiming something is objectively better, which is what Fil-C claims with respect to its "idea" about memory safety compared to Rust... and claiming a personal preference for one approach versus another approach, which is what OP is saying about their own personal preference about how Zig reduces errors compared to how Rust reduces errors. It is absolutely possible that one language migh…

I never claimed that Fil-C is objectively better than Rust. As a long time PL researcher, I can, should, and will point out interesting corner cases of languages. Including in Fil-C or Rust

Here is someone providing real criticism of Rust: https://news.ycombinator.com/item?id=49101733

Here is you claiming "Facts" on a troll post claiming to "criticize" Rust: https://x.com/filpizlo/status/2081765923757903940

Re: Zig's Incremental Compilation Internals

#265

Post by dwattttt »

uecker wrote: post #254
dwattttt wrote: post #177

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

Agreed on the last point. I'm very much in favour of developing an analysis that can assert the absence of an abort, I just can't see how an approach like Fil-C can achieve that.

It can guarantee a potential memory corruption event will be caught at runtime, but at that point I have very limited options.

To be clear, I prefer aborting safely to corrupting memory. But I prefer "issue detected at development time" significantly more than both.

Re: Zig's Incremental Compilation Internals

#266

Post by dlcarrier »

tester756 wrote: post #104
dlcarrier wrote: post #92

I just looked up a Hello World program from the Zig Wikipedia article: const std = @import("std"); const File = std.Io.File; pub fn main(init: std.process.Init) !void { _ = try File.stdout().writeStreamingAll(init.io, "Hello, World!\n"); } That's a lot to follow, just to output a plan-text message, especially after this line: "The primary goal of Zig is to be a better solution to the sorts of tasks that are currently…

Whats the point of evaluating technology from hello world programs?

It shows the bare minimum overhead needed to start a project and gives some insight into the readability.

Re: Zig's Incremental Compilation Internals

#267

Post by kibwen »

pron wrote: post #249
kibwen wrote: post #58

Earlier quoted context omitted.

> Look at how many basic data structures (in the standard library or outside it) require unsafe features in Java vs Rust. This is a fundamental misunderstanding of how "unsafe" code relates to a platform's trusted computing base. Rust could move all of those unsafe data structures out of the standard library and into the compiler itself, thereby reducing the amount of occurrences of the string "unsafe" in the source,…

> This is a fundamental misunderstanding of how "unsafe" code relates to a platform's trusted computing base. Rust could move all of those unsafe data structures out of the standard library and into the compiler itself, thereby reducing the amount of occurrences of the string "unsafe" in the source, code, but this would do nothing to reduce the size of the trusted computing base that Rust presents. No, you're missing…

> No, you're missing the point, which is that you cannot write some common data structures in safe Rust (whether they're implemented in the standard library or in the compiler), but you can in Java (inside or outside the standard library). In other words, the point is that safe Rust is quite restricted.

This is incorrect. You can write those data structures in safe Rust just as easily as you can in Java. You'd write them using the safe primitives that the Rust stdlib provides to you, just like how Java does it. Such collections could often be made to have superior performance by using unsafe Rust, which is why the collections in the stdlib use unsafe code internally, but it's an optimization, not a requirement. You highly underestimate what safe Rust can do; it's not "quite restricted", this is a low-information take.

> In Rust, that base has to be extended to any third-party code that uses unsafe, which is needed in many more situations.

That Rust allows you to define your own safe interfaces to unsafe constructs is a strength of Rust, and necessary for any language that wants to challenge C and C++ on the basis of runtime performance.

> It isn't controversial that the amount of stuff you can do in safe Java is significantly higher than the amount of stuff you can do in safe Rust. That's just obvious.

Turns out, things that people take as obvious can also be wrong.

Re: Zig's Incremental Compilation Internals

#268

Post by pron »

afdbcreid wrote: post #262
pron wrote: post #251

Earlier quoted context omitted.

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

I'm well aware. I don't know a moving GC crate for Rust, but I do know that building a safe moving GC crate for Rust is possible, using the same principles as existing GC crates. It will not be exactly as performant as Java, because you don't have compiler support for updating pointers, but it will almost be - pointers inside the data structures can be updated via derive, the only pointer that cannot is the pointer t…

> I don't know a moving GC crate for Rust, but I do know that building a safe moving GC crate for Rust is possible, using the same principles as existing GC crates.

But those pointers would not interoperate easily with code that does not expect them. Of course you could effectively "host" a moving GC world inside Rust (or C++, or C), just as you could host the entire JVM in a Rust program (or vice-versa, host a Rust program in a Java program), but the effectiveness and attractiveness of that depends on interoperability with existing libraries.

Java's FFM also lets you bring your own memory management strategies, but the interop with existing types is not transparent (i.e. while you can put a manually-managed object that implements a Map or a List interface in the manually-managed portion, you cannot let that Map or List store arbitrary Java objects).

So there can be interfaces that connect a world of moving pointers and a world of non-moving ones (that's what FFM is), but then the interop between them is pretty much the same as FFM, i.e. the interface between Java and C. That's not really "in the same language".

> Given that in Java everything is under indirection anyway,

I don't know what that means. References in Java are implemented as pointers (some GCs use free bits for some stuff). Maybe you mean that Java doesn't yet have types that are flattened into their container, but it will soon: https://openjdk.org/jeps/401 (this is only the first step). Indeed, that was the last gap that could still allow me to match or beat Java's performance even in some large programs (provided they matched a domain where this was important, and there are certainly some). With that gap closing, the number of large programs where I, an experienced C++ programmer, could even match Java's performance without extraordinary effort is getting very, very, very small.

Re: Zig's Incremental Compilation Internals

#270

Post by dlcarrier »

boomlinde wrote: post #202
flohofwoe wrote: post #183

Earlier quoted context omitted.

Tbf, it's a useful indicator whether a language follows the "simple things should be simple, complex things should be possible" principle. The vanilla 'Hello World' should always be an example of the "simple things should be simple" part.

The typical Hello World implementation tends to reveal very little about the language, because their print/println/printf/whatever implementations have failure modes that are either impossible to handle or easily ignored (e.g. panicking, throwing exceptions or returning error codes which you can implicitly ignore without compilation error) which they frequently use to effectively hide the complexity inherent to the p…

It's really easy to make a C hello world program that forwards the success of printf:

    #include 
    int main(void)
    {
        return printf("hello, world\n");
    }
I just tested it in a Bash shell, and it works great, only adding a single word, with clear functionality, to the example.
Post reply on HN