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

141–150 of 295 posts

Re: Zig's New Relationship with LLVM

#141

Post by pron »

tayistay wrote: post #139
pron wrote: post #58

Earlier quoted context omitted.

Zig is (or will be) memory-safe -- selectively. It just achieves that in a way that's very different from Rust. The way Zig helps you write memory safe programs is by adding runtime checks that eliminate undefined behaviour. UB becomes a panic. However, in your production build, you can choose to selectively remove those checks from some or all of your subroutines. If you remove those checks, while Zig does not give…

Rust will be safer. Reasoning is pretty simple: a dynamic approach (Zig) will only catch the memory errors for the tested code paths. This is probably only marginally better than running your C++ code's test suite with address sanitizer. Rust's static approach provides memory safety for all code paths.

Your conclusion rests on the assumption that Rust's sound guarantees are free and have no cost to correctness while they might very well do, or, put differently, that "all else is equal." It's like concluding that you must be richer than me because you have more cash in your wallet. See my comment here for more: https://news.ycombinator.com/item?id=24617127

Re: Zig's New Relationship with LLVM

#142

Post by adito »

pron wrote: post #116
the_duke wrote: post #108

Earlier quoted context omitted.

> and possibly the first radical breakthrough in low-level programming design in decades Can you expand what you mean here? I really like Zig, and there is definitely a big design space to explore in creating a modern low-level language that doesn't come with the complexity of something like Ada/Spark or Rust. This binary patching + daemonized compiler approach is particularly exciting. But as a language, I'm not awa…

> creating a better C I'm not sure I like the "better C" label. After all, Zig allows you to easily do stuff that's virtually impossible in C, and only possible in C++ with templates and constexprs and concepts. It also doesn't have pointer arithmetic and pervasive wild casts, so it's not a "syntax-sugared Assembly". Its only similarity to C is that it is a low-level language and that, unlike other low-level language…

> ... has never been attempted before. It is revolutionary.

Have you seen http://terralang.org/

Re: Zig's New Relationship with LLVM

#143

Post by tutfbhuf »

sai_c wrote: post #133
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…

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

I think people like you are the last one to adopt. Only when a new language is battle tested and has been around for at least two decades, with an language update rate equal or smaller than Go, only then you might want to consider it for your next embedded system. New languages invocations are by definition of new not for you, fair enough.

Re: Zig's New Relationship with LLVM

#144

Post by agentultra »

I started messing around with zig in earnest https://github.com/agentultra/zig8 and I have to say that the development experience is great so far. The compile times are fast, the tooling is minimal in the unix sense, and it's been nice to play around with.

Highlights:

- compile-time evaluation

- integrated testing through scoped blocks

- prevents some implicit casts that we take for granted in C

- catches allocation errors

- explicit error return handling

I appreciate it trying to make a better C.

Re: Zig's New Relationship with LLVM

#145

Post by mwcampbell »

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

On the topic of monolithic versus component builds, how much does Chromium's decision to use a large statically-linked module for release builds actually impact performance, both startup and steady-state? Has this been measured? For me, this characteristic of Chromium was always one of the most striking differences between it and IE, and even though Firefox has had one monster DLL for a while, Chromium takes this further. I just wonder how big a deal this obvious difference actually is for performance.

Re: Zig's New Relationship with LLVM

#146

Post by pron »

adito wrote: post #142
pron wrote: post #116

Earlier quoted context omitted.

> creating a better C I'm not sure I like the "better C" label. After all, Zig allows you to easily do stuff that's virtually impossible in C, and only possible in C++ with templates and constexprs and concepts. It also doesn't have pointer arithmetic and pervasive wild casts, so it's not a "syntax-sugared Assembly". Its only similarity to C is that it is a low-level language and that, unlike other low-level language…

> ... has never been attempted before. It is revolutionary. Have you seen http://terralang.org/

Someone pointed it out to me a while ago. I don't think the approach is comparable to Zig, but is in a somewhat similar spirit. Like with macros, Terra contains two languages (one of them being the meta language), while Zig has general partial evaluation in just one language (also https://news.ycombinator.com/item?id=24293611). For example, in Terra, conditional compilation is a branch in the metalanguage; in Zig, it's just a branch in Zig that is partially evaluated.

BTW, even Zig's build language is just Zig!

Re: Zig's New Relationship with LLVM

#147

Post by UncleOxidant »

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…

Tend to agree, but I hope that the zig folks aren't biting off too much by trying to replace LLVM. Sure, I can understand some of their reasons, but LLVM provides all kinds of functionality (optimization, code lowering, targeting lots of cpus,etc.) that will be difficult and time consuming to replace. I hope this doesn't cause them to lose focus on the development of the language itself and libraries.

Re: Zig's New Relationship with LLVM

#148

Post by cashsterling »

sai_c wrote: post #133
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…

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

At my place of work, we presently use C for embedded code because it is best supported for the microprocessor we are using... but we'd rather use Rust, Ada, or Zig. we may explore using Nim to generate C with static-only allocation.

Re: Zig's New Relationship with LLVM

#149

Post by moldavi »

whyever wrote: post #61
higerordermap wrote: post #3

I always like innovations in programming tooling. To me zig sounds like a system language written by system programmers, while rust is more influenced from FP and webdev communities, which is reflected in both tooling and language. To people asking why zig when there's rust, both are nice in different ways.

IIRC, Zig was partially born out of Andrew's frustration with Rust.

Really? Would love to hear more!

Re: Zig's New Relationship with LLVM

#150

Post by TylerE »

the_duke wrote: post #94
skohan wrote: post #79

Earlier quoted context omitted.

Rust allows virtually any type of memory management you want, my point is the syntax is not optimized for things like arena-based memory management or custom allocators. Rust assumes most of the time you'll be passing around references to values or small structures allocated on the stack.

In Zig, as far as I understand, you really just pass an allocator around. I don't see any special syntax to support this? This could be done in Rust. There is, for example, the simple bump allocator bumpalo [1]. It would be nice if the the std collections supported this (in planning, but hasn't seen much progress), and most dependencies would not be built around a manually passed allocator. > Rust assumes most of the…

The point is that the allocator CAN BE specified at call time for the entire stdlib.

And it doesn’t have to be just one allocator either, you can easily use multiple allocators simultaneously.

Post reply on HN