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

221–230 of 292 posts

Re: Zig's Incremental Compilation Internals

#221

Post by rkangel »

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]

Can you provide a citation to this fairly major claim?

Re: Zig's Incremental Compilation Internals

#222

Post by ModernMech »

pizlonator wrote: post #217
steveklabnik wrote: post #72

Earlier quoted context omitted.

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

[flagged]

You just posted this troll: https://news.ycombinator.com/item?id=49097320

Re: Zig's Incremental Compilation Internals

#224

Post by ModernMech »

pizlonator wrote: post #223
ModernMech wrote: post #222

Earlier quoted context omitted.

You just posted this troll: https://news.ycombinator.com/item?id=49097320

Saying something that you don’t believe isn’t trolling.

You said "I just post facts". It is not a fact that the Rust community is lobbying to make programming in C illegal. Do you understand why some people in that community might consider that trolling?

Re: Zig's Incremental Compilation Internals

#225

Post by CJefferson »

pron wrote: post #219
pron wrote: post #203

Earlier quoted context omitted.

> To him, the entire code base might as well be unsafe. Not at all. I would very much like the code to be safe, it's just that I reach for a low level language to get the thing that low-level languages are designed to offer me, which is control, and no language offers control and safety at the same time. So when the interesting parts of the code could be written in safe Rust, I have to give up control, and in that ca…

P.S. And that brings me back to the universality point, that you're actually repeating, so let me explain it again. All programming languages bring a certain aesthetic that appeals to some and repels others within their intended domain . For example, I prefer Java to C# and Kotlin because I place a value on language simplicity, but I'm well aware that some other people like a lot of convenience features and they have…

P.P.S.

Assuming you are replying to me, you seem to be projecting very powerfully. Rust isn't my favorite language, and I just asked about how much of your code was safe vs unsafe.

Re: Zig's Incremental Compilation Internals

#226

Post by surajrmal »

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]

I don't think there is anything wrong with increasing liability for writing preventable bugs. The floor should be raised as our tools improve and the negative outcomes of these bugs increase. Making c illegal is not a goal of anyone I know of.

Re: Zig's Incremental Compilation Internals

#227

Post by MatejKafka »

archargelod wrote: post #139
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…

> GC languages are slower This is not necessarily true. It depends on a language, e.g. Go is slow, Nim[0] is extremely fast with conventional GC and slightly faster with ARC/ORC[1]. GC programs can be faster than manually managed ones in some cases. It's just manual memory management gives you more control of where and when free is called. And a good type system is a privelege that gives Nim more control with destruc…

I haven't seen data that would confirm that the Nim ARC/ORC approach is faster than manual memory management (C/Rust/Zig/...) on programs with non-trivial lifetimes (for trivial lifetimes, Nim elides RC). I'd also be somewhat surprised if it was consistently faster than GC – most languages with automatic memory management use GC over RC because RC adds significant overhead, especially in multithreaded programs.

Re: Zig's Incremental Compilation Internals

#228

Post by MatejKafka »

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…

> By the way, if you don't want a culture war, you gotta stop warring.

I find it hard to understand how could steveklabnik's comment be seen as warring.

Re: Zig's Incremental Compilation Internals

#229

Post by pron »

CJefferson wrote: post #225
pron wrote: post #219

Earlier quoted context omitted.

P.S. And that brings me back to the universality point, that you're actually repeating, so let me explain it again. All programming languages bring a certain aesthetic that appeals to some and repels others within their intended domain . For example, I prefer Java to C# and Kotlin because I place a value on language simplicity, but I'm well aware that some other people like a lot of convenience features and they have…

P.P.S. Assuming you are replying to me, you seem to be projecting very powerfully. Rust isn't my favorite language, and I just asked about how much of your code was safe vs unsafe.

No, I was replying to imtringued.

But to answer your question, I reach for a low-level language when I need the one and only thing low-level languages are designed to do best, which is give me full and precise control over the hardware. In those situations, Rust offers little safety in the interesting/subtle/critical code, and for me it even makes things worse. It helps with the simple uninteresting code. So it's not a matter of quantity but of quality.

Of course, if the tricky parts of the program don't require precise control over the hardware, I don't use a low-level language in the first place. For example, if I'm going to let the language manage memory for me, why suffer the high overhead of heap memory management in the Rust/C runtime when the Java runtime offers me lower overhead?

Re: Zig's Incremental Compilation Internals

#230

Post by steveklabnik »

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

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.
Post reply on HN