I like Zig, lots of great features that work in unison. However the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to. I think it will be a mainstream language though and gain a lot more traction after v1. There is also the issue of will people actually code by then.
I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around).
Rust will also never replace C or C++ in any meaningful way, at best new code gets written in new languages (and Rust being only one among many, and among languages used for new projects will also be C and C++, just maybe not that often).
I think the era of 'pop star languages' is over, the programming language future is highly diverse (and that's a good thing).
C? Never. I feel like that ship has sailed, it's too primordial and tied to too many system ABI's to ever truly go away. I think we'll see a lot of Rust or Zig replacing certain popular C programs and libraries, but I don't think C will ever go away.
C++ on the other hand? Possibly, though I think that it's just as much because of the own-goals of the C++ standards committee as it is the successes of Rust. I don't really consider Zig a competitor in this space because if you're reaching for C++, you are reaching for a level of abstraction that Zig is unwilling to provide.
> I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around).
This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.
> This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.
This is a painfully shallow framing.
Yes, programming languages solve problems by emitting instructions that a programmable logic chip can use to preform calculations on input resulting in output. And the scaffolding you use to get there isn't just a matter of philosophical show. Rust as a first order decision will refuse to emit perfectly valid programs because it's unable to prove it's correctness. Zig will emit any program it has enough information to do so. People coding in rust off load much of the effort in understanding and proving that correctness to the compiler. In Zig that relationship is reversed, where the compiler offloads that responsibility to the programmer.
The person you responded to is correct. For some people. Rust solves the difficult and annoying problems, for others it creates difficult and annoying problems.
Some people like creating art, some people like creating software. I guess you could frame that as philosophical, but to call it a political show, belies ignorance to the interactions between systems and predispositions of individuals.
Rust is solving the memory safety problem, Zig is solving the 'idiomatic interop with existing C coding patterns' problem. These couldn't be more different - C-like idiomatic code is generally antithetical to 'safe' modularity since it often relies on tacit global invariants for correct behavior.
Interestingly, Carbon is kinda trying to tackle both at the same time (though starting from C++ in their case) which is a bit of a challenge.
I am not sure how Carbon will go. The Carbon compiler is not ready to be used yet by the public as I understand it, and the roadmap has not been updated for some time now, it seems.
I hear Cardon get mention on rare occasion, and with how rare that is I have to assume it's been completely stagnant. Does it offer anything over C++ in current year? Seems like C++ interop begets turning your language into C++ with different syntax in a way that C interop just doesn't.
As for it being widely adopted, people keeping missing the point that Carbon is mostly for Google themselves, as means to integrate into existing C++ projects.
They are the very first ones to assert that for green field projects there are already plenty of safe languages to chose from.
What concerns me is that the design of Carbon in aspects seem to have serious issues already now.
In case that you are well familiar with for instance pattern matching, might you have any opinions on the pattern matching that is currently proposed for Carbon?
I am not a Google employee, as such I don't care where they take Carbon, other than being a technology nerd that had compiler design as one of the areas I majored in.
Regarding the linked pattern matching proposal, it seems alright to me, not everything has to be ML like.
Are you really OK with runtime "expression patterns"?
match (0, 1, 2) {
case (F(), 0, G()) => ...
}
> Here (F(), 0, G()) is not an expression, but three separate expressions in a tuple pattern. As a result, this code will call F() but not G(), because the mismatch between the middle tuple elements will cause pattern matching to fail before reaching G(). Other than this short-circuiting behavior, a tuple pattern of expression patterns behaves the same as if it were a single expression pattern.
How would that work with exhaustiveness checking? As far as I can tell, they themselves believe that Carbon's exhaustiveness checking will be very poor.
And OK with implicit conversions? Especially when combined with their way of handling templates for pattern matching?
That won't happen if there are legitimate reasons why both Mitchell Hashimoto (creator of Ghostty etc.) and Richard Feldman (of Elm fame, creator of Roc-lang) chose Zig over Rust for their work. They both blogged about it
That doesn't mean Microsoft, Google, Apple, Sony, Nintendo, AMD, Intel, NVidia will be jumping into Zig any time now, just because some HN celebrities blogged about it.
Those are the companies I care about when chosing which programing languages to invest my time on.
The more compelling scenario is one where the unsafe subset of Rust itself becomes roughly as easy to use as Zig is today, though still with potential challenges wrt. properly interacting with safe code.
That requires literally rethinking every language and standard library facility and asking "is this putting up artificial roadblocks or even invoking straight UB when one tries to use it idiomatically in unsafe contexts?", then coming up with more flexible, more "C like" facilities in that case. It's hard work but quite doable.
The roadblock there is a cultural one. Among Rust devs if you ever find the need for an unsafe block then you need an explanation to back it up. If anything, the Rust language would benefit from adding as much friction to unsafe code as possible, so that you're only going to use it when you actually need it.
In other words, the Rust approach to safety is to make as few unsafe LoC as possible, and the Zig approach is to make every unsafe line as safe as possible. As long as their philosophical approach to safety is such that Zig makes writing unsafe code easy and Rust avoids it as much as possible, then writing unsafe code in Zig will always be easier.
The goal of Rust is not so much to avoid unsafe, the goal is to maximize safe code. The reason is that you don't have to check safe code for all the guarantees to get from the Rust language.
This has a big effect on unsafe code. When unsafe code gets called indirectly from safe code, the unsafe code has to make sure that whatever the safe code does, the result is still safe. This requires very careful design of the interface provided by the unsafe code.
I think it is a research question whether Zig would make writing Rust unsafe code a lot easier. In particular the boundary between safe Rust and unsafe code written in Zig could become very tricky. Possibly tricky enough that it would be as complex to write as unsafe Rust today.
The problem is not so much "when unsafe code gets called indirectly by safe code", which is fine if the unsafe happens to be sound. The problem is that "when C-like or Zig-like unsafe code wants to call safe code", the safe code is running in a context where its implied invariants may be violated, leading to insta-UB. Hence code that's intended to provide "library-like" facilities to unsafe blocks cannot be idiomatic Safe Rust, and it needs to be written even more carefully.
For instance, any &mut reference in Rust is assumed not to be aliased, and any &reference not involving UnsafeCell<...> is assumed not to be written to. These implied contracts can be loosened, e.g. by using &Cell<> if applicable (may alias, can be read or written safely, but only "as a whole object": access to the internals does not escape beyond any single operation) which is arguably closer to idiomatic C.
MaybeUninit<> is another common example: C and Zig code often works with possibly-uninitialized data, but this possibility has to be accounted for explicitly in a safe Rust interface. It's always insta-UB if a safe Rust function is passed uninitialized data, even when the equivalent would work idiomatically in C.
This is what makes Rust Rust and I'd say what makes Rust popular. The way safe Rust is safe. Of course this comes at the expense of making writing unsafe a lot harder.
Though I can imagine that unsafe Rust still has to many of the safe Rust's rules. So there could be a better unsafe language that has fewer restrictions.
The real sticking point is not whether there could be a better unsafe language, but a better unsafe library (or unsafe-friendly library that's still conditionally safe in some rigorous sense). That's a much closer goal that could even be achieved within Rust itself as it currently exists today.
No, it's not just a cultural thing. There are very real problems with standard Rust facilities not being accessible/usable from an unsafe context even though the C/C++/Zig idiomatic equivalent would be (i.e. would not invoke instant UB), and these problems are solvable. Sophisticated Rust developers are aware of the issue.
> If anything, the Rust language would benefit from adding as much friction to unsafe code as possible
The friction is there already. I'm not advocating for getting rid of explicit 'unsafe' markings, 'SAFETY' comments or even clunky boilerplate, just for closing a very real gap in capability.
Zig is a drop-in for C. I'm not sure what Rust is but around here no C++ teams seem to be adopting it. Zig on the other hand is seeing adoption in teams who write C for Python binaries. Not a whole lot of it since it's not exactly safe or "stable", but some. Now I'm aware that things like UV are build with Rust, but part of why UV is adopted so widely isn't just that it's fast. It's that it is a drop-in for pip, so that you can compile a requirements.txt and deploy your project without UV, which is handy when you use things like Azure specific Microsoft containers.
Maybe it's just C++ teams being conservative, but a lot of them really seem to hate Rust when you talk with them for whatever reason. I can't imagine why though, but then I've only ever worked with C when I had to, and I have never worked with C++. From having played around with both C++ and Rust, I'd personally pick Rust, but I'm sure it's because I don't know enough. Either way I doubt I'll ever see Rust in a real world job in my corner of the world.
First of all, if I am an evangelist of anything, it is about safe systems programming with automatic resource management languages, if I had a magic wand, we would be talking about languages like D and AOT C#, not Rust.
Secondly, let us know when Amazon rewrites Firecracker in Zig, Android replaces Rust with Zig, or Mark Russinovich goes to some Zig conference explaining why Azure is dropping Rust for Zig,
"Mark Russinovich, Microsoft Azure CTO tells Rust Nation UK 2025 why Azure is moving to Rust from C++"
The only Microsoft divisions that are still all are into C++ is Windows and XBox, and still, C++/WinRT is now in maintenace, the team has moved into windows-rs, WDK now has Rust bindings available.
Microsoft and IBM don't. Then they don't really post jobs for their own stuff. It's mainly to sell consultant services like selling Mainframe SWE's service to banks. If you mean jobs in my area in general then there are a lot of places that offer C++ jobs.
> the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to
Given that Rust is quite an old language now and its adoption is still so low, I don't think that should be much of a worry, although that doesn't mean Zig will be the option of choice, and not stabilising is certainly not a good sign. At Rust's adoption rate, a language that hasn't been invented yet and that would show a more normal rate of adoption for a popular language could easily overtake it.
> There is also the issue of will people actually code by then.
> Given that Rust is quite an old language now and its adoption is still so low,
So being part of 3 major OS (Windows, Android and now Linux), the big 3 cloud providers having SDKs for the language, used by so much tooling (js + python) and being part of major internet infrastructure means its “slow” adoption then wow…
Very much so once you compare it to how quickly C++ (and, in fact, any language that's ever been in the top 5 or so) achieved similar milestones. Rust's adoption is very impressive when you compare it to, say, Haskell or Clojure, but not when you compare it to languages that achieved significant and long-lasting popularity. It's roughly similar to Ada's adoption when it was of a similar age (Ada was more prevalent then than Rust is now in some areas and less so in others). When work on Rust started twenty years ago, Java was younger than Rust is now. It was almost as close in time to the early work on C++ as we are now to the early work on Rust. Larger portions of operating systems were being written in C++ when it was younger than Rust is now.
There's no denying Rust's popularity in open-source CLI dev tools for Python and JS/TS, but when you talk to C/C++ shops who've evaluated Rust and see how many of them end up using it (and to what extent) you see it's not like it's been with languages that ended up achieving real popularity (which includes not only super-popular languages like C, C++, and Java, but also mid-popular languages like Go).
To this day C++ has hardly won the hearts of C devs on the embedded space, on both sides of the camp there are individuals that start religious discussions about the C/C++ abreviation, there is something like Orthodox C++ that basically means using C++ compiler to write what is mostly Better C, and most frameworks that were so hyped in the 1990's are now gone, or subsyst in maintenance contracts on applications that when the time gets to be rewritten it won't surely be C++.
So even though C++ is the language I reach for outside Java, C#, TypeScript, I would assert that downplaying Rust adoption by Amazon, Adobe, Microsoft, Google, is losing track where things are going.
Downplaying compared to what? This kind of adoption is certainly something Haskell never gained. But all those companies (or analogous ones) adopted C++ much faster. In fact, they've adopted faster virtually every language they're using seriously. So it's a great achievement compared to every language they've never adopted at all, but not such a great achievement compared to every other language they have adopted.
> that when the time gets to be rewritten it won't surely be C++.
It looks like it won't be Rust, either. I mean, some may be written in Rust, but not the majority. My point is just that as much as some erstwhile Haskell fans have taken to Rust, comparing Rust's adoption to Haskell's - a language whose joke motto was "avoid success at all costs" - is not the right metric. Given that Rust's goal was to replace C++, its success should be compared to C++ and other languages that ended up achieving similar success. I'm saying that compared to them Rust's success has been mediocre, if that, and it's not a young language anymore by any stretch of the imagination.
I don't have a use for Rust on my daily work, and would rather see Java finally adopt the features it missed down from Oberon and Modula-3 for systems programming, however we will have to disagree on the "mediocre" adoption.
So many language designers would dream to have such adoption numbers by tech giants for their hobby language.
Of course Rust is very popular compared to any hobby language (and many non-hobby languages), but that is not the goal it set for itself to be judged by.
Correct, the goal is to be foster the adoption of safe systems programming, which given the uptake across all major cloud hyperscalers powering the Internet, and all major OS vendors selling hardware (with exception of one because they have their own alternative), is what I would consider a large success of anyone dreaming to get their language adopted at scale.
All major cloud vendors deploying my Java, .NET and nodejs containers do so, in infrastructure that has various layers of Rust code in it.
> Very much so once you compare it to how quickly C++
C++ came out in 1985 and competed with C, COBOL, Pascal and FORTRAN. It was an overall improvement than those and therefore there is a legit reason for it to take off.
> how many of them end up using it (and to what extent) you see it's not like it's been with languages that ended up achieving real popularity
I assume many places that have a huge codebase in C++ would just do a port to Rust. That would almost always cause problems but for greenfield projects it's a no brainer IMO.
> It was an overall improvement than those and therefore there is a legit reason for it to take off.
Of course. The rate of adoption is related to the increase in value compared to the status quo, much like how genes spread. But Rust's adoption is slow precisely because its "fitness benefit" is low.
> That would almost always cause problems but for greenfield projects it's a no brainer IMO.
It would have been a no brainer if, when writing a new codebase expected to last 20 years or more (which is often the case with software written in low-level languages), you'd believe the chosen language to be very popular over the next few deacdes. But given its slow adoption compared to languages that ended up achieving that status, despite it's rather old age, it's not looking like a safe bet, which is why Rust's adoption for important greenfield projects is also low (again, relative to other languages).
> Very much so once you compare it to how quickly C++ (and, in fact, any language that's ever been in the top 5 or so) achieved similar milestones.
No, this completely overestimates how quickly languages gain prominence.
C came out in 1972 and didn't gain its current dominance until approximately the release of the ANSI C spec in 1989/1990, after 17 years.
C++ came out in 1985 and didn't become the dominant language for gamedev until the late 90s (after it had its business-language-logic niche completely eaten by Java), after 14 years or so.
Python came out in 1991 and labored as an obscure Perl alternative until the mid-late 2000s, after about 16 years (we can carbon-date the moment of its popularity by looking at when https://xkcd.com/353/ was released).
Javascript came out in 1995 and was treated as a joke and/or afterthought in the broader programming discourse until Node.js came out in 2009, after 14 years.
Rust is currently 11 years old, and it's doing quite excellently for its age.
> C came out in 1972 and didn't gain its current dominance until approximately the release of the ANSI C spec in 1989/1990
While it kept growing in popularity later, by 1983-5 C was already one of the top programming langugages in the world.
> C++ came out in 1985 and didn't become the dominant language for gamedev until the late 90s
Major parts of Windows and Office were being written in C++ in the early-mid 90s, before C++ turned 10. Visual C++, one of Microsoft's flagship development products, came out in 1993. Huge mission-critical, long-term, industrial and defence projects were being written in C++ during or before 1995 (I was working on such a project).
> Python came out in 1991 and labored as an obscure Perl alternative until the mid-late 2000s
Even in 2002 Python was widespread as a scripting language. But it is, indeed, the best and possibly only example of a late bloomer language.
> Javascript came out in 1995 and was treated as a joke and/or afterthought in the broader programming discourse until Node.js came out in 2009
AJAX (popularised by Gmail) pretty much revolutionised the web in 2004. When jQuery came out in 2006, JS was all over the place.
> Major parts of Windows and Office were being written in C++ in the early-mid 90s, before C++ turned 10.
Major parts of Windows, Android, and Linux were being written in Rust before it turned 10. Major parts of AWS were being written in Rust before it turned 4. Major parts of Dropbox were being written in Rust before it turned 1. So you agree by your own criteria that Rust is a major language?
> While it kept growing in popularity later, by 1983-5 C was already one of the top programming langugages in the world.
In the mid-80s, C still had plenty of major and healthy competitors, as pjmlp will imminently arrive to remind you. By the criteria of mid-80s C, Rust is already one of the top programming languages in the world.
> AJAX (popularised by Gmail) pretty much revolutionised the web in 2004. When jQuery came out in 2006, JS was all over the place.
No, despite the existence and availability of freestanding interpreters (e.g. Rhino), Javascript was an also-ran everywhere except the web; which is to say, nobody was choosing to use Javascript except the people forced at gunpoint to use it. There are infinitely more people choosing to use Rust at the age of 11 than were choosing to use Javascript at the age of 11, which means that, once again, by your criteria, you must consider Rust a major language. You can just admit it instead of being a tsundere.
No, this is silly. You can look at the availability and maturity of toolchains, the rate of release of projects written in that language, the rate of release of books and learning materials, the rate at which universities begin teaching the language, the volume of discourse devoted to that language in magazines and the online venues which did exist (e.g. Usenet), and crucially the declining metrics of all of the above for the direct competitors of that language.
Rust projects generally use licenses like MIT instead of GPL, and thus some major corporations support Rust a lot, and thus Rust will continue getting popular.
Growing in absolute numbers doesn't mean growing the market share, and even a growing market share is not necessarily sufficiently fast growth to become a safe bet. All languages that ended up becoming very popular grew their market share much faster than Rust does. Being an old language with some real market share is obviously better than being an old language with negligible market share, but being an old language with real, but small, market share is not exactly a sign of confidence.
It's true that the total market share for low level languages (C + C++ + Rust + Zig + others) continues declining, as it has for a couple of decades now (that may change if coding agents start writing everything in C [1] but it's not happening yet), but that's all the more reason to find some "safe bet" within that diminishing total market. Rust's modest success is enough for some, but clearly not enough for many others to be seen as a safe bet.
Do you know of a good way to measure market share? I know of GitHub's and StackOverflow's surveys, but I'm not sure how well they reflect reality. There is also Redmonk.
GitHub's survey did not say much about Rust I think, despite Rust projects often having lots of starring. Rust projects might have a greater ratio of stars-to-popularity than projects in other languages, though.
StackOverflow's survey was much more optimistic or indicated popularity for Rust.
The best sources are industry studies by market research companies that collect information from companies. The best public sources, IMO, are those based on job openings (as jobs correlate more with total number of lines of code than sources based on number of repos, PRs, or questions). Some of these are about a year out-of-date:
Viewing these numbers through an optimistic or pessimistic lens is a matter of perspective and, of course, no one knows the future. But when you compare Rust, which is a middle-aged language now, to how languages that ended up "making it" were at the same age, the comparison is not favourable.
Except you could say something similar about the first few years of every language that became very popular, and the comparison would still not be in Rust's favour.
I wouldn’t worry about that. There’s plenty of software yet to be written, in many languages. If anything, Rust’s success has shown that it’s definitely possible for a new language to succeed if it offers something new.
The other tailwind for Zig is that it’s easier than ever to translate an existing codebase with tests into a new language with AI.
Their own libc project is wicked. They are gradually replacing C implementations with zig and in the mean time the C implementations effortlessly link and compile in the same compilation unit as the zig code.
I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.
Zig OTOH is clearly, to me at least (opinion alert), a "better C". It even compiles C!
I expect LLMs to be really good at converting C to Zig.
> There is also the issue of will people actually code by then.
LLMs don't take responsibility. So even if code is generated, a human will have to assess it. I think assessing Zig is easier than assessing C, which gives this language a selling point that holds out in the AI assisted programming future.
I've been coding in Zig for nearly 2 months straight now.
Or should I say, I've not written a single line of Zig because I've been managing AI's coding in Zig.
Turns out Zig is a fantastic language to "centaur" on. (Reference is to "centaur chess" and which is also sort of becoming a term indicating close code design cooperation with an LLM.)
All of that C code that the LLM trained on ends up helping it work out algorithms in Zig, except that Zig has waaaay more safety guarantees and checks. And is often faster compiled code than the equivalent C, which is astonishing.
> I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different.
The same can be said about Zig's comptime. It's entirely unlike anything C, C++ or Rust has to offer.
> I expect LLMs to be really good at converting C to Zig.
While it's possible to translate C to Zig code - and you don't need an LLM for that, it's a Zig compiler/build-system feature - the result will be quite different from a project that's developed in Zig from the ground up since the translation output wouldn't make use of Zig's unique features (and Zig isn't really unique as 'C translation target', C can also be translated to unsafe Rust, or even to Javascript - see early Emscripten versions).
Also, the 'C compatibility' of Zig is implemented via a separate compiler frontend, Rust toolchains could do exactly the same thing by integrating the Clang frontend into the Rust compiler.
Using the same language for compile-time and run-time programming is compelling, but doing it properly requires using the same approaches that dependently typed languages use. Comptime is a bit half baked.
It's not just about writing imperative code that runs at compile time, the actual interesting comptime feature in Zig is that "types are comptime values", e.g. you can inspect types and build new types with regular (comptime) code. This is very different from the template/trait systems in C++ and Rust. What Zig's comptime system is missing is the ability to build functions bodies at comptime (e.g. some sort of comptime AST builder).
Not all C++ is OOP, and Rust does support OOP as per CS literature, so much so that I have had no issues rewriting Raytracing Weekend tutorial from C++ into Rust, while keeping the same OOP architecture from the tutorial.
