I'm happy to revise what I said from "Rust keeps winning" to "Rust continually won" if you want to nitpick my choice of verb tenses. It refutes the idea that the "developer joy is pretty low" either way.
Yes, you have correctly pointed out that there are some developers who are unhappy with Rust.
I don't really care to have an argument as to whether "Rust has peaked" or not. Rust is the same language now as it was in 2023, and 2022, and 2021, etc., and developers liked it then. That's all.
> A pile of evidence refutes your statement. There is more if you need.
There are only two kinds of languages: the ones people complain about and the ones nobody uses
Of course some people are going to complain about Rust (for many various reasons, and had you read the links you posted, you'd have noticed that they all moved to a different one: C++, Zig or C#), the question is which share of it do, and the answer is a smaller one than in other mainstream languages.
+1 for Stern especially since it only has Go dependencies whereas Kubetail does not. Ease of integration with an existing stack is a bigger addition than the lack of a web UI is a subtraction.
> I think Zig is mostly community-driven and seems to have some traction. Not Rust levels of traction but definitely relevance.
Zig already appears to have lapped Rust in areas like game development, GUIs, compilation speeds, C FFI, etc. and all that despite Zig not yet being 1.0. That means backwards compatibility is not guaranteed until then nor is the full feature set fully defined. Notwithstanding that 1.0 release, traction and relevance only seem to be a matter of time.
> What in particular do you find cumbersome about the borrow system?
The refusal to accept code that the developer knows is correct, simply because it does not fit how the borrow checker wants to see it implemented. That kind of heavy-handed and opinionated supervision is overhead to productivity. (In recent times, others have taken to saying that Rust is less "fun.")
When the purpose of writing code is to solve a problem and not engage in some pedantic or academic exercise, there are much better tools for the job. There are also times when memory safety is not a paramount concern. That makes the overhead of Rust not only unnecessary but also unwelcome.
Isn't the persistent failure of developers to "know" that their code is correct the entire point? Unless you have mechanical proof, in the aggregate and working on any project of non-trivial size "knowing" is really just "assuming." This isn't academic or pedantic, it's a basic epistemological claim with regard to what writing software actually looks like in practice. You, in fact, do not know, and your insistence that you do is precisely the reason that you are at greater risk of creating memory safety vulnerabilities.
One example is a function call that doesn't compile, but will if you inline the function body. Compilation is prevented only by the insufficient expressiveness of the function signature.
It's not difficult to write a provably correct implementation of doubly linked list in C, but it is very painful to do in Rust because the borrow checker really hates this kind of mutually referential objects.
Hard part of writing actually provable code isn't the code. It's the proof. What are invariants of double linked list that guarantee safety?
Writing provable anything is hard because it forces you to think carefully about that. You can no longer reason by going into flow mode, letting fast and incorrect part of the brain take over.
Although the more usual pattern here is to ditch pointers and instead have a giant array of objects referring to each other via indices into said array. But this is effectively working around the borrow checker - those indices are semantically unchecked references, and although out-of-bounds checks will prevent memory corruption, it is possible to store index to some object only for that object to be replaced with something else entirely later.
> it is possible to store index to some object only for that object to be replaced with something else entirely later.
That's what generational arenas are for, at the cost of having to check for index validity on every access. But that cost is only in comparison to "keep a pointer in a field" with no additional logic, which is bug-prone.
Is Zig aiming to extend C or extinguish it? The embrace story is well-established at this point but the remainder is often unclear in the messaging from the community.
C interop is very important, and very valuable. However, by removing undefined behaviours, replacing macros that do weird things with well thought-through comptime, and making sure that the zig compiler is also a c compiler, you get a nice balance across lots of factors.
It's a great language, I encourage people to dig into it.
Open source or not isn't the point. The point is the mission and the ecosystem. Some of the Zig proponents laud the C compatibility. Others are seeking out the "pure Zig" ecosystem. Curious onlookers want to know if the Zig ecosystem and community will be as hostile to the decades of C libraries as the Rust zealots have been.
To be fair, I don't believe there is a centralized and stated mission with Zig but it does feel like the story has moved beyond the "Incrementally improve your C/C++/Zig codebase" moniker.
Are you referring to static linking? Dynamic linking? Importing/inclusion? How does this translate (no pun intended) when the LLVM backend work is completed? Does this extend to reproducible builds? Hermetic builds?
And the relationship with C libraries certainly feels like a placeholder, akin to before the compiler was self-hosted. While I have seen some novel projects in Zig, there are certainly more than a few "pure Zig" rewrites of C libraries. Ultimately, this is free will. I just wonder if the Zig community is teeing up for a repeat of Rust's actix-web drama but rather than being because of the use of unsafe, it would be due to the use of C libraries instead of the all-Zig counterparts (assuming some level of maturity with the latter). While Zig's community appears healthier and more pragmatic, hype and ego have a way of ruining everything.
> How does this translate (no pun intended) when the LLVM backend work is completed?
I'm not sure what you mean. It sounds like you think they're working on being able to use LLVM as a backend, but that has already been supported, and now they're working on not depending on LLVM as a requirement.
> Does this extend to reproducible builds?
My hunch would be yes, but I'm not certain.
> Hermetic builds?
I have never heard of this, but I would guess the same as reproducible.
> While I have seen some novel projects in Zig, there are certainly more than a few "pure Zig" rewrites of C libraries.
It's a nice exercise, especially considering how close C and Zig are semantically. It's helpful for learning to see how C things are done in Zig, and rewriting things lets you isolate that experience without also being troubled with creating something novel.
For more than a few not rewrites, check out https://github.com/allyourcodebase, which is a group that repackages existing C libraries with the Zig package manager / build system.
zig's C compat is being lowered from 'comptime' equivalent status to 'zig build'-time equivalent status. When you'll need to put 'extern "C"' annotations on any import/export to C, it'll have gone full-circle to C++ C compat, and thus be none the wiser.
andrewrk's wording towards C and its main ecosystem (POSIX) is very hostile, if that is something you'd like to go by.
The goal rather explicitly seems to be to extinguish it - the idea being that if you've got Zig, there should be no reason to need to write new code in C, because literally anything possible in C should be possible (and ideally done better) in Zig.
Whether that ends up happening is obviously yet to be seen; as it stands there are plenty of Zig codebases with C in the mix. The idea, though, is that there shouldn't be anything stopping a programmer from replacing that C with Zig, and the two languages only coexist for the purpose of allowing that replacement to be gradual.
I can see the appeal if there is a need for stronger metaprogramming. Not that Zig is terrible in this area, it is just that Jon's language is much more powerful in that area at this stage.
That being said, I do see an issue with globally scoped imports. It would be nice to know if imports can be locally scoped into a namespace or struct.
In all, whether it's compete or coexist (I don't believe the compiler for Jon's language can handle other languages so you might use Zig to compile any C or C++ or Zig), it will be nice to see another programming language garner some attention and hopefully quell the hype of others.
What are you talking about?