<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>PudgePacket</author><text>&amp;gt; The extreme low level control that C++ offers and powerful metaprogramming allows for performance that even Rust cannot hope to rival.&lt;p&gt;Could you expand on this? It&amp;#x27;s a pretty strong claim.&lt;p&gt;LLVM produces very fast code and is very commonly used for c++ compilation. Rust also has access to the usual low level control suspects, inline asm, manual memory layout &amp;amp; operations, pointer shenanigans etc.&lt;p&gt;Benchmarks are never perfect but they show that rust in usually within the ballpark of c++, if not comparable: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.reddit.com&amp;#x2F;r&amp;#x2F;rust&amp;#x2F;comments&amp;#x2F;akluxx&amp;#x2F;rust_now_on_average_outperforms_c_in_the&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.reddit.com&amp;#x2F;r&amp;#x2F;rust&amp;#x2F;comments&amp;#x2F;akluxx&amp;#x2F;rust_now_on_av...&lt;/a&gt;.</text><parent_chain><item><author>alfalfasprout</author><text>&amp;quot;which is just about everything useful&amp;quot;. This statement is wildly without merit.&lt;p&gt;Sure, for the typical user facing application HN readers talk about then C++ can certainly contain vulnerabilities that are worrisome. Many performance critical applications can tolerate vulnerabilities in favor of latency.&lt;p&gt;It seems to me that the world of realtime systems including avionics, autonomous control software, trading, machine learning, and more is &amp;quot;not useful&amp;quot; as per your comment. The extreme low level control that C++ offers and powerful metaprogramming allows for performance that even Rust cannot hope to rival.&lt;p&gt;The industry &lt;i&gt;has&lt;/i&gt; moved away from C++ for plenty of these user facing use cases. Codebases like Chrome and Firefox can&amp;#x27;t just be rewritten in Rust overnight. You can try and rewrite eg; SSL libraries but that has its own host of problems (eg; guaranteeing constant time operations).&lt;p&gt;I encourage the people parroting a move away from C++ to really think about what it is that should move and what the pros&amp;#x2F;cons are. I think you&amp;#x27;ll find that many of the things at risk (i.e user facing applications) are already on their way to being rewritten in Go&amp;#x2F;Rust.</text></item><item><author>tatersolid</author><text>&amp;gt;  think if you need a very safe code, you shouldn&amp;#x27;t use the string_view or span without thinking about the potential consequences.&lt;p&gt;That’s the whole point: your caveat shows that’s it’s C&amp;#x2F;C++ which are &lt;i&gt;unsafe in their very nature&lt;/i&gt; and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful.&lt;p&gt;HPC are generally closed systems and have different threats, but the industry just needs to run (not walk) away from C&amp;#x2F;C++ for the majority of use cases.</text></item><item><author>namirez</author><text>This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn&amp;#x27;t use the string_view or span without thinking about the potential consequences. These are added to the language to prevent memory allocation and data copy for performance critical software.&lt;p&gt;Herb Sutter has concrete proposals to address this issue and Clang already supports them:
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.infoworld.com&amp;#x2F;article&amp;#x2F;3307522&amp;#x2F;revised-proposal-could-solve-longstanding-c-bugs.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.infoworld.com&amp;#x2F;article&amp;#x2F;3307522&amp;#x2F;revised-proposal-c...&lt;/a&gt;</text></item></parent_chain></comment><story><title>Modern C++ Won&apos;t Save Us</title><url>https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>fulafel</author><text>&amp;gt; The extreme low level control that C++ offers and powerful metaprogramming allows for performance that even Rust cannot hope to rival.&lt;p&gt;Rust has vastly better metaprogramming, and as much low level control, no? And many low-level things are well-defined in Rust, and undefined behaviour or implementation-defined in C++.</text><parent_chain><item><author>alfalfasprout</author><text>&amp;quot;which is just about everything useful&amp;quot;. This statement is wildly without merit.&lt;p&gt;Sure, for the typical user facing application HN readers talk about then C++ can certainly contain vulnerabilities that are worrisome. Many performance critical applications can tolerate vulnerabilities in favor of latency.&lt;p&gt;It seems to me that the world of realtime systems including avionics, autonomous control software, trading, machine learning, and more is &amp;quot;not useful&amp;quot; as per your comment. The extreme low level control that C++ offers and powerful metaprogramming allows for performance that even Rust cannot hope to rival.&lt;p&gt;The industry &lt;i&gt;has&lt;/i&gt; moved away from C++ for plenty of these user facing use cases. Codebases like Chrome and Firefox can&amp;#x27;t just be rewritten in Rust overnight. You can try and rewrite eg; SSL libraries but that has its own host of problems (eg; guaranteeing constant time operations).&lt;p&gt;I encourage the people parroting a move away from C++ to really think about what it is that should move and what the pros&amp;#x2F;cons are. I think you&amp;#x27;ll find that many of the things at risk (i.e user facing applications) are already on their way to being rewritten in Go&amp;#x2F;Rust.</text></item><item><author>tatersolid</author><text>&amp;gt;  think if you need a very safe code, you shouldn&amp;#x27;t use the string_view or span without thinking about the potential consequences.&lt;p&gt;That’s the whole point: your caveat shows that’s it’s C&amp;#x2F;C++ which are &lt;i&gt;unsafe in their very nature&lt;/i&gt; and therefore should not be used in code exposed to potentially malicious (e.g. user or network) input. Which is just about everything useful.&lt;p&gt;HPC are generally closed systems and have different threats, but the industry just needs to run (not walk) away from C&amp;#x2F;C++ for the majority of use cases.</text></item><item><author>namirez</author><text>This has been discussed extensively in the C++ community. I think if you need a very safe code, you shouldn&amp;#x27;t use the string_view or span without thinking about the potential consequences. These are added to the language to prevent memory allocation and data copy for performance critical software.&lt;p&gt;Herb Sutter has concrete proposals to address this issue and Clang already supports them:
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.infoworld.com&amp;#x2F;article&amp;#x2F;3307522&amp;#x2F;revised-proposal-could-solve-longstanding-c-bugs.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.infoworld.com&amp;#x2F;article&amp;#x2F;3307522&amp;#x2F;revised-proposal-c...&lt;/a&gt;</text></item></parent_chain></comment><story><title>Modern C++ Won&apos;t Save Us</title><url>https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/</url></story>