You just got a tiny taste of what Rust enthusiasts have been doing to every C++ related submission here on HN for years.
Which is what C++ enthusiasts have done to C enthusiasts and C enthusiasts have done to assembly enthusiasts.
I suspect that Rust will start taking over as a dominant LLM output language.
I also suspect that in short order we'll have entirely new languages that are engineered to be ideal languages for LLMs to generate. Perhaps even safer than Rust.
The models are shockingly good at writing Rust. You don't even need to have familiarity with Rust to start using it now. You'll learn the language as you interact with the LLMs.
Decades before Rust and long before the simplified language that was C, there were safe programming languages, where all invalid operations, numeric overflows or out-of-bounds accesses generated exceptions and where use-after-free was impossible, because either garbage collectors or reference counts were used.
Rust is much safer than C compiled with its bad default compilation options, but it did not bring much in comparison with other languages.
Even in C++, with appropriate rules, restrictions and discipline you can write programs that are guaranteed to be at least as safe as any Rust program, but unfortunately very few use C++ in this way, i.e. by strictly avoiding the features that are obsolete or unsafe.
And no, C++ just doesn't make the same things easy or clean.
And no, "discipline and appropriate rules" were never enough.
The biggest innovation of Rust is bringing some of the good ideas from functional programming to low level programming. I'd also say that partially exposing data flow analysis to a proframmer is new.
Rust package management is quite good, and also not by any means an invention.
I am still not a fan of all the ugly macro programming systems and verbose syntax in the language.
The language I really want is somewhere inbetween those two languages.
The broader ML-like type system in Rust is not novel, but the integration of the borrow checker -- and its move semantics more broadly -- with it in its form honestly is an innovation. And one I'd have a hard time living without at this point.
If by discipline, you mean running something akin to the borrow checker in your head, that's essentially tautologically true. The issue with that is that it's mentally draining and/or you will still make mistakes sometimes.
For maximum safety, beyond what Rust offers by default, in C++ it is easy to replace the built-in integer types with custom integer types, which check for overflows and allow only the correct type conversions. It is also easy to define distinct types for various kinds of physical quantities, for increased safety.
You do not need to run anything in your head. With appropriate type definitions, a C++ compiler will do anything that is required.
The problem is that because of the requirement for backwards compatibility, C++ is a huge junk collection. I think that more than half of C++ consists of obsolete features, which should never be used in new programs, and this is a serious difficulty for newbies. There are various C++ style guides, but in my opinion even most of those are not very inspired.
Despite of its defects, C++ still has the advantage of extreme customizability. It is easy to write programs that appear to be written in a language that has no resemblance with C++ (inclusively by having different keywords and what appears to be a different syntax), but nonetheless they are valid C++ programs.
Such a customized C++ variant can mimic any safer language.
The work to try to address this for C++ 29, half-finished and untried as it is - is extremely restrictive, you'd likely hate it, and that's just to solve this, the relatively easy problem.
Thing is, Rust wasn't content just to solve that easy problem. (Safe) Rust also doesn't have data races. The C++ standard doesn't say very much about data races, can't help you ensure they don't happen - it just explains that if they do that's Undefined Behaviour, game over.
This completely misses the point.
That is really not very different of rules enforced by the Rust compiler.
For someone who does a fresh start, using a Rust compiler may ensure safer programs out of the box, but that does not mean that the same results cannot be achieved by alternative means when using other languages, when the use of those languages makes sense for other reasons, and it is worthwhile to invest resources in making appropriate libraries and tooling.
In general, I recommend against the use of C++ in new projects, but I see much too often claims about things that are supposedly difficult or impossible to do in C++, which are just false.
I doubt it. I think most people will become more entrenched in their favored ecosystem.
> I also suspect that in short order we'll have entirely new languages that are engineered to be ideal languages for LLMs to generate.
This is already happening. A couple months ago I came across this language that is engineered for AI and human consumption https://www.moonbitlang.com/
A waste.
This code will be high-defect and slow.
All of your LLM outputs should be Rust.
Of all the complaints about rust, this strikes me as one of weirdest. How much code do you actually write for architectures outside the Tier 3 support list?
However I did write ADA and C for those.
Ok, but recently? I too wrote code for obscure platforms once upon a time, but not in, say, the last 15 years.
Now that PCs, game consoles, and mobile devices are basically all either amd64 or ARM, there's just not such a long tail of weird platforms to develop for.
(the embedded world I will grant you, still lots of bespoke toolchains running around in that space)
We get it. You like Rust. It's not a panacea.
Experienced Go devs that stay inside the ecosystem try to write their libraries as "pure go" libraries with zero dependencies other than the upstream core libraries (or golang.org/x if needbe), which results in a very low maintenance ecosystem. This combined with the strong toolchain makes it joyful to work with.
I still don't agree with a lot of design choices of the language, but I realize that I can be more efficient if I am setting aside my opinion.
And that's exactly the thing that somehow never happened in the Rust ecosystem. I always joke that the Rust ecosystem has more OpenGL bindings than developers, because there's just so many low quality bindings or wrappers out there that the ecosystem in result got too noisy to maintain.
I don't want to write more (verbose) code. I want to write less.
I kind of already know that my comment goes to shit in terms of downvotes, but that's what I expect while writing this. How dare I criticized Rust as a language? How dare I, a fulltime noob, do this? Rust is better, always!
...the Rust ecosystem is just so effing toxic. I am glad that I left it. I just got tired of being angry at random online things all the time. Go is my happy place where my annoyances are reduced to Cgo, maps, and the unsafe package <3
Rust seems to attract a lot of horizontal programming. I have done mainly that so far and I LOVE Rust for it.
AIUI, horizontal programming is fully building out each abstraction before you start building on top of it, as opposed to vertical programming, which generally seeks to accomplish the task as directly and straightforwardly as possible, and only abstract if needed.
This leads to things like the proliferation of bindings, abstraction layers, frameworks etc. with little downstream users to show for it. And often little influence from experience using them. Sometimes very technically impressive but otherwise not always fleshed out to the point of being practically usable.
I am sure there's tons of toxicity all over the place too but I chalk it up to differing mindsets / patterns of development.
For example, std's linked list seems rarely useful for anything but scripting, and could've easily been a crate. I don't think it's egregious or anything, it's just a bit meh. I don't really use Rust for scripting though (I usually use zsh or TypeScript), so maybe it's super valuable in specific cases.
Please provide a link to this comment.
Someone asked an honest question and got reasonable responses that were informative. At no point did anyone chide the project for not using Rust.
> Rust might be a fine language but it has the most toxic evangelist culture, bar none.
Nah, people complaining about the supposed toxic community are noisier than the supposed toxic community.
Then again, your very username implies an indulgence in viewing technology through the lens of fandoms which is... weird
It was basically a complete derail to backdoor in a conversation about why they think everything should be in Rust.
OpenBSD still uses CVS, C and Make because that's what works for them. They will continue to keep using C, Make and CVS but that enables them to be productive with the contributors that they have. Moving things to other languages will not increase their productivity. That's the biggest thing that the largely-fanatical Rust evangelists completely fail to understand.
This is a wide ranging discussion board, not the OpenBSD forums. That shit is fair game even if you don’t like it.
(It’s annoying, sure - because dev tribalism is the most played out thing in this industry - but overall the topic can be an interesting discussion point)
I come to an OpenBSD post to talk about OpenBSD. Rust isn't even really tangentially related.
Then why is it weird if you're saying the same thing? Different programming languages appeal to programmers with different tastes, and so it makes sense that some programmers would be drawn to language X and dislike language Y, while others would be the opposite.
I'm old-ish though and grew up apolitical, so I'm sure it's just a me problem.
You kind of had to be there for part of it, at least the early stuff though.
Edit: Thought about scare quoting “taste”
In fairness, Loris Cro is “VP of Community at Zig Software Foundation” so if there’s someone to judge the community by, Loris has more weight than just about anyone (perhaps excluding Andrew Kelly).
Note I am not agreeing with your parent post, what I have seen from Loris and Andrew makes me interested in trying Zig.
Ghostty is fine I guess, I find it to be way buggier than iterm with a fraction of the features.
Zig is fine, has some cool stuff, the community seems roughly the same as the rust, with again just way less features.
The rest of the hashi tools are fine, I don’t really use any of them anymore. Vault was a big deal at some point I guess
For decades, I have used a great number of video terminal emulators. I have used for long time intervals at least 8 or 9 video terminal emulators, from the original xterm until the one used immediately before ghostty, which was kitty (and including Konsole, the Gnome terminal, the XFCE terminal, WezTerm and others).
I consider Ghostty the best video terminal emulator that I have used. For now, I have not encountered any noticeable bug yet, even if I spend a lot of time using it.
Nor have I encountered any feature that I really miss (though a few things that worked in other emulators, do not work, at least not with the default configuration, e.g. setting the title of a tab window with the standard escape sequence of characters; but the ghostty titles are fine, i.e. the pwd value while in shell and the invoked command otherwise).
I do not doubt that there may exist some bugs or missing features, but it seems unlikely that they can be seen during typical workflows. I have used it only in Linux, so I do not know anything about bugs under macOS.
It turns out its not 1986 anymore, and sometimes we want to output gasp images to our terminals
Hmm... I'm using ghostty (on macOS) since it was released and have yet to encounter a single bug. Iterm2 simply got too fat and slow over time, which was the point where I went terminal-shopping (first wezterm, which is also fine, now sticking with ghostty).
Literally all companies I've worked for a know about use Vault for storing secrets to be used during deployment.
It would be interesting to learn that this is different elsewhere.
If you want auto unseal with HSM and don't have to worry about the unseal key shards, then you can hook it up the HSM. Of course, HSMs are expensive and you also have to buy a Vault license.
Never used the product Vault.
I don’t use Zig, and frequently use Rust, but I’ve never really interacted with the core development team for either. I don’t think it’s necessary to care about whatever culture is driving development once it has sufficient velocity. The Rust I use today is more than enough for my needs. Maybe if I were more involved in open source I would better understand why culture matters, but unfortunately I’m mostly a consumer of it, not a producer.
In hindsight (and at risk of starting a flame war), it's easier to be magnanimous when you are winning/have won.
Rust's big tentpole is "no memory management bugs, everything must be provably safe", whereas Zig is very proud of "no memory management, you have full control but you have to exercise it". I don't feel as though these are competing for the same audience or mindshare.
I've used Zig a big (while trying to contribute to ghostty, at least), and it's an interesting language that I like the aesthetics of but I don't want to use. I use Rust for things because it's so specific about what it wants from you and won't let you go off-script, and frankly I find that very beneficial for myself as someone coming from Python, Javascript, PHP, etc. where you just let things fall out of scope and it's not your problem anymore (usually).
I share your complaints about the tools you came to Rust from, but the philosophy of not letting you go off script is great until it doesn't work for you. A lot of the reason some of us use the more flexible languages is because we've been in situations where a language and its ecosystem either won't let you do something outright or not without significant pain. Often when everything is on fire and your customers are cancelling contracts. You can't afford to wait for the core team or community to come in and save you in these situations.
Having access to work around your problems is also the source of a lot of the pain you're talking about, but at least you get to stay in business to solve that problem tomorrow.
To a very large degree, a lot of the Rust evangelists that I encounter in the wild are either hobbyists, academics or paid open source contributors at large companies. Most of the discussions I've seen wrt Rust at companies with actual deliverables stop at "Rust? Absolutely not.". Except for a very narrow set of systems where you want the kind of guarantees that Rust provides as a primary feature. For more general situations, the tradeoffs often aren't worth it.
> Culture wars are sadly one of the biggest inhibitors of progress
"My tribe is better than your tribe"
Some people thrive inside this mentality, whole others don't go near it.
Not everyone is thinking like this but a lot of people do. So because of that it's a common heuristic to think of it as "war" because there are some people who do that gladly.
Still though: Amiga 4 ever! :D
I might stay away from a particularly toxic community or one with wildly different values, but I don't really get why you wouldn't write Rust just because of how some people post about it. Odd tbh. I find the whole thing about "oh the rust zealots" hand wringing stuff so silly, really.
That's just engineering communities in a nutshell...
I'm a bit curious, what features could you not do without?
I think I get the point about "Rust culture" (although it's too vague to agree or disagree with, probably on purpose).
But in 2026, Rust is fully a commodity language, and especially to compare it to Zig in this angle is bizarre. Even turning my stereotypes to 11 and thinking back to when I worked with a team developing Rust professionally in 2021, I'd say we got mostly ended up hiring "proglang enthusiasts" and not "Rust people." In terms of "cultural dilution" alone Zig is orders of magnitude more culty than Rust because that many fewer people use it.
I think you missed his point. He's arguing against homogeneity of (cyber) culture. For example, programming languages that promise to do everything. Rust fanatics indeed can be a bit like that. Every time I see a thread here about someone building something in Zig, they storm in and start arguing 'why not rust!?'.
The fact that you don't like the zig community is healthy and not weird. Don't worry about it. You don't have to like everything and you can disagree on taste.
> I tried to get into Zig even chatted with Loris Cro when he was streaming. I was looking to explore what my Rust project could look like in Zig but there were features simply missing that I couldn't do without. The entire interaction was mostly about how bad Rust is and how I could just do something different in Zig (completely misunderstanding my ask, with little interest to explore my actual requirements).
Kind of reeks of unreasonable expectations to me. I don't think one should expect language designers to redesign a language or introduce new features that would likely be poor fits with the overall existing language philosophy (the design and usage philosophies behind Rust and Zig are practically opposite poles). Language stewards have a responsibility to everyone in their existing user base and they have a responsibility to evolve the language in a ways that's consistent with the expectations they already established (if they want to keep their users that is). Expecting the designers to rework the language to bolt on features from some other language just for your project is kind of absurd. I think Loris's supposed response is actually correct here and probably the best response he could give, without knowing more about precisely what the requests were, how willing you were to contribute work yourself, etc.
Oh, please...if you haven't noticed the carpet bombing of rust advocacy on HN for more than 4 years and still in progress, you're deliberately not paying attention.
The C++ community and the Zig community seem to get along fine, so it not about looking up at the entrenched thing or down at the new thing, many orders of magnitude there and no drama.
Python, R, and Julia folks all seem to get along.
On the frontend there are a zillion things that compile to JS and even in the big camp the frameworks are split 9 ways, you get a little heat here and there over Vercel throwing big bucks or something but it's rare, generally the Svelte people and the Astro people seem to not mind when the other one front pages or whatever.
Rust is at war with the world. Maybe it can even win but it's a weird road to walk by choice.
The Zig Evangelism Task Force has supplanted Rust as the premier hypebeast. And they'll be supplanted by the NEXT BIG THING.