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

271–280 of 292 posts

Re: Zig's Incremental Compilation Internals

#271

Post by pron »

kibwen wrote: post #267
pron wrote: post #249

Earlier quoted context omitted.

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

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

Of course you can, but the reason you don't is that their performance would be quite bad. I guess you could call that "an optimisation", but good performance for these data structures is a requirement. I am well aware that you can do a lot in safe Rust, but the result is such that you wouldn't want to use Rust at all.

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

Every language with unsafe constructs allows you to do that! The problem is that with Rust you need to do it quite a bit (of course, if you want acceptable performance, that is). That's not an upside of Rust compared to other safe languages, it's a downside.

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

They can, but this one isn't. Safe Rust is Turing complete and in the functional sense you could do anything with it. But the same is true for Python. So does that mean safe Rust and Python are interchangeable because by your measure they can do the same things? Of course not.

Re: Zig's Incremental Compilation Internals

#272

Post by pron »

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

Pointer aliasing by default was a mistake. I won't budge on this one. The borrow checker is a good idea independent of memory safety. In fact, I would say that if you think that the borrow checker is a tool to ensure memory safety and it is getting in the way of flexibility, you probably don't understand the underlying problem. The memory safety given by Rust is obviously not airtight, because the aliasing case requi…

> The borrow checker is a good idea independent of memory safety. In fact, I would say that if you think that the borrow checker is a tool to ensure memory safety and it is getting in the way of flexibility, you probably don't understand the underlying problem.

I don't think that, but I don't think that "the borrow checker is a good idea independent of memory safety" in an unqualified way. I don't doubt its general utility for one second, but I resist adding a lot of useful constructs to the language I have some influence over because I think that every feature hurts the language a bit by adding complexity. So for every feature the tough question isn't "is it useful" but "is it worth the price?" I don't have an answer for the borrow checker (and the answer also depends on the language's intended audience) but I don't think it's an obvious yes.

> The painfully constricting flexibility so reminiscent of C that everyone else clings to is not where I want to go back to.

That's not what I was talking about. When I use a low-level language, I use it not for what I would call flexibility, but for what I would call control. If Rust could give me safety in the parts I'm less interested in for "free", I wouldn't care about using unsafe Rust. The safe part would be pure bonus; not worth a whole lot, but I'll gladly take it. But that's not what's happening. To support safety in the safe subset, Rust is so complicated that I pay the price whether I get to enjoy that safety or not.

I think that for the safe parts, Rust would have been better off using some flavour of non-moving GC because interop between full-control low-level code and non-moving GC isn't too hard (whether tracing or refcounting; it doesn't matter all that much), which would have kept the safe part simpler. Maybe it would have looked more like Swift.

Re: Zig's Incremental Compilation Internals

#273

Post by pron »

galangalalgol wrote: post #189
josephg wrote: post #144

Earlier quoted context omitted.

Good to know! Would there be any way languages like Go or C# could adopt Nim's new garbage collector? If it's better, what stops other languages from using it? > GC programs can be faster than manually managed ones in some cases. I've seen poorly written programs in C/C++/Rust which are slow because they allocate millions of tiny objects. Its true that generational GCs can be faster in this case. But you usually get…

Even if you don't think about memory management, and do the naive thing in rust or rc in some other systems language, gc only comes out ahead in that many tiny objects case. Which is very domain specific. I don't ever run into that situation, or if I do, they are homogeneous in type so I handle them in bulk, not individually.

That depends on what you mean by GC. There are refcounting GCs, there are mark-and-sweep tracing GCs (like the one Go uses), and there are moving GCs (the last ones are the ones used in Java, V8, and .NET). Moving GCs win in many situations because they're just a really efficient algorithm both in theory and in practice (they win on speed, and the tradeoff is footprint). The downside is that they require 1. a lot of expertise and effort to implement (in fact, the first open-source, high-throughput, low-latency pauseless moving GC only appeared 3 years ago), which is why only specialised expert teams have implemented them, and 2. that virtually all pointers can move, which means that interop with low-level code requires some specialised API. That last restriction means that low-level languages generally cannot enjoy the optimisations that moving collectors bring.

Re: Zig's Incremental Compilation Internals

#274

Post by vlovich123 »

pron wrote: post #271
kibwen wrote: post #267

Earlier quoted context omitted.

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

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

> Of course you can, but the reason you don't is that their performance would be quite bad

Not very different from Java or C#. Worse than zig/c/c++ but that’s because those are the equivalent of using use in rust.

Re: Zig's Incremental Compilation Internals

#275

Post by literallyroy »

awesome_dude wrote: post #60
steveklabnik wrote: post #46

Earlier quoted context omitted.

I can say that something is "table stakes" for me without demanding that everyone else adhere to my values.

There's little point in me telling the world how I like my dinnercooked, unless the world both understands exactly what I mean, and cares

This doesn’t seem useful. I understood the parent comment and cared since OP’s opinions/thoughts/reasoning help me sort my own thoughts.

Re: Zig's Incremental Compilation Internals

#276

Post by phire »

tester756 wrote: post #106
dwattttt wrote: post #102

Earlier quoted context omitted.

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.

>While most hello worlds do not check that the message was printed Should they?

Really depends on what a hello world is meant to be a simplification of.

If hello world is meant to be a simplification of printing large amounts of text to a buffered standard out? Then yes, it probably should be checking errors.

If hello world is meant to be a simplification of low-volume debug logging to prove that code was reached (aka, printf debugging), then the simple alternative hello world using std.debug.print is what you want.

For such debug prints, you don't want any buffering, you don't want it mixed in with stdout (despite the name, stderr is not just for error messages), and you don't really need to check for errors. And std.debug.print does not return errors.

Re: Zig's Incremental Compilation Internals

#277

Post by duped »

pron wrote: post #260
duped wrote: post #70

Earlier quoted context omitted.

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

You don't find it useful that use after free, double free, uninitialized memory, and many kinds of race conditions are just impossible in code that compiles?

What exactly is the low level subset you feel like you can't use?

Re: Zig's Incremental Compilation Internals

#278

Post by steveklabnik »

chaz72 wrote: post #253
imtringued wrote: post #192

Earlier quoted context omitted.

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

I should let things go more often, it's a personal problem :) Thanks for the nudge, I'll consider it in the future.

Re: Zig's Incremental Compilation Internals

#279

Post by tstack »

steveklabnik wrote: post #278
chaz72 wrote: post #253

Earlier quoted context omitted.

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

I should let things go more often, it's a personal problem :) Thanks for the nudge, I'll consider it in the future.

Let the healing begin!

Re: Zig's Incremental Compilation Internals

#280

Post by gf000 »

pron wrote: post #31
saghm wrote: post #19

Earlier quoted context omitted.

> I'm not sure what that means. Java lets you do many things 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. I don't think I agree with this framing. The question to me isn't "what can you do while being memory safe", it's "can you accidentally do something memory unsafe without noticing?" Rust and Java are the same here; you need to exp…

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…

But unsafe Rust is still considerably safer than C (not sure about how it stands up to Zig, though)
Post reply on HN