Hacker News Reader

Comment by seg_lol | Hacker News Reader

What specifically, that they mention Zig or that you learned of Zig or that Zig has a lazy build system or ???

The thing I really find interesting about Zig is the compile time function evaluation [1] and how it can stand-in for macros, code generation, precomputing values, etc. I think of CTFE as a continuation that comes baked into the binary from an earlier point in time, T-days_ago.

As for this release, I am stoked to see Flang making progress. I am excited about Fortran in the browser.

The interesting thing of note is that Zig is in the process of creating their own backend, but I don't see them dropping LLVM any time soon. An alternate backend is a great way to find bugs in codegen.

[1] https://andrewkelley.me/post/zig-programming-language-blurs-...

View on HN

Zig's comptime is surprisingly powerful and does not suffer C++ template problem when an error message at the instantiation site is extremely unhelpful. And Zig managed it without constrains or traits just via bunch of useful compile-time operations on types. Still I do not see how one can have, for example, a struct field or enum case available only at certain compile-time condition like OS version.

You can put together an `std.builtin.TypeInfo` structure describing the type (eg. by using `@typeInfo` on an existing type and editing the result, adding something under `.Struct.fields`); then use `@Type` to 'unreflect' it back into a real type.

Splendid! This is much more flexible than various static if aproaches like in D or modern C++.

Zig's home-grown backend is strictly for super-quick turnaround compile and link during development. For optimized release builds, they'll depend on LLVM forever.

I think that is a lovely solution for a couple reasons. First it allows the project to optimize for its goals (dev latency), this allows the team to have more local control and autonomy.

Second, it puts _less_ pressure on LLVM to have both a low latency version and a highly optimized version. If the LLVM IR could be more of a common format, I think it would provide a medium for tools to compose better. Eventually we will get there, compiler gods willing. I think LLVM should be the place for the massive-engineering-effort optimization passes.

Lastly, it provides for differential testing of both backends, this makes Zig's homegrown one AND LLVM better.

Thanks for sponsoring Zig!

Random question, but you’re the first commenter who mentioned flang, so I am hoping you know the answer: is Flang doing its own alias management to enable Fortran’s optimizations on arrays, or did LLVM finally regain usable alias attributes in the backend?

Perf isn't a high priority for me, more about getting Fortran into the browser. I don't have insights into the aliasing.

That’s interesting. Is it personal familiarity with the language that drives your desire or is some features of the language that you find lacking in alternative languages already in the browser space?

Another option may be wanting to port existing Fortran libraries to web.

I'm probably biased but comptime doesn't seem as elegant as the mechanism D provides for doing CTFE (i.e. I prefer a separation of quasi-template parameters)

Can you eg. generate a struct with fields based on an existing struct or on a comptime array in D? Can you receive a structure literal of anonymous type and iterate over it at compile time? (curious bc. these were a few things I found straightforward in Zig, and in C++ the main proposals involve tons of new metaclasses and reflection features for)

Yes to all points.

D doesn't go the C++ route, the way code like this works is via generating new code (in text) at compile time which the compiler then compiles (duh) and replaces the mixin statement within.

Here's an annotated example of these features in use

https://run.dlang.io/is/2b5zgC

Brilliant.

That is beautiful. I wish C++ had something like that... Perhaps in addition to its current template system. Having a separate build pass to generate files is annoying.

It does, via constexpr, which just got more expressive in C++20, and is the basis for the ongoing compile time reflection work on C++23.

Code injection might eventually come later via Microsoft's ongoing research in C++ metaclasses.

"Dynamic Polymorphism with Metaclasses and Code Injection"

https://www.youtube.com/watch?v=8c6BAQcYF_E

That looks a lot more complicated than D's simple "output text that gets fed back into the compiler". But admittedly I only quickly jumped around the video. Hopefully it works well, though.

True, but a programming language is more than just syntax and for better or worse, the ecosystem is what matters.

That's what I meant by doesn't go the C++ way. The standards committee over complicate everything (concepts still haven't landed yet for example, D has D a better more flexible system 15 years ago I think)

And no ecosystem to speak off, while that standards committee is making sure that GPGPU programming is the next killer application for C++.

How are modules coming along then?

C++ has succeeded despite the committee not because of it.

Already available as experimental on VC++, and approved as part of C++20.

As proven by every failed attempt to replace languages with industry standards, plenty of companies do care about ISO and ECMA language standards.

D is a nice language, but spends too much time focusing on the language and its cool metaprograming capabilities, without focus on the ecosystem.

Slowly Java, C#, C++ will have the features that made D unique, with the plus side of 20 - 40 years of libraries, IDE support and industry certifications.

Cool! Nim is related here, where instead of text manipulation you're doing AST manipulation with quasi-quoting (like in many lisps), eg. https://nim-lang.org/docs/tut3.html#introduction-building-yo....

While I agree that D is a 'treasure' (full of good ideas that should be copied more often by other languages) I don't understand why you think that D's way is better than Zig here.. What exactly do you prefer?

It's personal preference, but if a parameter is well and truly compile time I think it should be separate from the others (it certainly makes introspection "easier")

Aside, there no reason that this comment should be downvoted.

Reply on news.ycombinator.com