Ask HN: What is preventing rust from replacing c/c++?

Re:Ask HN: What is preventing rust from replacing c/c++? by AnimalMuppet on Monday July 17, 2017 @07:01PM (#14793010)

Changing languages isn't free. Rust isn't enough better than C++ for most developers (or their management) to switch.

Or, if you're more of the skeptical sort, Rust doesn't seem to be enough better. You could argue that C++ developers don't think they write code that creates memory issues very often. So they underestimate the benefits. (And the borrow checker is a different concept, so they may also overestimate the costs of switching.)

The net result, though, is that they perceive the benefits to not be worth the costs.

[ Parent | on HN ]

Re:Ask HN: What is preventing rust from replacing c/c++? by JoeAltmaier on Monday July 17, 2017 @08:35PM (#14793470)

Perhaps they estimate the benefits correctly. In that case, they may never switch.

[ Parent | on HN ]

Re:Ask HN: What is preventing rust from replacing c/c++? by AstralStorm on Tuesday July 18, 2017 @02:02AM (#14794499)

More modern styles of C++ just wholesale avoid most problems that are solved by the borrow checker. Smart and owning pointers, dynamic and checked data structures thanks to operator overloading. There are remaining warts but not bad enough in practice.

[ Parent | on HN ]

Re:Ask HN: What is preventing rust from replacing c/c++? by jjpe on Tuesday July 18, 2017 @05:39AM (#14795330)

That's not really all that relevant for most existing commercial code since legacy code tends to not get rewritten at all unless it's absolutely necessary, and thus remains stuck with the Old Ways.

[ Parent | on HN ]

Re:Ask HN: What is preventing rust from replacing c/c++? by AstralStorm on Tuesday July 18, 2017 @12:46PM (#14798001)

Indeed, but unlike a rewrite, you can refactor staying in the same language at your leisure, piece-wise.

Plus the argument was mostly pertaining to new code.

[ Parent | on HN ]