Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig's New Relationship with LLVM

kristoff.it

Post reply on HN
Print view View original

281–290 of 295 posts

Re: Zig's New Relationship with LLVM

#281

Post by pron »

sai_c wrote: post #279
pron wrote: post #276

Earlier quoted context omitted.

Yes, but in Debug/ReleaseSafe it's much stronger than C with sanitisers. Zig makes those problems so much easier to catch in development than C. Zig doesn't have pointer arithmetic and pervasive casts, and all traversals require knowing the data's size either at compile-time (Zig arrays) or runtime (Zig slices). Unless you explicitly do unsafe casts, Zig won't allow you to index anything outside a buffers, and by tha…

"Yes, but in Debug/ReleaseSafe it's much stronger than C with sanitisers." Is it also stronger than C with Frama-C? Are you sure you hit all the execution paths during development? Pervasive casts? Not under MISRA C. Look, I'm not criticising Zig on a technical level (I mentioned above I'm keeping an eye on it because it looks interesting), but I don't have any trust in community driven languages keeping it simple (a…

> Is it also stronger than C with Frama-C?

No, and, in fact, I specifically said that C has unparalleled tooling in the formal verification space: https://news.ycombinator.com/item?id=24618856

But, 1. as much as I like formal verification and am actively involved in the space, we're talking less than 1% of C code that uses those tools (unfortunately), and 2. because Zig is so simple -- simpler even than C from a formal analysis perspective because of slices and casts -- if it ever becomes successful, I have no doubt we'll see such tools emerge.

Of course, the other 99% can't use Zig either because it's not even "out" yet. Obviously, a product that doesn't even exist yet can't replace any product that does, and no one is suggesting that Zig -- in it's current virtually nonexistent form -- is a replacement for anything, let alone for C. We're talking about what Zig could do when it exists in some production-ready form.

Re: Zig's New Relationship with LLVM

#283

Post by atombender »

pron wrote: post #105
nyanpasu64 wrote: post #98

Earlier quoted context omitted.

Not a Zig user, but this seems to indicate Zig still doesn't always detect use-after-free even with all safety flags on. It seems progress is being made though. https://github.com/ziglang/zig/issues/3180

You are correct, that's still a WIP, but the goal is to have "safe Zig" (i.e. Zig with safety checks on) catch all undefined behaviour modulo explicitly marked unsafe casts (which correspond to unsafe Rust code).

By "catch", do you mean at compile time?

Re: Zig's New Relationship with LLVM

#284

Post by pron »

pjmlp wrote: post #275
pron wrote: post #273

Earlier quoted context omitted.

Right, but in this case it's not a matter of what you have, but what you don't . Zig has slices as the only form of moving pointers around, and it doesn't have any pointer arithmetic. I.e. every time some data is traversed, the language ensures the size is known either at compile time or runtime.

For the time being, https://github.com/ziglang/zig/issues/2018

This isn't exactly pointer arithmetic as in C (or in unsafe Zig, as with @intToPtr, or using the "unknown size" pointer type, [*]). This is talking about preserving size information, and only when the arithmetic is compile-time-known; so it's more "array arithmetic".

Re: Zig's New Relationship with LLVM

#285

Post by bigbizisverywyz »

tom_mellior wrote: post #7

I don't understand the "in-place binary patching" bit. Does it literally mean that the compiler opens the existing binary in a write-but-do-not truncate mode, leaves most bits in place, and only changes others in certain places? Is this expected to be that much faster than writing the whole binary anew? What other benefits is this supposed to have? The article doesn't seem to say. Also, how does this relate to the ob…

Glad you asked that question, I was wondering the same - and good answers.

I guess this is all in the pursuit of reducing link time, but a clean build will write the whole binary from scratch in a more compressed way?

Re: Zig's New Relationship with LLVM

#286

Post by est31 »

steveklabnik wrote: post #278
est31 wrote: post #262

Earlier quoted context omitted.

Note that it wasn't a simple cargo update, but an update between two semver incompatible releases of the futures crate, from 0.1 which supported edition 2015 and provided combinators, to 0.3 which was built on the async/await feature, and required its use, because the combinators were removed. I guess it would have been hard to provide them compatibly to async/await but I'm not sure about it. Anyways, they weren't av…

Ah yes, that makes perfect sense. I was thinking purely from the "you can still use the keywords because of the raw syntax" perspective, but in this case, that wouldn't quite work. Thank you.

Yeah there is a raw r#ident identifier syntax, but no raw keyword k#kwd syntax.

Re: Zig's New Relationship with LLVM

#287

Post by Guvante »

discreteevent wrote: post #212
Guvante wrote: post #171

Earlier quoted context omitted.

Rust has editions to help with this. All code is backwards compatible (except soundness bugs) and if need be editions are added to allow adding breaking changes. The compiler still supports 2015 edition and will forever. You can even use different editions in the same project by importing crates that use a different edition, still overall creating a single binary. As an example of this one of the features they added…

That's interesting but I don't know if it helps with the parents concern. If I arrive into a project, the same reasons that made them choose rust mean that they have likely chosen the latest version of rust, with all its complexity and power. If I am inspecting code for safety that is doing low level things then I want to have a clear and simple (imperative) model in my head. I don't want to spend the review admiring…

"Newfangled features" and "don't be too smart for your own good" don't overlap as much as you imply. They aren't entirely orthogonal but very much so.

C++'s `unique_ptr` is a "newfangled feature" but is not the latter (ignoring custom delete functionality).

I tried to account for the discrediting of zero cost abstractions (which I buy) but I think you are adding the latter onto that which I didn't get from the person I was responding to.

> I want to know as directly as possible what is going on in the machine

Certainly not in multi-threaded code on an x64 machine (and IIRC ARM is trending in that way as well). There are too many abstractions to actually do that, the best you can do is understand the abstract machine of the language and the rough edges translating that into real machine code entails.

> safety of low level code is not a concern

I will remind you that in the case of Rust safety is where all of this comes from not productivity.

Writing a mutex by hand is hard and you will make mistakes, here is a library construct to do it for you. It will be more complex than what you would write but it will be safer because others have worked with it. etc. etc.

When working with minimal computation resources using "works for everyone" constructs stops being zero cost and starts being expensive both conceptually (what were the poisoning rules again?) and performance wise when the cost of providing your abstraction is hard (why can't I arena allocate an RC?)

Those are the situations where Rust and even C++ have difficulty shining and C wins out. It provides so little you never have to pay for anything but what you absolutely need. But remember the things you lose out on are from every category you can think of, not just one. Performance, reliability and safety are all often sacrificed in some amount when writing custom code.

When you write code instead of a random Joe in a garage you know who to blame when it blows up. When you write code instead of using the larger community code you give up the often great characteristics in every metric for your more fine tuned characteristics in some metric generally.

Sorry that got wordy... TL;DR nothing about most low level languages up to things like Java and C# IMO stops you from having a simple imperative model in your head so using that to chose C over something else is missing the point.

Re: Zig's New Relationship with LLVM

#288

Post by Guvante »

est31 wrote: post #286
steveklabnik wrote: post #278

Earlier quoted context omitted.

Ah yes, that makes perfect sense. I was thinking purely from the "you can still use the keywords because of the raw syntax" perspective, but in this case, that wouldn't quite work. Thank you.

Yeah there is a raw r#ident identifier syntax, but no raw keyword k#kwd syntax.

Yeah rather than supporting backporting things like that they instead decided that every feature should have a lint that shows you how to update your edition.

Basically the idea was rather than making it as easy as possible to stay on the oldest version they focused that effort on making it as easy as possible to update once you decided that was what you wanted to do.

Re: Zig's New Relationship with LLVM

#289

Post by steveklabnik »

Guvante wrote: post #288
est31 wrote: post #286

Earlier quoted context omitted.

Yeah there is a raw r#ident identifier syntax, but no raw keyword k#kwd syntax.

Yeah rather than supporting backporting things like that they instead decided that every feature should have a lint that shows you how to update your edition. Basically the idea was rather than making it as easy as possible to stay on the oldest version they focused that effort on making it as easy as possible to update once you decided that was what you wanted to do.

We do backport all kinds of things, and we also the vast majority of things land on all editions.

This one is tricky for a few reasons that don't apply to most things.

Re: Zig's New Relationship with LLVM

#290

Post by pjmlp »

pron wrote: post #284
pjmlp wrote: post #275

Earlier quoted context omitted.

For the time being, https://github.com/ziglang/zig/issues/2018

This isn't exactly pointer arithmetic as in C (or in unsafe Zig, as with @intToPtr, or using the "unknown size" pointer type, [*]). This is talking about preserving size information, and only when the arithmetic is compile-time-known; so it's more "array arithmetic".

Fair enough.
Post reply on HN