rc00
Qualcomm has been beating the marketing drum on this instead of delivering. Ampere has delivered excellent hardware but does not seem interested in the desktop segment. The "greatest Linux laptop around" can not be some unmaintained relic from a hostile hardware company.
The demise of both of these trends cannot come soon enough.
> I stick with Qt
These come up on search results if you combine Qt plus the language.
Go:
* https://github.com/mappu/miqt
Java:
* https://github.com/OmixVisualization/qtjambi
Nim:
* https://github.com/jerous86/nimqt
* https://github.com/seaqt/nim-seaqt
Zig:
What about the crypto library affects how you would use Go to solve your problem?
1. https://deadmoney.gg/news/articles/migrating-away-from-rust
> So now I pose the question to you what do we do?
1. Port your application to the language/tool that fits your needs like Go.
2. Hope that a language like Zig decides to feature a standard library as good as Go.
> I just don’t care about karma that much. The first 500 is the only that matters. I find it hard to say that submitting a story that people found valuable is “abuse.”
The submitting account is automated and mostly non-deterministic. Forget the fake internet points and focus on the fact that there are accounts on this site that mostly exist to spam. Isn't the value of this site that humans curate what is posted? Or is automating submissions not a form of abuse? Good to know where your ethics are.
Except the submitter account in question is actually automating submissions from what looks like Lobsters (based on the timing and posting history). The account owner only seems to post non-automated comments to spam their product. This looks an awful lot like abuse. Or is abuse okay when you perceive it to be beneficial to Rust propaganda?
https://deadmoney.gg/news/articles/migrating-away-from-rust
https://loglog.games/blog/leaving-rust-gamedev
https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...
https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a39...
https://medium.com/@rusty-vibes/part-4-abandoning-rust-for-c...
A pile of evidence refutes your statement. There is more if you need.
> I'm happy to revise what I said from "Rust keeps winning" to "Rust continually won"
"Rust has peaked"
The one I shared before that is from late 2024. What are you trying to say other than Rust has peaked?
What are you talking about?
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.
Migrating Away from Rust
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.
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.
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.
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.
These are language features not dependencies or external libraries. Maybe the best phrasing is that Rust's garbage collection features are opt-in, similar to the same features being opt-out for Go, Nim, OCaml, and others.
GLib is an external library to C and C's standard library. Arc/Rc (and there are other types of garbage collection within Rust _the language_) are language features since they are built-in types.
The delineation is very clear here. If it is part of the language's standard features and/or standard library then it is part of the language. Using opt-in/opt-out terminology also make clear how the garbage collection features are available. In Rust, you opt into garbage collection by using specific built-in types.