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

111–120 of 295 posts

Re: Zig's New Relationship with LLVM

#111

Post by fanf2 »

dnautics wrote: post #103
skohan wrote: post #65

Earlier quoted context omitted.

I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. I think Rust is a great, worthy language, and for a lot of use-cases it makes sense to optimize for trying to just put everything on the stack, but there are a lot of other cases where what you really want to do is own allocation by yourself instead of trusting it to the compiler. I hav…

> I really like the Zig approach of improving the tooling for manual memory management rather than replacing manual memory management. The new test allocator checks your code for memory leaks, use after free, and double free in a highly ergonomic fashion. I think is fantastic that zig encourages writing tests, and I think if you get full test coverage in your zig code with the test allocator, you will probably solve…

Address Sanitizer and valgrind are widely-used standard tools for finding allocation bugs

Re: Zig's New Relationship with LLVM

#112

Post by pkphilip »

higerordermap wrote: post #56
kristoff_it wrote: post #5

Earlier quoted context omitted.

I think Zig will reserve a few interesting surprises also in the webdev world, it just needs a bit more time to get there.

I don't think zig is very well suited for / should target web dev. There a GC'd language with modern features should do best. Imagine OCaml but modern and great tooling. That would be easy for developers, more productive to write, less type errors, also more productive because of IDE support, and much faster than current crop of scripting languages. Sadly, there is a vacuum for such a language. Go is too gruntwork an…

Julia is a good language - has excellent performance and it has a pretty decent web development framework as well.

https://genieframework.com/

Re: Zig's New Relationship with LLVM

#113

Post by dnautics »

tom_mellior wrote: post #93
ikskuh wrote: post #12

Earlier quoted context omitted.

Yes, you understood that right. The existing executable file is not written completly anew. And yes, it will be faster. The way Zig does this is by only recompiling and modifying the parts of the executable where the source has changed. Imagine a project like chromium, where your executable is 150 MB large. Now you change a single function. Classic linking would require the whole linking process and the write of 150…

> Now you change a single function. Classic linking would require the whole linking process and the write of 150 MB of code. Zig will only compile and patch a single function (when lucky: less than 1kB) and emit this. I see, thanks. I think I was misled by the article's "the final executable depends on everything else and so any meaningful change to the code will invalidate it". My understanding now is that, since th…

> the final executable depends on everything else and so any meaningful change to the code will invalidate it

If I'm not mistaken that refers to in traditional compiled languages.

Re: Zig's New Relationship with LLVM

#114

Post by _urga »

sam0x17 wrote: post #27
johnnycerberus wrote: post #24

Earlier quoted context omitted.

While I like what Rust is trying to achieve, I would never use something that is not formally proven. There are many, many other static analysis tools in the C and Ada world that can achieve exactly the same thing. They imply less risk, they are way more mature (~40 yo) and have bigger communities around them. Zig is a better C and C++. It should be used accordingly. It will do well in game servers, simulation server…

Agreed that Rust has a bit of an odd fit -- it is in many ways a bit too onerous for day-to-day things like CRMs and web dev, but for the real scenarios where you want formal verification, you can of course also use actual formal methods and get a much higher degree of certainty perhaps. It is well suited for OS and driver dev though, which is arguably the target use case.

"It is well suited for OS and driver dev though"

Rust is brilliant, but for drivers, I would go for a language with OOM safety and strict static allocation, especially for embedded environments.

Re: Zig's New Relationship with LLVM

#115

Post by ec109685 »

benesch wrote: post #59
zokier wrote: post #45

Earlier quoted context omitted.

This might be stupid question but would it make sense to forgoe linking a monolithic binary altogether and just load the different bits dynamically at startup from various object files or something like that? On the other hand your way of thinking sounds a lot like what I understand Smalltalk image format to be like

That's not a stupid question. That's extremely insightful! That is exactly my model of the world, in fact. When linking incrementally, you don't want a tightly packed object file where the functions are stacked right on top of one another. You want something more akin to a key–value database, where you can swap out key–value pairs without corrupting the entire file. Whether that's an object file that "symlinks" a bun…

Is there a point where instead of allowing your single binary to grow indefinitely (to your point about application growth eating up any linker performance benefits), you modularize it into shared libraries that can be independently linked?

Re: Zig's New Relationship with LLVM

#116

Post by pron »

the_duke wrote: post #108
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…

> 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 languages that aren't C -- like C++, Rust, and Ada -- not only is it not among the most complex languages in the history of software (all three of those have probably secured their places in the top-five), but it is probably among the simplest.

> I'm not aware of any features that would amount to a "radical breakthrough". As far as I am aware, it is a modernized C, with nice compile time evaluation, async, and some runtime-provided safety guarantees. But nothing that is novel from a type system / language design point of view.

AFAIK, general partial evaluation with introspection as a single mechanism to do the work of generics, typeclasses/traits/concepts, value templates, macros, and conditional compilation -- combined with a general error reporting mechanism that is shared between runtime and compile-time -- has never been attempted before. It is revolutionary.

Re: Zig's New Relationship with LLVM

#117

Post by zokier »

benesch wrote: post #59
zokier wrote: post #45

Earlier quoted context omitted.

This might be stupid question but would it make sense to forgoe linking a monolithic binary altogether and just load the different bits dynamically at startup from various object files or something like that? On the other hand your way of thinking sounds a lot like what I understand Smalltalk image format to be like

That's not a stupid question. That's extremely insightful! That is exactly my model of the world, in fact. When linking incrementally, you don't want a tightly packed object file where the functions are stacked right on top of one another. You want something more akin to a key–value database, where you can swap out key–value pairs without corrupting the entire file. Whether that's an object file that "symlinks" a bun…

> You want something more akin to a key–value database, where you can swap out key–value pairs without corrupting the entire file

That is kinda my point, we already have one perfectly good kv-database in the form of filesystem, so why not use that

Re: Zig's New Relationship with LLVM

#118

Post by dnautics »

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!

I thing zig ships with the relevant prebuilt llvm if you don't mind being tied to a release.

Re: Zig's New Relationship with LLVM

#119

Post by evmar »

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:

http://neugierig.org/software/blog/2012/07/gyp-toc.html

Re: Zig's New Relationship with LLVM

#120

Post by [deleted] »

nyanpasu64 wrote: post #98
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…

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

[deleted]
Post reply on HN