5 ms·

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

bigyabai 10mo ago
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.
- ls-a 10mo ago
  [flagged]
  - bigyabai 10mo ago
    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.
    - ls-a 10mo ago
      [flagged]
      - bigyabai 10mo ago
        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.
        aw1621107 10mo ago
        > 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 https://github.com/cppfastio/fast_io
        ls-a 10mo ago
        [flagged]
      - DemocracyFTW2 10mo ago
        > 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?
WCSTombs 10mo ago
> 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.
josevalerio 10mo ago
As another comment pointed out, this and all of their other posts are AI generated. https://cachecowboy.medium.com/ https://cachecowboy.medium.com/
pjmlp 10mo ago
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.
- kjsingh 10mo ago
  > 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
  - pjmlp 10mo ago
    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.
patchymcnoodles 10mo ago
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.
- Rochus 10mo ago
  > 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.
  - queenkjuul 10mo ago
    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)
kjsingh 10mo ago
If Hype wasn't the pill then in no dimension would Typescript be as popular as Java
rich_sasha 10mo ago
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.
- MattPalmer1086 10mo ago
  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.
  - Rochus 10mo ago
    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.
7bit 10mo ago
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...
- MattPalmer1086 10mo ago
  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.
wakawaka28 10mo ago
Why is this flagged?
- nrposner 10mo ago
  Presumably because it's LLM-generated, as other comments here are pointing out.
  - wakawaka28 10mo ago
    How does anyone know that? Seems like an unfalsifiable accusation you can hurl at anything to dismiss it.
    - nrposner 10mo ago
      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.
- akagusu 10mo ago
  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.
nrposner 10mo ago
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.

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.

ls-a 10mo ago
[flagged]
- bigyabai 10mo ago
  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.
  - ls-a 10mo ago
    [flagged]
    - bigyabai 10mo ago
      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.
      - aw1621107 10mo ago
        > 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 https://github.com/cppfastio/fast_io
        ls-a 10mo ago
        [flagged]
    - DemocracyFTW2 10mo ago
      > 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?

WCSTombs 10mo ago

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

josevalerio 10mo ago

As another comment pointed out, this and all of their other posts are AI generated. https://cachecowboy.medium.com/ https://cachecowboy.medium.com/

pjmlp 10mo ago

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.

kjsingh 10mo ago
> 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
- pjmlp 10mo ago
  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.

patchymcnoodles 10mo ago

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.

Rochus 10mo ago
> 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.
- queenkjuul 10mo ago
  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)

kjsingh 10mo ago

If Hype wasn't the pill then in no dimension would Typescript be as popular as Java

rich_sasha 10mo ago

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.

MattPalmer1086 10mo ago
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.
- Rochus 10mo ago
  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.

7bit 10mo ago

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

MattPalmer1086 10mo ago
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.

wakawaka28 10mo ago

Why is this flagged?

nrposner 10mo ago
Presumably because it's LLM-generated, as other comments here are pointing out.
- wakawaka28 10mo ago
  How does anyone know that? Seems like an unfalsifiable accusation you can hurl at anything to dismiss it.
  - nrposner 10mo ago
    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.
akagusu 10mo ago
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.

nrposner 10mo ago

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.