Does anyone have any good examples of Zig being used as a build system for a large project? Coming from a Windows world when my gigantic C++ project is hidden inside a vcxproj I dont delve into that often, I tried to compile a standard autoconf based project into wasm the other week and eventually gave up. Use autoconf to create your cmake to create your make which builds your lib? and wrap all those calls with emscr…
File for divorce from LLVM
101–110 of 167 posts
Re: File for divorce from LLVM
#102Does anyone have any good examples of Zig being used as a build system for a large project? Coming from a Windows world when my gigantic C++ project is hidden inside a vcxproj I dont delve into that often, I tried to compile a standard autoconf based project into wasm the other week and eventually gave up. Use autoconf to create your cmake to create your make which builds your lib? and wrap all those calls with emscr…
Do any of these count? https://www.uber.com/blog/bootstrapping-ubers-infrastructure... https://github.com/tigerbeetledb/tigerbeetle/blob/main/build... https://github.com/oven-sh/bun/blob/main/build.zig
Yes! Thanks!
Re: File for divorce from LLVM
#103Earlier quoted context omitted.
Yes, that is how languages become a success on the market, either being pushed by the platform owner no matter what, or by having a framework written in them that everyone feels like using. Everything else are aspiring extras in the cinema of programing languages, waiting on the sidelines for that major role that will come someday, it really will, one just has to believe enough.
Counter-example: Kotlin.
How is that a counter example? Doesn’t Kotlin fulfil a similar role for Android?
Re: File for divorce from LLVM
#104I think they should keep LLVM as a fallback or as an optimizing backend.
This part is pretty solid, even if all the dependencies is hard to deal with, I am not convinced that building your own would lead to better results.
The most annoying part is the slow compilation in non-release, this can be fixed more easily with support for a minimal number of targets.
Re: File for divorce from LLVM
#105Earlier quoted context omitted.
Yes, that is how languages become a success on the market, either being pushed by the platform owner no matter what, or by having a framework written in them that everyone feels like using. Everything else are aspiring extras in the cinema of programing languages, waiting on the sidelines for that major role that will come someday, it really will, one just has to believe enough.
Counter-example: Kotlin.
That's not a counter example:
https://miro.medium.com/v2/resize:fit:720/format:webp/1*sojK...
Kotlin would be likely still nowhere without Google and Android.
Re: File for divorce from LLVM
#106Two issues here. The first is code generation and the other is bootstrapping. Ime, the optimizing passes of a compiler are easy and fun to write. You have to read research papers to understand how register allocation and ssa form works, but it's fun code to write. You just send the ir through various optimizing passes, each refining it in some way. You can write high-quality optimization passes without llvm. But then…
Zig already bootstraps from its C backend, so the second issue is not a problem.
Re: File for divorce from LLVM
#107Andrew is super sharp so I imagine he and the team will get there now that it's declared as a goal. But man, it seems to me (uneducated on the challenges zig faces w/LLVM) that this shifts the team's capacity away from zig and towards things like binutils. When I read the headline I assumed that they were throwing out the compiler (IIRC they had mostly/totally excised it already). But for a project like zig it just s…
There's a document that I think was an unofficial project management document from NASA, I can't find it now, but one of the items was something along the lines of 'if your space mission isn't reusing an existing launch vehicle, it will be a launch vehicle development project and everything else, including what you think is the focus of your mission, will be secondary to this'. Edit: additional bit I remembered, this…
Akin's Laws of Spacecraft Design
Re: File for divorce from LLVM
#108Earlier quoted context omitted.
Yes, that is how languages become a success on the market, either being pushed by the platform owner no matter what, or by having a framework written in them that everyone feels like using. Everything else are aspiring extras in the cinema of programing languages, waiting on the sidelines for that major role that will come someday, it really will, one just has to believe enough.
Counter-example: Kotlin.
Not at all, given the way Google is pushing it on Android, they are even mischievous enough to compare Kotlin with Java 6 when going on about why Kotlin.
For all practical purposes ART has turned into the Kotlin Virtual Machine.
However it so happens, that to keep the advantage of using Java libraries in the Android ecosystem, they actually need to support newer Java libraries unless they feel like rewriting all of them into Kotlin.
So Android 12 and 13 got a subset of Java 11 LTS, and Android 14 is getting Java 17 LTS support.
That doesn't change the reasoning that Android is all about Kotlin nowadays, unless one is writing platform code itself.
Re: File for divorce from LLVM
#109So I spent ~4 years writing all my embedded projects (and libraries) in Zig and now several "tier 1" supported arches are just going to be dropped? It's your language so do whatever you want but please adjust the branding accordingly...
Just wanted to point out that this is just a proposal, so if enough people voice their opinion, which many have already done, I am sure the core team will adjust their approach.
Re: File for divorce from LLVM
#110Some of this reasoning is just wild. 1. "We can attract direct contributions from Intel, ARM, RISC-V chip manufacturers, etc., who have a vested interest in making our machine code better on their CPUs." They are nowhere near popular enough (or used enough by some particularly important customer) for any major architecture vendor to spend any time contributing except as someone's random side project. To think otherwi…
I agree that it's probably impossible to write something that is orders of magnitude faster than LLVM and better than LLVM at optimizing, but I don't see that claim in the original text. It seems like a lot of work but also doable to create something that is orders of magnitude faster than LLVM for unoptimized debug builds. Furthermore, the Zig compiler might be an easier thing to work with than LLVM/Clang for doing…
Sure, the latter is possible.
I read the claims and comments differently than you, fwiw. It definitely reads like people who think they can make it both faster and better.