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

241–250 of 292 posts

Re: Zig's Incremental Compilation Internals

#241

Post by mirashii »

pizlonator wrote: post #211
josephg wrote: post #126

Earlier quoted context omitted.

Yeah. In that thread the Fil-C author said of typescript, go and C#: > Those languages rely on a much larger pile of YOLO C/C++ code for their runtimes and standard libraries than Fil-C does. So Fil-C is safer than those Given the relative immaturity of Fil-C, this seems wildly wrong to me. I’m not sure how to take his claims about his runtime seriously. [ https://news.ycombinator.com/item?id=49042736 ]

This is a simple fact. The Fil-C runtime is tiny compared to TS and C#

> The Fil-C runtime is tiny compared to TS and C#

Sure, this is a simple fact.

> So Fil-C is safer than those

This is not a simple fact that follows, and a good example of why you seem to be catching so much criticism for overly bold claims. One could state that a smaller runtime is easier to audit, and so the investment needed to reach similar levels of safety is lower. One might even argue that after similar levels of investment, that the probability that it's safer is higher. But jumping all the way from lower number of lines => safer is a simple fact is a huge leap.

Re: Zig's Incremental Compilation Internals

#242

Post by mustache_kimono »

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!

[flagged]

Re: Zig's Incremental Compilation Internals

#243

Post by pizlonator »

mirashii wrote: post #241
pizlonator wrote: post #211

Earlier quoted context omitted.

This is a simple fact. The Fil-C runtime is tiny compared to TS and C#

> The Fil-C runtime is tiny compared to TS and C# Sure, this is a simple fact. > So Fil-C is safer than those This is not a simple fact that follows, and a good example of why you seem to be catching so much criticism for overly bold claims. One could state that a smaller runtime is easier to audit, and so the investment needed to reach similar levels of safety is lower. One might even argue that after similar levels…

I have worked on both a major JS runtime and a .NET runtime. I have fixed hundreds of security bugs in JSC. Based on that, I have no doubt that what Fil-C does is safer. Just the absence of a JIT makes it safer in a way that I don’t think is seriously debatable. Even with JIT disabled, a JS runtime has massive attack surface due to the language relying on a large native library to do anything useful, not to mention a mind boggling amount of language implementation corner cases.

By contrast Fil-C has a small number of rules and largely obviates the need for “native” code.

Re: Zig's Incremental Compilation Internals

#244

Post by dlcarrier »

dwattttt wrote: post #102
defen wrote: post #93

Earlier quoted context omitted.

The issue is that most "hello world" programs are not correct.

While most hello worlds do not check that the message was printed (which I assume writeStreamingAll does for you), dismissing the rest of the differences as "the others aren't correct" isn't really accurate. Explicitly passing IO in is a fine design choice, but it's not a correctness issue to say others are wrong to not do so.

Also, it's easy to make a C program return the number of characters printed and doesn't hurt readability:

    #include 
    int main(void)
    {
        return printf("hello, world\n");
    }

Re: Zig's Incremental Compilation Internals

#245

Post by afdbcreid »

steveklabnik wrote: post #236
afdbcreid wrote: post #173

Earlier quoted context omitted.

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.

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

Re: Zig's Incremental Compilation Internals

#246

Post by afdbcreid »

bluecalm wrote: post #208
afdbcreid wrote: post #116

Earlier quoted context omitted.

That's just false. You can use `Arc` or even one of the safe GC crates available, and get semantics like Java with no `unsafe`.

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.

Re: Zig's Incremental Compilation Internals

#247

Post by landr0id »

steveklabnik wrote: post #240
mbrock wrote: post #238

Earlier quoted context omitted.

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

>you must go through a system provided shared library rather than make syscalls directly

Just to add to this, on Windows for example you're really only supposed to invoke syscalls via ntdll as the syscall table is not stable so their numbering changes over time. You cannot guarantee forward or backward compat if you do not use the library.

If you look at some of the syscalls in https://github.com/j00ru/windows-syscalls, you can see they clearly do change over time too.

Re: Zig's Incremental Compilation Internals

#248

Post by landr0id »

pizlonator wrote: post #213
rkangel wrote: post #201

Earlier quoted context omitted.

> First, because it promotes an "us vs them" mindset I was always intrigued by the maturity about how the Rust team approached this sort of thing. IIRC years ago you and I had a back and forth on me thinking it would be helpful to have a "Why Rust is better than C++" type page. Seeing an alternative approach from Andrew Kelley in recent weeks has really hammered home the value of the approach the Rust team took in te…

[flagged]

Comments like these are why, even if Fil-C has cool technical accomplishments, I find it hard to speak positively about it. You unfortunately seem to forgo all nuance and push disingenuous arguments which fuel the cycle with similarly disingenuous people.

I'll do you a favor though and cite a few things related to "lobbying"

The White House put out an RFI regarding open-source security: https://bidenwhitehouse.archives.gov/wp-content/uploads/2024...

Rust foundation's response: https://www.regulations.gov/comment/ONCD-2023-0002-0045

Neither have anything to do with making "programming in C illegal".

Re: Zig's Incremental Compilation Internals

#249

Post by pron »

kibwen wrote: post #58
pron wrote: post #33

Earlier quoted context omitted.

> Java and Rust have actually very similar memory safety profiles They really don't. Look at how many basic data structures (in the standard library or outside it) require unsafe features in Java vs Rust. > Zig has an identical memory safety profile to C It really doesn't. Zig gives you the same spatial memory safety as Rust and very much not like C (and violations of spatial memory safety are a bigger cause of vulne…

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

> Java's own data structures are implemented with the support of an extensive runtime written in C++, which forms their own trusted computing base that every user of Java relies upon, and demands just as much careful auditing as any data structure in the Rust standard library.

No, because these data structures are not part of the trusted computing base, which is fixed and closed. In Rust, that base has to be extended to any third-party code that uses unsafe, which is needed in many more situations. In fact, the need for unsafe code in Java has been so reduced that we're currently in the process of removing Unsafe altogether, making it inaccessible to third party code, which would still be able to write the data structures that would be unsafe in Rust in safe Java (the only unsafe thing remaining would be the FFM API, used for FFI, and the legacy JNI, used for that same purpose).

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.

Re: Zig's Incremental Compilation Internals

#250

Post by pron »

afdbcreid wrote: post #116
bluecalm wrote: post #94

Earlier quoted context omitted.

The point is not that those specific implementations use unsafe Rust but to illustrate that to write even basic data structures you need unsafe Rust.

That's just false. You can use `Arc` or even one of the safe GC crates available, and get semantics like Java with no `unsafe`.

You can't get the same semantics (e.g. no leaks) and you certainly can't get the same performance.
Post reply on HN