<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>pdpi</author><text>&amp;gt; I do not care about safety (memory or otherwise) - my code doesn&amp;#x27;t take arbitrary input, run on shared hardware, do much of anything over networks or have memory safety crashes.&lt;p&gt;This is a common misconception — safety and security are different things. If your simulations make extensive use of parallelism (and I can only assume they do), memory safety also helps you ensure correctness.&lt;p&gt;I can absolutely appreciate that you might lose other things to achieve that, and that this is not a trivial tradeoff to make (and I&amp;#x27;ll take you on your word that it is the wrong tradeoff for you!), but it&amp;#x27;s not as clear cut as &amp;quot;I don&amp;#x27;t need safety features because I have no security exposure&amp;quot;.</text><parent_chain><item><author>keldaris</author><text>I mostly use C++ for numerical simulations in physics and associated code (analysis, some visualization, etc.). That means my primary consideration is the ease and convenience of writing high performance code for a narrow set of hardware. I care about the quality of tooling, especially for performance analysis (including things like likwid [1]) and GPGPU computation. I do not care about safety (memory or otherwise) - my code doesn&amp;#x27;t take arbitrary input, run on shared hardware, do much of anything over networks or have memory safety crashes.&lt;p&gt;From this rather narrow point of view, Rust does very little to help and quite a lot to hinder me. Rust is very much about memory safety - an issue extremely far down my list of concerns - and to me the borrow checker is an anti-feature I&amp;#x27;d love to turn off. None of this is in any way an indictment of Rust - it looks like a very well designed language that knows what it wants to accomplish. It just happens to want the exact opposite things from what I want, and that&amp;#x27;s fine. I know I&amp;#x27;m in a weird minority (most of the people who think like I do seem to be game engine developers).&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;RRZE-HPC&amp;#x2F;likwid&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;RRZE-HPC&amp;#x2F;likwid&lt;/a&gt;</text></item><item><author>dgellow</author><text>&amp;gt; reading this has further convinced me that, for all of its disadvantages, I much prefer C++ to Rust for my needs.&lt;p&gt;What are your needs, if I may ask? I&amp;#x27;m not asking this to start a thread &amp;quot;rust&amp;#x2F;C++ is better&amp;quot;, I&amp;#x27;m just curious regarding situations in which someone decides that one language matches their needs more than another, it&amp;#x27;s always interesting to see what boundaries people consider for those decisions.</text></item><item><author>keldaris</author><text>This is a wonderfully written comparison benchmark and it deserves attention even for that reason alone. It knows its target audience, explains what&amp;#x27;s going on succinctly but completely, and avoids most of the usual benchmark pitfalls that result in comparing apples to oranges. Great job.&lt;p&gt;The one glaring issue that is ignored is the floating point model used. I understand Rust still doesn&amp;#x27;t have a usable equivalent to -ffast-math, so I assume it wasn&amp;#x27;t used for that reason. Some discussion of whether it&amp;#x27;s permissible in this algorithm (I believe so?) and how much advantage that might give to C++ seems crucial when performance is a priority.&lt;p&gt;Ironically, reading this has further convinced me that, for all of its disadvantages, I much prefer C++ to Rust for my needs. I&amp;#x27;m sure others will draw the opposite conclusion and that&amp;#x27;s great. Rust is a language that clearly knows what it wants and if your priorities are aligned with that, the performance gap is shrinking and implementation-related reasons to avoid it are rapidly decreasing in number.</text></item></parent_chain></comment><story><title>Comparing Parallel Rust and C++</title><url>https://parallel-rust-cpp.github.io/introduction.html</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>filmor</author><text>When I was working in LQCD (lattice quantum chromodynamics), people were fighting quite a bit with corrupted memory, which only resulted in a crash in the best of all cases, usually it led to very or (worse) slightly weird results.</text><parent_chain><item><author>keldaris</author><text>I mostly use C++ for numerical simulations in physics and associated code (analysis, some visualization, etc.). That means my primary consideration is the ease and convenience of writing high performance code for a narrow set of hardware. I care about the quality of tooling, especially for performance analysis (including things like likwid [1]) and GPGPU computation. I do not care about safety (memory or otherwise) - my code doesn&amp;#x27;t take arbitrary input, run on shared hardware, do much of anything over networks or have memory safety crashes.&lt;p&gt;From this rather narrow point of view, Rust does very little to help and quite a lot to hinder me. Rust is very much about memory safety - an issue extremely far down my list of concerns - and to me the borrow checker is an anti-feature I&amp;#x27;d love to turn off. None of this is in any way an indictment of Rust - it looks like a very well designed language that knows what it wants to accomplish. It just happens to want the exact opposite things from what I want, and that&amp;#x27;s fine. I know I&amp;#x27;m in a weird minority (most of the people who think like I do seem to be game engine developers).&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;RRZE-HPC&amp;#x2F;likwid&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;RRZE-HPC&amp;#x2F;likwid&lt;/a&gt;</text></item><item><author>dgellow</author><text>&amp;gt; reading this has further convinced me that, for all of its disadvantages, I much prefer C++ to Rust for my needs.&lt;p&gt;What are your needs, if I may ask? I&amp;#x27;m not asking this to start a thread &amp;quot;rust&amp;#x2F;C++ is better&amp;quot;, I&amp;#x27;m just curious regarding situations in which someone decides that one language matches their needs more than another, it&amp;#x27;s always interesting to see what boundaries people consider for those decisions.</text></item><item><author>keldaris</author><text>This is a wonderfully written comparison benchmark and it deserves attention even for that reason alone. It knows its target audience, explains what&amp;#x27;s going on succinctly but completely, and avoids most of the usual benchmark pitfalls that result in comparing apples to oranges. Great job.&lt;p&gt;The one glaring issue that is ignored is the floating point model used. I understand Rust still doesn&amp;#x27;t have a usable equivalent to -ffast-math, so I assume it wasn&amp;#x27;t used for that reason. Some discussion of whether it&amp;#x27;s permissible in this algorithm (I believe so?) and how much advantage that might give to C++ seems crucial when performance is a priority.&lt;p&gt;Ironically, reading this has further convinced me that, for all of its disadvantages, I much prefer C++ to Rust for my needs. I&amp;#x27;m sure others will draw the opposite conclusion and that&amp;#x27;s great. Rust is a language that clearly knows what it wants and if your priorities are aligned with that, the performance gap is shrinking and implementation-related reasons to avoid it are rapidly decreasing in number.</text></item></parent_chain></comment><story><title>Comparing Parallel Rust and C++</title><url>https://parallel-rust-cpp.github.io/introduction.html</url></story>