I 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 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.
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.
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.
> 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:
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.7s
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!
And it's pretty much downhill from there. Like this:
> Suddenly, the compiler starts screaming:
error[E0515]: cannot return value referencing local variable
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.
The 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.
> 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.
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.
Speaking of manic this is the third time you completely re-write your reply in a few minutes. Relax. Rust is just a faulty programming language not a religion.
Again - there's nothing to refute. The only accusation in the video is that there is some grand conspiracy against C++ users, which would give Chris Lattner a belly laugh.
If it is you recording that video, I hope you get over it. You can find a better way to process your grief than complaining on all three of your HN accounts.
> If it is you recording that video, I hope you get over it. You can find a better way to process your grief than complaining on all three of your HN accounts.
Based on the profile pic and the other videos on the channel, I think it's reasonable to conclude that the channel owner is also the author of the C++ fast_io library [0]. They've been quite vocal about their dislike of Rust (among other things) over the past few years, so I wouldn't expect that to change any time soon.
No comment on whether ls_a is or isn't connected to the channel owner; just thought I'd give a bit more background on the video uploader.
I 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 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.
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.
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.
> 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!And 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.The 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
[1]: https://news.ycombinator.com/item?id=36239534
[2]: https://news.ycombinator.com/item?id=41791773
As another comment pointed out, this and all of their other posts are AI generated.
https://cachecowboy.medium.com/
> 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.
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.
Refute this https://www.youtube.com/watch?v=hkNLVQHZHk8
There's nothing to refute. It's a garden-variety panic that was identified and fixed.
The person recording that video sounds manic and doesn't make any points besides their own feeling of prejudice. It basically confirms my point above.
Speaking of manic this is the third time you completely re-write your reply in a few minutes. Relax. Rust is just a faulty programming language not a religion.
> Speaking of manic this is the third time you completely re-write your reply in a few minutes
Speaking of manic you're the one who checked how many rewrites there were within a few minutes so who's manic?
Again - there's nothing to refute. The only accusation in the video is that there is some grand conspiracy against C++ users, which would give Chris Lattner a belly laugh.
If it is you recording that video, I hope you get over it. You can find a better way to process your grief than complaining on all three of your HN accounts.
> If it is you recording that video, I hope you get over it. You can find a better way to process your grief than complaining on all three of your HN accounts.
Based on the profile pic and the other videos on the channel, I think it's reasonable to conclude that the channel owner is also the author of the C++ fast_io library [0]. They've been quite vocal about their dislike of Rust (among other things) over the past few years, so I wouldn't expect that to change any time soon.
No comment on whether ls_a is or isn't connected to the channel owner; just thought I'd give a bit more background on the video uploader.
[0]: https://github.com/cppfastio/fast_io
[flagged]