It is difficult for me to imagine Zig succeeding without a similar capability - which is to say I hope they do not follow through on this milestone.
In zig you _can_ actually start with a c codebase and rewrite it file by file in zig and you _can_ include c headers in your zig files verbatim. Both of these are not possible in rust.
This milestone is only gonna remove the c++ (and objective c/c++) compiler for now from zig cc. So while you could argue this will ostracize people rewriting their c++ codebases in zig, I don't imagine there's actually many people like that. EDIT: I just looked at the discussion and there's actually a lot of people that use the c++ capapbilities.
well, you can: i have done this, with Rust. but yes, it’s more the type of thing that well-resourced companies do rather than solo devs, because even with Bindgen and the like Rust really wants the atomic codegen unit to be the “library”, not C’s notion of a “compilation unit”. still, C FFI compatibility is exactly why porting from C to rust incrementally is feasible while C to, say Java, is probably a bigger leap.
In Zig that all "just works" with the standard Zig install.
https://github.com/floooh/sokol
...inspired by:
https://github.com/nothings/stb
(here's how the sokol headers are integrated into a Zig project, note that there is only a build.zig which builds everything: https://github.com/floooh/kc85.zig)
But it's not so much about build systems, but requiring a separate compiler toolchain to build any C++ or ObjC dependencies (Rust needs this, Zig currently does not - unless that controversial proposal is implemented).
(also even complex C++ libraries can be wrapped in a build.zig, so you don't require a separate build system like cmake for the C++ dependencies)
Similarly I don't really understand why you want one toolchain for a multi-language project. It's not that useful or convenient since it's going to need to be orchestrated with a buildsystem somehow.
Like with Rust, you probably only have a build.rs file. It invokes a separate (possibly multiple) toolchains. Or with CMake. A simple project has a single CMakeLists.txt that can invoke any number of toolchains. I don't see why zig can't do that with a build.zig file, or why it matters.
(also it's a myth that STB style libs increase compile time, that's only true for typical C++ single header libs with inline methods and template code)
> In zig you _can_ actually start with a c codebase and rewrite it file by file in zig and you _can_ include c headers in your zig files verbatim. Both of these are not possible in rust.
You can. Either via FFI and bindgen-ing headers, or by using c2rust. The latter is not just a toy ambitious project, but actually a very impressive piece of engineering and does produce a result where you can transpile a project or file and start rewriting file-by-file or function-by-function.
It also doesn't supportal a good amount of more complicated c features.
It's a help for sure, but the few times I tried I ended up just doing the rewrite by hand instead to actually cover all the cases.
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.
Additionally JetBrains has their fingers all over the place in Android.
Kotlin, Android Studio a mix of InteliJ and Clion, Compose,...
https://miro.medium.com/v2/resize:fit:720/format:webp/1*sojK...
Kotlin would be likely still nowhere without Google and Android.
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.
Google is in bed with JetBrains in what concerns Android.
A big difference is there was an element of no choice to LLVM, at least in Apple’s takeover of the project: GCC didn’t want to allow / do what Apple wanted / needed out of it.
Edit: additional bit I remembered, this statement is prefixed with something like 'you may start thinking you project will be cheaper/more efficient if you develop a launch vehicle suited to your particular mission instead of compromising on an existing one, but', then the above.
39. Any exploration program which "just happens" to include a new launch vehicle is, de facto, a launch vehicle program.
No. It's an unaccepted proposal.
I think it's same to assume it's an official goal, now.
https://github.com/ziglang/zig/issues?q=is%3Aissue+label%3Ap...
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 seems like there's a lot to be gained from keeping it.
That said -- the prospect of rewriting a lot of the stuff that's in the LLVM project now in zig instead of c++ - that's pretty cool and ambitious. Just as ambitious as it was for Lattner to create LLVM, I suppose.
But code that's accidentally quadratic - well, that's bound to happen to zig too, if it's as popular and useful as LLVM project is.