15 ms·

I read https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/ but I’m still not clear on the endgame for this language. Is

I read https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/ but I’m still not clear on the endgame for this language. Is the plan to kill both Rust and Go?

rgrmrts 2y ago
No, the plan is to build a simple general purpose language. Lots of folks already enjoy using Zig, and not every language has to be in direct competition with others.
kristoff_it 2y ago
We don't have VC money so the only endgame is to gift Zig to people who happen to find it an effective tool, so that they can make more software you can love.
AndyKelley 2y ago
Endgame: After creating a language that encourages programmers to make robust and optimal software, using a toolchain that exemplifies these ideals by providing an order of magnitude faster development iteration speed, point this energy towards the ecosystem, with a focus on our core principle of prioritizing the needs of end users. Building upon this rich ecosystem of high quality software, create and maintain free, libre, and open-source applications that outcompete proprietary versions. I want to see the next Blender, the next Postgresql, the next Linux. This is my vision. Mitchell's Ghostty project is a perfect example of this movement. At least, it will be when it is open sourced.
- rc00 2y ago
  > I want to see the next Blender, the next Postgresql, the next Linux. This is my vision. Do you think it makes sense to augment these existing (and successful) open source projects with Zig (language and/or toolchain)? Or should something grassroots and written primarily in Zig be their eventual successor?
  - AndyKelley 2y ago
    Now that you mention it I forgot an important one! I want to see the next VLC. And in fact J-B has mentioned on IRC that he would be interested to see contributions to the project using Zig.
  - zdragnar 2y ago
    Why contribute to a monopoly when you can lay the foundation for greener grass for more competitors? There's arguments both ways; what it really boils down to is what you value.
  - samatman 2y ago
    This is one of the shining features of the language: either of these is a viable option. Zig is a great way to build C projects, with native cross-compiling, and the semantics make it straightforward to supply a C API for Zig libraries to add to existing code in C. Depending on the specifics, it can make sense for a C codebase to switch to Zig's build system just for excellent cross compilation, without writing anything in Zig. I think once Zig stops being a moving target, we'll see an increasing number of C codebases writing some of the new code in Zig, moving over to the build system, and taking it from there. There are a lot of decisions which make this easy. As an example, idiomatic Zig code which allocates memory receives an Allocator, where C uses malloc and free. So there's a C allocator, which provides the Allocator interface to malloc and free, meaning Zig code can create objects and pass the memory to C, which can free it later. There's a lot of C code out there which is working just fine, and if it ain't broke, no need to fix it. But if it's easy to do new work in a nicer language (to my taste, Zig is definitely that), why not? Then maybe rewrite some preprocessor-heavy C code using comptime. The main thing holding this back (though it's already happening) is that Zig is pre-1.0. That imposes a maintenance burden which not everyone is willing to take on. But that won't last forever.
  - geon 2y ago
    I interpreted it as examples of excellent open source software that Andy wants to see more of. Not that those projects should be replaced. Specifically, those are applications that are arguably better than their proprietary alternatives. Perhaps we can se a * DAW * Photoshop alternative (no, gimp was never it) * Video editor
- zozbot234 2y ago
  > ... I want to see the next Blender, the next Postgresql, the next Linux. This is my vision. That's a really nice thought. Maybe instead of "Move fast and break things" we can have "Move Zig for great justice."
  - rc00 2y ago
    I much prefer the pattern I've noticed with the recent generation of Go projects. What I mean is that I find myself more and more often going to a project's repository to check for an issue or open a pull request, only to find that it is written in Go. After the initial hype cycle, Go silently started being the engine many useful tools were written in. While I understand that Zig needs to have some level of getting the word out early on, ultimately having great projects arrive that are written in Zig (that don't need a "written in Zig" tag line as a sort of marketing gimmick) would be the best statement. This pattern I've observed with Go holds true for projects written in TypeScript, Python, and even C as well but Go is the more recent entry. Effectively, less focus on slogans and more on great projects that solve actual problems. Sometimes moving in silence can speak volumes. (In chess, there's a saying: "Move in silence. Only speak when it's time to say, 'Checkmate.'") But your sentiment was great! :D
    - pjmlp 2y ago
      I rather love three specific projects that are rather vocal about Go actually. TamaGo, TinyGo and the Go compiler toolchain itself. As they are all good examples regarding Go's suitability for systems programming, regardless of the usual discussion of what is systems programming about.
      - rc00 2y ago
        These are great but none of them would be considered "recent generation" for this scope and it actually highlights the point rather well. Those projects started before this resurgence in Go and the first two are likely branding artifacts of the Go vs Rust period that the open source software engineering field was in at the time. A good example of what I mean is a project like Ollama. If you look at the repository's main page, the only hints that it is written in Go are in the file tree, the GitHub language graph, and the topic labels. This is a project that was started in 2023 and exemplifies the lack of necessity to brand the project with "written in Go" likely because Go has really taken hold in CLI application development. (This could have easily been called Gollama. :D)
skywhopper 2y ago
Why would it need to kill anything? It’s enough to be useful, imo.
- infamouscow 2y ago
  [flagged]
  - Ar-Curunir 2y ago
    Yes, Rust which is under consideration as the first ever non-C language in the kernel, has very little real-world respect. JFC, I can get that sometimes Rust folks can be obnoxious and overbearing, but IME it's the "never-rust" crowd that are more obnoxious.
    - randomdata 2y ago
      To be fair, he said the Rust community has little real-world respect. Linux considering the inclusion of Rust on technical merit is unrelated to the bunch of yahoos who have made a certain technology their identity.
      - infamouscow 2y ago
        You've precisely pinpointed the nuance that seems to elude so many: the distinction between the technical merits of Rust and the often overzealous antics of its most ardent adherents. It's amusing how some conflate corporate adoption with universal admiration for a community's demeanor. Perhaps if more could separate the tool from its torchbearers, we'd have fewer misguided defenses and more meaningful discourse.
      - Ar-Curunir 2y ago
        I have a hard time believing that as well. What is the definition of community? Is it the RIIR fanboys? Is it /r/rust? Is it users.rust-lang.org? Each of these subcommunities is quite sizable, and the last two definitely make an effort to squash RIIR-type overzealotry. If you're still going to define the Rust community by the latter, it would be fair game to define the C/C++ community by the very vocal people who insist that there's nothing wrong with the lack of memory-safety in those languages.
ksec 2y ago
I don't remember Java ever had an endgame during the late 90s or early 00s. There were certainly a lot of ambitious. But on the whole we know or assumed about its ( JVM ) limitations. There were also languages before or in between. But I dont record any one of them ever had an End Game plan. This phenomenon is entirely new and doesn't exist until certain language's supporter came out. And it has now somewhat popularised by it.
lenkite 2y ago
I think Zig is definitely an alternative for programmers who are too dumb to grok idiomatic Rust - sadly I am one of them. Go is more meant for middleware and services programming and is a simple, consistent language that won't go away as it has now been enterprise adopted.
zozbot234 2y ago
I just asked my local AI chatbot, and they said that this is the endgame for Zig: Congratulation !! A.D.2111 All bases of Rust were destroyed. It seems to be peaceful. But it is incorrect. Rust is still alive. Zig must fight against Rust again And down with them completely! Good luck.

I read https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/ but I’m still not clear on the endgame for this language. Is the plan to kill both Rust and Go?

rgrmrts 2y ago

No, the plan is to build a simple general purpose language. Lots of folks already enjoy using Zig, and not every language has to be in direct competition with others.

kristoff_it 2y ago

We don't have VC money so the only endgame is to gift Zig to people who happen to find it an effective tool, so that they can make more software you can love.

AndyKelley 2y ago

Endgame: After creating a language that encourages programmers to make robust and optimal software, using a toolchain that exemplifies these ideals by providing an order of magnitude faster development iteration speed, point this energy towards the ecosystem, with a focus on our core principle of prioritizing the needs of end users. Building upon this rich ecosystem of high quality software, create and maintain free, libre, and open-source applications that outcompete proprietary versions. I want to see the next Blender, the next Postgresql, the next Linux. This is my vision. Mitchell's Ghostty project is a perfect example of this movement. At least, it will be when it is open sourced.

rc00 2y ago
> I want to see the next Blender, the next Postgresql, the next Linux. This is my vision. Do you think it makes sense to augment these existing (and successful) open source projects with Zig (language and/or toolchain)? Or should something grassroots and written primarily in Zig be their eventual successor?
- AndyKelley 2y ago
  Now that you mention it I forgot an important one! I want to see the next VLC. And in fact J-B has mentioned on IRC that he would be interested to see contributions to the project using Zig.
- zdragnar 2y ago
  Why contribute to a monopoly when you can lay the foundation for greener grass for more competitors? There's arguments both ways; what it really boils down to is what you value.
- samatman 2y ago
  This is one of the shining features of the language: either of these is a viable option. Zig is a great way to build C projects, with native cross-compiling, and the semantics make it straightforward to supply a C API for Zig libraries to add to existing code in C. Depending on the specifics, it can make sense for a C codebase to switch to Zig's build system just for excellent cross compilation, without writing anything in Zig. I think once Zig stops being a moving target, we'll see an increasing number of C codebases writing some of the new code in Zig, moving over to the build system, and taking it from there. There are a lot of decisions which make this easy. As an example, idiomatic Zig code which allocates memory receives an Allocator, where C uses malloc and free. So there's a C allocator, which provides the Allocator interface to malloc and free, meaning Zig code can create objects and pass the memory to C, which can free it later. There's a lot of C code out there which is working just fine, and if it ain't broke, no need to fix it. But if it's easy to do new work in a nicer language (to my taste, Zig is definitely that), why not? Then maybe rewrite some preprocessor-heavy C code using comptime. The main thing holding this back (though it's already happening) is that Zig is pre-1.0. That imposes a maintenance burden which not everyone is willing to take on. But that won't last forever.
- geon 2y ago
  I interpreted it as examples of excellent open source software that Andy wants to see more of. Not that those projects should be replaced. Specifically, those are applications that are arguably better than their proprietary alternatives. Perhaps we can se a * DAW * Photoshop alternative (no, gimp was never it) * Video editor
zozbot234 2y ago
> ... I want to see the next Blender, the next Postgresql, the next Linux. This is my vision. That's a really nice thought. Maybe instead of "Move fast and break things" we can have "Move Zig for great justice."
- rc00 2y ago
  I much prefer the pattern I've noticed with the recent generation of Go projects. What I mean is that I find myself more and more often going to a project's repository to check for an issue or open a pull request, only to find that it is written in Go. After the initial hype cycle, Go silently started being the engine many useful tools were written in. While I understand that Zig needs to have some level of getting the word out early on, ultimately having great projects arrive that are written in Zig (that don't need a "written in Zig" tag line as a sort of marketing gimmick) would be the best statement. This pattern I've observed with Go holds true for projects written in TypeScript, Python, and even C as well but Go is the more recent entry. Effectively, less focus on slogans and more on great projects that solve actual problems. Sometimes moving in silence can speak volumes. (In chess, there's a saying: "Move in silence. Only speak when it's time to say, 'Checkmate.'") But your sentiment was great! :D
  - pjmlp 2y ago
    I rather love three specific projects that are rather vocal about Go actually. TamaGo, TinyGo and the Go compiler toolchain itself. As they are all good examples regarding Go's suitability for systems programming, regardless of the usual discussion of what is systems programming about.
    - rc00 2y ago
      These are great but none of them would be considered "recent generation" for this scope and it actually highlights the point rather well. Those projects started before this resurgence in Go and the first two are likely branding artifacts of the Go vs Rust period that the open source software engineering field was in at the time. A good example of what I mean is a project like Ollama. If you look at the repository's main page, the only hints that it is written in Go are in the file tree, the GitHub language graph, and the topic labels. This is a project that was started in 2023 and exemplifies the lack of necessity to brand the project with "written in Go" likely because Go has really taken hold in CLI application development. (This could have easily been called Gollama. :D)

skywhopper 2y ago

Why would it need to kill anything? It’s enough to be useful, imo.

infamouscow 2y ago
[flagged]
- Ar-Curunir 2y ago
  Yes, Rust which is under consideration as the first ever non-C language in the kernel, has very little real-world respect. JFC, I can get that sometimes Rust folks can be obnoxious and overbearing, but IME it's the "never-rust" crowd that are more obnoxious.
  - randomdata 2y ago
    To be fair, he said the Rust community has little real-world respect. Linux considering the inclusion of Rust on technical merit is unrelated to the bunch of yahoos who have made a certain technology their identity.
    - infamouscow 2y ago
      You've precisely pinpointed the nuance that seems to elude so many: the distinction between the technical merits of Rust and the often overzealous antics of its most ardent adherents. It's amusing how some conflate corporate adoption with universal admiration for a community's demeanor. Perhaps if more could separate the tool from its torchbearers, we'd have fewer misguided defenses and more meaningful discourse.
    - Ar-Curunir 2y ago
      I have a hard time believing that as well. What is the definition of community? Is it the RIIR fanboys? Is it /r/rust? Is it users.rust-lang.org? Each of these subcommunities is quite sizable, and the last two definitely make an effort to squash RIIR-type overzealotry. If you're still going to define the Rust community by the latter, it would be fair game to define the C/C++ community by the very vocal people who insist that there's nothing wrong with the lack of memory-safety in those languages.

ksec 2y ago

I don't remember Java ever had an endgame during the late 90s or early 00s. There were certainly a lot of ambitious. But on the whole we know or assumed about its ( JVM ) limitations. There were also languages before or in between. But I dont record any one of them ever had an End Game plan. This phenomenon is entirely new and doesn't exist until certain language's supporter came out. And it has now somewhat popularised by it.

lenkite 2y ago

I think Zig is definitely an alternative for programmers who are too dumb to grok idiomatic Rust - sadly I am one of them. Go is more meant for middleware and services programming and is a simple, consistent language that won't go away as it has now been enterprise adopted.

zozbot234 2y ago

I just asked my local AI chatbot, and they said that this is the endgame for Zig: Congratulation !! A.D.2111 All bases of Rust were destroyed. It seems to be peaceful. But it is incorrect. Rust is still alive. Zig must fight against Rust again And down with them completely! Good luck.