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

271–280 of 295 posts

Re: Zig's New Relationship with LLVM

#271

Post by dixon395 »

jimbob45 wrote: post #131
pron wrote: post #52

Zig is one of the most interesting languages I've seen in a very long time, and possibly the first radical breakthrough in low-level programming design in decades. Maybe it will become a big success and maybe it will tank, but after having two visions for low-level programming -- that of C's "syntax-sugared Assembly", or that of C++'s "zero-cost abstractions" whose low-level, low-abstraction code appears high level o…

Wait doesn’t Zig compete with C, not C++? IIRC it doesn’t have any intuitive form of typeclasses.

I thought it compete with both)

Re: Zig's New Relationship with LLVM

#272

Post by pabs3 »

AndyKelley wrote: post #260
pabs3 wrote: post #259

Earlier quoted context omitted.

Hmm, since the LLVM/Clang/Zig files in that repo are unmodified, why not just move the zig-bootstrap build script to a bootstrap script in the zig repository?

what purpose would that serve?

Seems simpler to have one repo for building zig no matter whether you want a bootstrap build or a from-zig build.

Re: Zig's New Relationship with LLVM

#273

Post by pron »

pjmlp wrote: post #270
pron wrote: post #256

Earlier quoted context omitted.

Just to be clear, Zig isn't the same as C/C++ with sanitizers. Zig has slices and it doesn't have pointer arithmetic and pervasive casts. For example, if you preallocate a buffer and then reuse it, or chunk it into multiple pieces, sanitizers won't find an issue, but Zig will (thanks to slices). C simply has no way to express, "I want to pass a pointer into an array to this subroutine but it is only allowed to use n…

C++ has it though, https://github.com/microsoft/GSL/blob/master/include/gsl/spa...

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.

Re: Zig's New Relationship with LLVM

#274

Post by pron »

Bekwnn wrote: post #246
pron wrote: post #244

Earlier quoted context omitted.

I think Zig competes with C++, too. But to match the expressivity of C++ you don't necessarily need to have the exact same features. C++ gives you control over generics with concepts, and Zig does it differently -- with introspection, which is very much a first-class feature. If Zig wanted to achieve what other languages do in the same way they do it, it wouldn't be radical. Instead, it offers a different way. When c…

I think Zig competes with a school of C++ that tries to stick to a simpler, limited subset of C++. Games is one area where C++ is much more common than C, but also where a lot of C++ practices (exceptions, excessive template use, many parts of the stdlib) are discouraged and things tend to be kept "simpler". I'm sure there are a good handful of other fields that currently write "minimal C-like C++" and I think Zig co…

But Zig has counterparts to exceptions, templates and anything you may want to do with them; it compares quite nicely with even "rich" C++. The one thing it intentionally doesn't have is operator overloading. In general, I'd say that the difference between Zig and C++ is that when you do some clever stuff in Zig, you need to be explicit about it so that the reader knows this call-site uses dynamic dispatch or that there is a destructor being called or that this operation isn't really the standard +.

Re: Zig's New Relationship with LLVM

#275

Post by pjmlp »

pron wrote: post #273
pjmlp wrote: post #270

Earlier quoted context omitted.

C++ has it though, https://github.com/microsoft/GSL/blob/master/include/gsl/spa...

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

Re: Zig's New Relationship with LLVM

#276

Post by pron »

sai_c wrote: post #263
Ar-Curunir wrote: post #175

Earlier quoted context omitted.

> "Focus on debugging your application rather than debugging your programming language knowledge." > > I have yet so see a community driven language that fulfills this promise in a comparable way to C's. I mean, this is only true if you ignore the myriad ways in which C allows you to manifest memory unsafety and undefined behaviour

"I mean, this is only true if you ignore the myriad ways in which C allows you to manifest memory unsafety and undefined behaviour" Which Zig has as well in release mode.

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 that I don't just mean outside of allocated buffers, but even "sub-buffers" derived from them.

Re: Zig's New Relationship with LLVM

#277

Post by ksec »

benesch wrote: post #26

Yes, yes, yes, yes, yes. I'm going to make the kind of prediction that will set me up to be the laughingstock of HN in a few years. I think in-place binary patching will be the single most consequential development in build toolchains in the last twenty years; the most consequential development since a graduate student at the University of Illinois named Chris Lattner decided to embark on LLVM. If Zig is successful i…

> The differences between a dynamic language like Python and a compiled language like Zig become mightly slim when recompiling a large Zig program becomes as fast as restarting a Python program.

This. Possibly a whole paradigm shift in computer programming since the introduction of VM.

Re: Zig's New Relationship with LLVM

#278

Post by steveklabnik »

est31 wrote: post #262
steveklabnik wrote: post #255

Earlier quoted context omitted.

What specifically made you need to? Editions aren’t supposed to make you do that. I would be interested in hearing what we missed!

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.

Re: Zig's New Relationship with LLVM

#279

Post by sai_c »

pron wrote: post #276
sai_c wrote: post #263

Earlier quoted context omitted.

"I mean, this is only true if you ignore the myriad ways in which C allows you to manifest memory unsafety and undefined behaviour" Which Zig has as well in release mode.

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 (although Zig promises to do so, see link above).

EDIT: Corrected formatting.

Re: Zig's New Relationship with LLVM

#280

Post by CyberDildonics »

yamirui wrote: post #234
CyberDildonics wrote: post #136

Earlier quoted context omitted.

Why not do that with a formatting tool that applies to the compiler source instead of purposely breaking hello world on windows?

Same answer as to why you don't configure your text editor to just not emit useless and outdated CR from past century - he has better things to do. And no, really, check out Zig repo's issue tab, he really has better things to do with his time on a project that's still evolving. You're demanding 1.0+ usability from a language that's has yet to stand up on its own feet and is currently, unsurprisingly, 0.6.0 and won't…

Ignoring two different ascii bytes is not "1.0+ usability". The idea that it is a matter of work is an insane rationalization. Someone else said it is to prevent 'bike shedding'.

None of the backwards rationalizations people give actually makes sense, especially since it literally breaks any "hello world" program on windows. It's insane that people would try so hard to make excuses for such a basic disregard for new people.

Think about the reverse. Let's say tabs are treated as spaces and carriage return bytes are ignored. Who would ever argue that something should be changed to break these things?

Post reply on HN