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

261–270 of 295 posts

Re: Zig's New Relationship with LLVM

#261

Post by exikyut »

evmar wrote: post #119
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…

At one point I got Chrome (a genuinely massive C++ project) to compile+link in under six seconds: http://neugierig.org/software/chromium/notes/2011/02/ninja.h... One of the big tricks not mentioned there is to decompose the app into multiple .so files (only when debugging -- release is still a single binary), so that you don't need to rebuild files unaffected by your incremental changes. I wrote more about that here:…

Ninja is neat.

I wonder if a) this is still possible with Chromium today, and b) if/how it might be possible to incrementally build changed functions into new .so files, rewrite the symbol tables in the old .so files to garbage (if needed?), then relink (either incrementally/in-place or from-scratch) the executable. Dependency analysis and garbage collection could delete fully-superceded .so files.

Re: Zig's New Relationship with LLVM

#262

Post by est31 »

steveklabnik wrote: post #255
est31 wrote: post #252

Earlier quoted context omitted.

You are still forced to upgrade your edition if you want to use certain libraries. I wanted to the newest versions of some async libraries and the update forced me to update my edition, otherwise I wouldn't have been able to use the libraries as they required me to use the async language feature. Also, editions are no response to the issue of new features being added to the language, changing what is considered idiom…

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 available, and as async/await is not available on the 2015 edition, I had to update the edition of the crate. The code got a lot simpler thanks to async/await so I'm very thankful for its existence.

Re: Zig's New Relationship with LLVM

#263

Post by sai_c »

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

Earlier quoted context omitted.

At this point in time, i agree with this analysis. But what for a C programmer (systems/embedded) remains to be seen, is, if any of the new languages (say for example Rust, Zig, Odin) can (or want to) offer one of C's strengths most language designers do not think of (at least it looks to me like that). And this would be for me "leave the language alone (for the most part)". If i may quote from Zig's website ( https:…

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

Re: Zig's New Relationship with LLVM

#264

Post by higerordermap »

eggy wrote: post #203
butterisgood wrote: post #29

I’ve often wanted to try out Zig at work but the dependency on the latest LLVM meant doing that first. Building LLVM from scratch on our platform takes more resources (including time) than I normally have available (LLDB needs like 6GB of RAM to link?) So, I welcome this news!

Aside from using software that relies on LLVM, I am not at all familiar with its internals. A fellow on another forum was ranting against using LLVM as a backend for security reasons pointing out its sheer size and the fact that it is a "US controlled software stack" [1]. Don't get me wrong, I think he has a very fringe and suspicious outlook on LLVM and the US, but it is a big codebase that would be hard to audit fo…

90% of your computing stack is US controlled code. What's so different about LLVM

LLVM monoculture is pretty bad though.. and its codebase quality is not very good either. But that's another issue.

Re: Zig's New Relationship with LLVM

#265

Post by higerordermap »

dasb wrote: post #158

I want to like Zig, but I just hate the {var | const } identifier : type syntax. I know it's an extremely superficial observation, but it just doesn't feel good to me.

I am a programmer and I make very scientific decisions. I don't like this language because syntax is not like C.

Re: Zig's New Relationship with LLVM

#266

Post by viraptor »

johnnycerberus wrote: post #68
viraptor wrote: post #28

Earlier quoted context omitted.

> that can achieve exactly the same thing That's a bold claim. What's the C formal validator which automatically handles both memory management and concurrency in source of any size within seconds/minutes? (Without making the source its own dialect rather than C)

I don't think we can call it "automatic handling", you just play by the borrow checker's rules. Automatic are the garbage collectors but not Rust's model. Anyway, you can verify the critical part of your C/Ada program by using: Why3 http://why3.lri.fr/ Frama-C http://frama-c.com/ (which is also extensible) SPARK https://www.adacore.com/about-spark One company that I've worked for used generators, they were specifying…

There's a bit of disjoint between what those tools do and they what Rust does. Rust provides something different - you write the source in standard code and get a sound app. Verifiers can't do that with C. You essentially either write a parallel list of annotations or generate the app from another language. It's a valid approach, but that's why I objected to "exactly the same thing".

Re: Zig's New Relationship with LLVM

#267

Post by evmar »

exikyut wrote: post #261
evmar wrote: post #119

Earlier quoted context omitted.

At one point I got Chrome (a genuinely massive C++ project) to compile+link in under six seconds: http://neugierig.org/software/chromium/notes/2011/02/ninja.h... One of the big tricks not mentioned there is to decompose the app into multiple .so files (only when debugging -- release is still a single binary), so that you don't need to rebuild files unaffected by your incremental changes. I wrote more about that here:…

Ninja is neat. I wonder if a) this is still possible with Chromium today, and b) if/how it might be possible to incrementally build changed functions into new .so files, rewrite the symbol tables in the old .so files to garbage (if needed?), then relink (either incrementally/in-place or from-scratch) the executable. Dependency analysis and garbage collection could delete fully-superceded .so files.

I haven't touched it in many years, but:

I think (a) it's still possible, per https://chromium.googlesource.com/chromium/src/+/master/docs... .

(b) Creating new .so files that shadow functions in others is an interesting idea! I think you're implying that the executable wouldn't pick them up for free, which I think is true, but I'm not actually sure. I forget the details of how this works but it might be that you could just play tricks with the order of the files to make them shadow.

In practice with a fast linker (I used gold at the time, but I think lld is even faster than gold now) it doesn't matter so much as long as you keep the component libraries small enough. But my info is also nearly a decade out of date now...

Re: Zig's New Relationship with LLVM

#268

Post by pjmlp »

cashsterling wrote: post #148
sai_c wrote: post #133

Earlier quoted context omitted.

At this point in time, i agree with this analysis. But what for a C programmer (systems/embedded) remains to be seen, is, if any of the new languages (say for example Rust, Zig, Odin) can (or want to) offer one of C's strengths most language designers do not think of (at least it looks to me like that). And this would be for me "leave the language alone (for the most part)". If i may quote from Zig's website ( https:…

My 0.02... and have an upvote for stating your opinion. C is not going any where.. we all know that. But it is not the best tool for accomplishing many systems programming tasks. IMO, this has probably been true since Ada95. Ada2012/SPARK, Rust, and probably Zig make this even more clear. For some domains, C was the ONLY tool available... e.g. C is/was the only language with board-level support and an available compi…

It was true since ever actually, not only Ada83, Modula-2, but also since NEWP, PL/I, PL/S among other possible ones.

Re: Zig's New Relationship with LLVM

#269

Post by pjmlp »

alexithymia wrote: post #258
sai_c wrote: post #155

Earlier quoted context omitted.

Yes indeed, Ada/SPARK would be better suited, but suffer (unfortunately) from a hefty price tag, not every shop is willing to pay. Especially if there are no lifes at stake should your software crash. Rust has the (imo) above stated problem. Also, if you avoid dynamic allocation, Rust's advantages are not as compelling in the real world as advertised (personal opinion). They are there, but IMO minor. The problem righ…

When you say Ada has a hefty price tag, what do you mean, exactly? (Are you talking about ide licences, the commercially supported version of the compiler, ramp-up time to productiveness, or maybe something else?) Somehow I've become interested in the economics of Ada, and am considering it in comparison to several other strongly typed systems programming languages for a learning project. So I'm a bit curious.

There are still 5 surviving Ada vendors, only Ada Core supports a FOSS compiler, for most commercial deployments the compilers lie in typical enterprise seat prices with "talk to our sales team".

Re: Zig's New Relationship with LLVM

#270

Post by pjmlp »

pron wrote: post #256
chubot wrote: post #168

Earlier quoted context omitted.

They're built into both GCC and Clang and very easy to use IMO. The only hard part is figuring out how to pass -fsanitize=address into your compiler via your complex build system! And building with symbols. That is inherent to the C/C++ toolchain and not a problem that sanitizers can address.

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