Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle

freedium-mirror.cfd

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle

#21

Post by pjmlp »

kjsingh wrote: post #13
pjmlp wrote: post #11

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 d…

> 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.

Re: Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle

#22

Post by akagusu »

wakawaka28 wrote: post #20

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.

Re: Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle

#23

Post by aw1621107 »

akagusu wrote: post #22
wakawaka28 wrote: post #20

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:

    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.

[0]: https://news.ycombinator.com/item?id=40172033

[1]: https://news.ycombinator.com/item?id=36239534

[2]: https://news.ycombinator.com/item?id=41791773

Re: Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle

#24

Post by Rochus »

patchymcnoodles wrote: post #12

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 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.

Re: Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle

#25

Post by Rochus »

MattPalmer1086 wrote: post #18
rich_sasha wrote: post #15

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 tha…

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.

Re: Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle

#27

Post by nrposner »

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.

Re: Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle

#28

Post by bigyabai »

akagusu wrote: post #22
wakawaka28 wrote: post #20

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.

Your account is like 90% Rust-bashing. Have you considered getting a job?

Re: Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle

#29

Post by timeon »

patchymcnoodles wrote: post #12

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.

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.

Re: Rust Isn't the Future of Systems Programming – It's Just the Hype Cycle

#30

Post by timeon »

wakawaka28 wrote: post #20

Why is this flagged?

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.
Post reply on HN