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

131–140 of 295 posts

Re: Zig's New Relationship with LLVM

#131

Post by jimbob45 »

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.

Re: Zig's New Relationship with LLVM

#133

Post by sai_c »

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://ziglang.org/#Small-simple-language): "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. There's always "this little feature" necessary, or "this cruft to clean up". You name it i've seen it.

If you want people like me (and trust me HN community, there's a GIANT silent majority out there) to use Zig e.a. for production in the embedded and systems space where product lifecycles are counted in decades, you will have to provide this feature. Sure, you can call me a dinosaur (still under 40 :-)), or a BLUB programmer or what not. But language designers wanting to (slowly) put C to rest, should, imho, not forget about this "feature".

In this space you really want to focus on the real problems, not on problems of keeping up with the latest and greatest.

Side note for all the "if all you know is a hammer" responses: Please don't compare programming languages with tools. This is a bad analogy. Programming languages are more like materials. Once chosen and the product (the source code) built, you cannot simply change it without starting from scratch and a new product (new source code).

So, downvotes, here i come ;-).

Re: Zig's New Relationship with LLVM

#134

Post by _urga »

benesch wrote: post #100
_urga wrote: post #90

Earlier quoted context omitted.

I'm with you on the mental model, but from a hardware point of view what you also don't want is hundreds of random disk seeks. I know we're almost in an SSD-only world but HDDs are still a thing and large sequential reads are always important at any level of the memory hierarchy.

I wouldn't expect that to matter much during the debug cycle. The whole binary is going to be sitting in the buffer cache.

Sure, but the buffer cache is also part of the memory hierarchy. At every level, it's always good not to go wild with cache misses. Not that that's what you're proposing of course.

Re: Zig's New Relationship with LLVM

#135

Post by throwaway17_17 »

pjmlp wrote: post #99
skohan wrote: post #71

Earlier quoted context omitted.

> There a GC'd language with modern features should do best. I predict that there will be a paradigm shift away from GC in the next round of languages. I suspect what will win for something like web-dev will be a language with static memory management like Rust, but at a higher level, with slightly more tolerance for abstractions of non-zero cost.

I predict that GC languages will prevail and adopt affine types for advanced users to code application hot paths, like D, Swift, Chapel among others are pursuing.

I think this is in general the right call, but I would prefer seeing the adoption of a more general substructural type system implementation and the inclusion of uniqueness types. It would not add that much complexity when the use case is specifically limited to advanced users and the obvious trade offs in syntax increase and annotations are limited to those that want/need it.

Re: Zig's New Relationship with LLVM

#136

Post by CyberDildonics »

ikskuh wrote: post #110
CyberDildonics wrote: post #102

Earlier quoted context omitted.

Zig purposely does not parse carriage returns or tabs. When this is brought up, people tell you to use a separate program to format it before compiling and don't seem to acknowledge that this is not a problem with any other language. The result is that by default you get errors on windows with hello world programs. People will tell you to just change your defaults in your text editor to not write carriage returns. Th…

> When this is brought up, people [...] don't seem to acknowledge that this is not a problem with any other language. This was a deliberate design decision by andrew for all zig pre-1.0 to supress discussions about coding style (use CR, LF, CRLF, LFCR as a line ending? tabs vs. spaces? ...) as it's considered bike shedding Zig 1.0 won't have this restrictions anymore. More information can be found here: https://githu…

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

Re: Zig's New Relationship with LLVM

#137

Post by the_duke »

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…

> I'm not sure I like the "better C" label.

I agree that Zig is more than a "better C", and I edited my comment.

Regarding `comptime`: I haven't fully grokked it, but it looks very similar to the capabilities of D (and in part Nim). Do you by chance know those languages and can give a comparison?

(Languages like Idris also allow to express a lot at compile time, but that's quite a different domain)

Re: Zig's New Relationship with LLVM

#138

Post by pron »

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

> I'm not sure I like the "better C" label. I agree that Zig is more than a "better C", and I edited my comment. Regarding `comptime`: I haven't fully grokked it, but it looks very similar to the capabilities of D (and in part Nim). Do you by chance know those languages and can give a comparison? (Languages like Idris also allow to express a lot at compile time, but that's quite a different domain)

Nim and D have a similar feature, but Zig's radical design is not in including this feature but in not including others it can replace (generics and macros). Both D and Nim have generics as a separate features, and Nim has macros and D has conditional compilation as a separate features. Zig is not special in having comptime; it's special in having only comptime as the single partial-evaluation mechanism.

Re: Zig's New Relationship with LLVM

#139

Post by tayistay »

pron wrote: post #58
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.

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.

Re: Zig's New Relationship with LLVM

#140

Post by pron »

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.

comptime combined with introspection gives you something similar to generics and typeclasses.
Post reply on HN