Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle
freedium-mirror.cfdI find the comparison about being good for newcomers rather interesting. I would say none of them are easy for beginners. I don't see where C(++) can shine here. For a beginner into systems programming Go would be much easier as example. And if it's about programming in general then there are many, many more languages to choose from that are all easier to learn than C(++) and Rust.
> I don't see where C(++) can shine here [..] Go would be much easier
There is a world of difference between the complexity of C and C++. C is in principle quite easy to understand (besides some syntactic quirks), similar to Turbo Pascal back in the day. Go, on the other hand, has various features that are not so easy for beginners to understand (e.g., interfaces with all their rules, or value vs. pointer receivers with all their complex consequences). Since the introduction of generics, the complexity of Go has taken a leap forward, moving even further away from C and closer to C++ in terms of complexity.
Personally, coming from higher level languages (Python, TS, Java, C#) I've found Go by far the easiest to get productive in.
You're probably right that for trivial examples C is, in principle, the simplest to learn and understand. But in reality, non-trivial C projects come with complex build systems, makefiles, macros, endless compiler flags... I've found it pretty hard to, for example, fork a moderately-sized C project and modify it. Hell sometimes even building it is a challenge when you don't understand make/build system errors and how to set up and configure C projects.
Go, however, i could just get up and running. Simple to use modules, simple to import dependencies, simple to build projects, great centralized documentation. Now granted do i fully understand all the nuances of things like pointer receivers and generics? No, but i don't really understand memory allocation in C either to be quite honest, and I've spent more time trying to understand C in my life than i have Go (please understand: extremely little in both cases)
Rust does seem similarly impenetrable honestly, except that it seems much easier to build and manage Rust projects. But I definitely can't even just read Rust code and get it the way i can Go (or even C)
Programmers using high-level languages develop models about how programming works, particularly around memory management, type safety, and abstractions. These models don't transfer to C, so they must be "unlearned" to some degree, which research shows is often harder than learning from scratch. Programmers accustomed to Python, TypeScript, or C# face specific conceptual "paradigm shifts" when switching to C such as manual memory management (as you said), pointer discipline and lack of abstraction (you have to take care of many things which the high-level language offered or took care of).
Programming beginners (to whom my statement applied) lack preconceived notions about what programming "should" be like. They build their mental models around C's paradigms from the start, avoiding the cognitive dissonance experienced by those expecting automatic memory management or rich standard libraries and integrated build systems.
I suppose, but i tried to learn C before i tried to learn anything else. If it had been my only option, i wouldn't have stuck with programming (in fact i didn't, several years passed between trying to learn C and successfully learning Typescript)
Well I know several GC-based languages but for others:
C was easy to learn, hard to use. C++ was hard to learn, hard to use. Rust was hard to learn, easy to use. Rust was only one of those I was able actually learn and use.
I sort of thing the article has a point, though I disagree with the arguments. C++ 20 years ago was simple, sure. Today? I think it's on par with Rust. And both kind of have a simple core you can stick to if you like.
Saying project directory structure is complex is IMO crazy, since a fair comparison would be to general package/dependency management on C++ which is a brain explosion.
Where they do have a point is that I would hope, we can create a language that is at the same time fast, safe and simple to use. Right now we have a tradeoff triangle. Rust is safer than C++, about as fast, and arguably harder to use. Something gives.
The article absolutely has a point that C is trivial to pick up, and surely that fueled the explosion of software.
C++ was not simple 20 years ago! We had template metaprogramming, and regular arguments about what subset of the language we could all agree on to safely use. Nobody understood it all even back then.
Right. There were even regular puzzle columns in magazines where people had to figure out what a piece of C++ actually did. This is how template metaprogramming eventually came to light, when a few very clever minds figured out how to use it to implement even conditions and loops, for example - possibilities that even the inventor of the language had not anticipated. So, C++98 was in no way simple, but definitively much more simple than C++ today.
Leaving the LLM writing aside, this argument just doesn't hold together. It wants to say 'Rust has these flaws, therefore it will not replace C/C++', but doesn't make (or doesn't realize it is necessary to make) the intermediary claim 'C/C++ do not have these flaws/Rust does not provide enough other attractive features to overcome these flaws'.
It's also engaged in an odd two-step where it conflates C and C++, championing C's simplicity in contrast to Rust's complexity... and then just doesn't address C++'s complexity, as though it's interchangeable with C. The notion that Rust developers are running into quirks with tooling and this is reason not to use it in preference to C++ is ludicrous.
Regardless of the article being AI generated or not, I would rather vote for automatic resource management, with type systems improvements for low level coding, regardless of the form, between affine, linear, effects, proofs, dependent types, there is plenty to choose from.
The note that Rust cannot fully replace C++ as long as it depends on using it for its key compiler backends.
Finally even if it is a bubble, AI driven programming is making specific languages irrelevant, eventually only AI language runtimes will need fine grained control how everything works, at the bottom layer.
Maybe the future is an AI language compiler generating machine code directly, with similar productivy as Xerox PARC workstations, Lisp Machines, or Bret Victor ideas.
> only AI language runtimes will need fine grained control how everything works
Rust can win against CPP if AI can understand its docs better than CPP's :D
Why when the end goal is to get machine code directly, or agents that act on their own?
Generating current programming languages is only a transition step, just like Assembly programmers were suspicious of the first optimizing compilers and expected multiple steps, having the compilers generating Assembly they could inspect, and only then run the Assembler on that.
We need to take the Alan Kay point of view, not what AI tools can do today, rather what they might look a few decades down the line.
> Rust shines when memory safety is critical (OS kernels, cryptography), but in most real-world scenarios, the trade-offs don't justify the pain.
You've got to be kidding me...
Memory safety is a huge benefit in myriad scenarios. I would call it the rule, not the exception. Pair that with competitive performance and you have something really compelling. I don't know enough Rust to really speak to its tradeoffs, but the above just seems like a dumb point to try to make.
And regarding the "hype cycle," Rust is old enough now to have survived many actual software hype cycles, so this claim of us finally getting to the middle of it now, which isn't really justified in the article, also doesn't seem to stick.
A steep learning curve mean you learn a lot (y-axis) in a short time (y-axis). So the graph goes up fast (steep).
When making bold clickbaity claims like the author does, at least get your terms right...
No, the phrase a "steep learning curve" implies that learning is difficult and therefore progress may be slow.
It is actually a misnomer. Your interpretation of the graph is correct, but the phrase actually means the opposite.
If Hype wasn't the pill then in no dimension would Typescript be as popular as Java
Why is this flagged?
Because there is a coordinated effort on HN to suppress any dissent view on certain topics.
Rust is one of these topics. If you want to be flagged and down voted, just write a critic about Rust.
Even tell about this is a motive to be down voted.
Sadly, this appears to be true. For whatever strange reasons, Rust (and Zig) are glazed and hyped beyond any sense and way out of proportion to their language rankings (see TIOBE)[1]. Rust is not even in the TIOBE top 10. Zig is barely in their top 50.
These two languages look like they have a weird kind of "protected and special status" on HN. Other programming language don't get anything like the push and special treatment that these do.
[1]: https://archive.md/sJRyf (TIOBE Index Novemeber 2025)
> If you want to be flagged and down voted, just write a critic about Rust.
Nonsense. It's not all that hard to find well-received stuff on HN critical of Rust (e.g., from a quick search there's [0, 1, 2] and plenty more, especially around async and/or deps). The key is to write substantive/thoughtful/constructive criticism. In fact, that applies in general - substantive/thoughtful/constructive articles/comments are much more likely to be well-received no matter their topic.
This article does touch on some of Rust's weaknesses/pain points, but does an absolutely atrocious job of doing so. Right off the bat you have this:
Yes, Rust's compile times can be long, but if you wanted to demonstrate that then this is pretty much the worst possible way to do so as not only is it not comparing apples to apples (it's comparing a debug build to a release build) but we don't even know what is being compiled!Example comparison (small benchmark): # C++ (g++) $ time g++ main.cpp -o main real 0m0.4s # Rust (cargo build --release) $ time cargo build --release real 0m9.7sAnd it's pretty much downhill from there. Like this:
> Suddenly, the compiler starts screaming:
Well yes, that's an error. It's also wrong in C++. In fact, C++26 makes (some forms?) a hard error as well, so C++ is moving to match Rust in this respect.error[E0515]: cannot return value referencing local variableThe code organization example is yet again not an apples-to-apples comparison. It's also straight up wrong to boot.
The migration decision tree is inconsistent as well. If "memory safety is your #1 priority", then C++ with sanitizers is definitely not a viable option.
So on and so forth. If you want to write Rust criticism and be received well, this is definitely not the way to do so.
[0]: https://news.ycombinator.com/item?id=40172033
Much more superficial stuff flies on this site and even gets hundreds of upvotes. You haven't explained why this is flagged.
> Much more superficial stuff flies on this site and even gets hundreds of upvotes.
Sure, but the fact that one thing gets one kind of reception but another thing gets another tells you little since HN is not a monolith. Different people read different things, have different thresholds for flagging stuff, so on and so forth.
> You haven't explained why this is flagged.
My comment was not an attempt to explain why the post was flagged in the first place?
It's not like I can give a definitive reason for its flagging either, since a) I don't know the precise manner in which HN's software determines whether something is flagged or not, b) I can't read the minds of everyone who flagged the article, let alone try to determine whether their reason for flagging was "valid" (assuming I'm even qualified to make that determination), and c) I have no idea if the moderators manually flagged this article. I can make guesses, sure, but it's not like my guesses would be worth any more than yours.
If you see something is flagged and think it should not be, the best way to try to resolve the issue is to either vouch for it, or if that doesn't work, email the moderators.
I don't think I have enough points to vouch for anything. The rules about how many points are required to do things seem to promote a hive mind phenomenon.
If you're not trying to explain why this thing is flagged, or at least why it isn't flagged, idk why you are in this thread. But it's all good.
> I don't think I have enough points to vouch for anything.
Based on this [0] (and a few other random comments search engines pulled up) the points threshold for vouching is supposedly 31. It does appear that I misunderstood the vouching functionality, though, since apparently it's supposed to counteract [dead] posts, not [flagged]. My mistake!
> The rules about how many points are required to do things seem to promote a hive mind phenomenon.
As with many things, it's a tradeoff. Having a points threshold also makes it harder to abuse new accounts to manipulate flags/votes/etc., so there's no free lunch here.
> If you're not trying to explain why this thing is flagged, or at least why it isn't flagged, idk why you are in this thread.
My intent was very specifically to push back against the claim that Rust criticism is a surefire way to get downvoted/flagged. The tl;dr is that good criticism of Rust is well-received, and this article is not a good critique and so it's not all that surprising that it was not well-received.
[0]: https://github.com/minimaxir/hacker-news-undocumented/blob/m...
I'm inclined to agree with him. I've had comments mass downvoted here and on Reddit over Rust criticism. It's not even symmetrical either, because the threshold to be able to downvote is 500 points. I'll never get to that level (or stay there) unless I stick to very milquetoast takes on things. I shouldn't care but it's unfair and annoying. At one point I even lost the theme feature because I made a few unpopular comments in a row and got like 50 downvotes in a short time. The way the votes are tabulated is also confusing. It is not one to one. It's like, the downvoted posts contribute more than the sum total of the downvotes, based on the replies.
> I'm inclined to agree with him. I've had comments mass downvoted here and on Reddit over Rust criticism.
I mean, I'm not trying to say that (even good, unfortunately) Rust criticism will never be at risk of downvotes/flagging; I'm just saying that Rust criticism is not guaranteed to garner downvotes/flags - or at least, not to the extent implied in the particular wording. That's not to comment on your specific situation, either.
> It's not even symmetrical either, because the threshold to be able to downvote is 500 points.
If anything, shouldn't that weigh in favor of comments being upvoted, since there's no threshold to vote something up?
> The way the votes are tabulated is also confusing. It is not one to one. It's like, the downvoted posts contribute more than the sum total of the downvotes, based on the replies.
IIRC the vote display on comments has a floor of -4, but further downvotes continue to affect your karma nevertheless.
I had the impression that there's a bit of the opposite at play as well - upvotes beyond some threshold stop contributing 1:1 to your total karma. Not sure if that's just my faulty memory though.
Ok let's discuss the article. Can you give example, from the article, you like?
Your account is like 90% Rust-bashing. Have you considered getting a job?
It is just rage-bait without content. Like made-up benchmark without specifying what it was comparing. Showing code that actually works and then providing error message that is not related or caused by that code. Etc.
Presumably because it's LLM-generated, as other comments here are pointing out.
How does anyone know that? Seems like an unfalsifiable accusation you can hurl at anything to dismiss it.
If it helps, GPTZero rates the text as 99% AI-generated. In addition, the whole article has a patter that's very typical of LLM-writing, fond of short phrases and reversals. You might also consider that the medium page it's pulled from posts short daily articles on programming, full of surface-level takes on language and technology choice without going into serious technical detail or providing biographical detail about the author, their work, or their projects. Or, most clearly, you might notice that those articles are replete with ASCII flowcharts--something a human writer would almost certainly not bother with in favor of just drawing them, but which is very easy for an LLM to output.
All of this points quite clearly to this being LLM-generated. But, as I pointed out in my other comment, as have others above, it's just not well argued. The points are shallow and don't adequately support the claims made. It looks to me very much like someone churning out posts on surface-level topics by prompting an LLM, either not having the expertise to tell the quality of the argument or just not bothering.
As another comment pointed out, this and all of their other posts are AI generated.
This is AI-generated, and seems to just be the standard-flavor C++ cope. Not sure why I should spend any time refuting it or reconsidering my system architecture.