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

191–200 of 295 posts

Re: Zig's New Relationship with LLVM

#191

Post by theresistor »

nick_ wrote: post #76
alexnask wrote: post #51

Earlier quoted context omitted.

While I am not terribly familiar with the LLVM codebase, this kind of improvement would probably require massive internal changes. One example of this is the fact that codegen needs to be aware of the linker to emit correct code depending on the type of executable that is being generated, since different strategies can and are used for different formats (for example, currently the x86_64 backend will generate differe…

Very interesting. It makes a lot of sense. Do you have a read on how well using the LLVM interpreter modes fill this gap? EDIT: To be clear, I mean the gap of slow build performance in the feedback look of code-build-check.

LLVM's interpreter is atrociously slow. It's only really meant for debugging LLVM itself.

Re: Zig's New Relationship with LLVM

#192

Post by AnIdiotOnTheNet »

pjmlp wrote: post #9
IshKebab wrote: post #2

This looks amazing, as do many of Zig's features (e.g. comptime). It's hard to go back to memory errors after Rust, but I hope Zig becomes popular enough with some people (those that don't care about security? maybe game developers?) that it influences future languages.

Unless we get "Unreal/Unity for Zig" not really.

While many developers do use these kinds of pre-built all-in-one game engines for various reasons (and that's great because it means more people can make games without the work of building an engine), there are still many many game developers who write their own "engine" for a wide variety of reasons.

Re: Zig's New Relationship with LLVM

#193

Post by agentultra »

ifreund wrote: post #165
agentultra wrote: post #144

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…

Compile times of the stage1 zig compiler may seem fast compared to e.g. rust or C++ but they are slow compared to what the WIP stage2 compiler can do :)

I can't complain as I mostly write Haskell these days and trade off compile time for other things.

That sounds excellent though, I'll check it out when it lands.

Re: Zig's New Relationship with LLVM

#195

Post by int_19h »

pjmlp wrote: post #164
alexhutcheson wrote: post #159

Earlier quoted context omitted.

The low cost of porting a C toolchain to a new platform is a feature of C. Arguably, it's one of C's two remaining "killer apps" that keep it in use. The other is that C is the "universal recipient" language for FFI - it's easy to call C functions from almost any other language (but not vice-versa). It's currently much more expensive to port an Ada, Rust, or even C++ toolchain to a new platform, so I'd expect C to co…

The universal recipient for FFI is mostly a thing in UNIX like OSes, not so much on others.

It's similarly true on Windows - not everything supports COM.

Re: Zig's New Relationship with LLVM

#197

Post by adenozine »

When zig can handle line endings from this century, maybe.

It's kinda crazy there's software that bothers the user to restrict CRLF. I tried zig and this was the first issue. I thought I needed to go find my AOL discs or something.

Re: Zig's New Relationship with LLVM

#198

Post by oh_sigh »

gravitas wrote: post #32

I see zig users commenting here -- the "getting started" guide at https://ziglearn.org/ immediately fails with the installable zig binary from Arch (0.6.0) due to https://github.com/ziglang/zig/issues/5683 I'd never heard of zig until now, but as a community having top level "how to get started" website using features only available from the Master branch of github is... not a good way to get people into your languag…

I don't know how repl.it chooses the languages it supports, but it would be great if zig could get on that so there could be a zero-download way to get started in the language.

Re: Zig's New Relationship with LLVM

#199

Post by jhoechtl »

Zig is the legit successor to C++ , not Rust.

In a sense that it will feed your family and get you a job in the future.

Sure, Rust is even smarter and a savy Rust hacker is likely to run circles around the herds of mediocre Zig hackers.

But Zig hackers will come in legions while Rust hackers will die in beauty.

Re: Zig's New Relationship with LLVM

#200

Post by elcritch »

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…

This new announcement for Zig makes it seems like in the future it might be independent of LLVM... Maybe it could support C compilation back-end one day. But for now it's pretty much LLVM based languages, or C.

Alas... not to mention debugging tools, etc. That's why I've gone down the Nim path at work as well, and it's actually pretty fun once you get the basics. Having JSON support in a few kB's of flash is nice. I've ported enough of the Nim standard library to FreeRTOS/LwIP to be able to use it with the ESP32! If you want to take a look and see how it integrates with FreeRTOS [1].

I'd recommend trying out Nim's new ARC garbage collector if you have more than a few dozen kB's of RAM. The ARC GC is pretty friendly to working with C based-boards as it can use the native malloc and any native debugger mechanisms. The references are non-locking to it's pretty low overhead, but if you do try it run `-d:nimArcDebug -d:traceArc` first to see the overhead. You can't use `async` without cycle collection (ORC) however.

Of course no-GC works too and you can annotate functions to guarantee no GC (I think). Just less fun if you have the RAM available.

1: https://github.com/elcritch/nesper (Warning: WIP)

Post reply on HN