Hacker News Reader

Comment by sfkdjf9j3j | Hacker News Reader

Can you elaborate on the "propaganda" comment?

Rust users have a reputation for being eager to promote their language. There's a running joke of a "Rust Evangelism Strike Force" that roams the internet looking for places to "Rewrite it in Rust" and this is, in my experience, at least partially true.

The rust evangelism strike force seems to be matched only by the rust criticism strike force - the rub of it is that once these things get started they seem to be pretty much self-sustaining, with every Rust discussion immediately attracting two large groups, each of which are only there to argue with the other. Overall it makes everyone look bad, but certainly has the impact of making it more difficult to find reasoned discussion around Rust's advantages and shortcomings.

There is a similar phenomena around Microsoft, with nearly every news item about them attracting two such camps, so this news item happens to find itself at a rather unhappy intersection!

For what it's worth, as someone who's working on a first project in Rust right now, the actual Rust documentation and direct Rust community seem to be friendly and helpful. It's only in more 'neutral' discussion forums like here where most things about Rust devolve into trench warfare. I also feel that, subjectively, the core Rust communities (e.g. the rust-lang forums) are pretty honest about identifying places where Rust or its tooling currently fall short (plenty of "I don't know that there's a good way to do this right now.").

Attract people with promises based on unwarranted denigration of other technologies. They should present appropriate, independent studies instead, not just claim something. In the article itself you can read that even Microsoft with its billions of lines of C++ code will certainly never switch to Rust. And in C++ 23 something similar to what is not even thought through in Rust today is also planned.

> And in C++ 23 something similar to what is not even thought through in Rust today is also planned.

Source? The closest thing in C++ to what Rust offers today is the C++ Core Guidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines but these are best-effort in nature and do not have a goal of comprehensively ensuring soundness or memory-safety.

And I'm not sure why you're implyng that the Rust featureset "isn't even thought through" when the Rust Belt project has been doing a lot of work on modeling it in a principled and clearly-understandable way, and this has already contributed usefully to the design of newer Rust features.

E.g. https://github.com/isocpp/CppCoreGuidelines/blob/master/docs...

As mentioned by your parent, matching Rust’s abilities here is a non-goal for this project. Still very glad to see it!

There are a lot of mechanisms in C++ to avoid the issue Rust want's to solve with the borrow checker altogether. And there are proposals going in the same direction as the borrow checker. But in the end, human error can somehow circumvent all these security mechanisms, no matter how much hoopla they are praised today.

https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

> And in C++ 23 something similar to what is not even thought through in Rust today is also planned.

I'll believe it when I see it. The C++ committee consistently fails to deliver on safety features.

Reply on news.ycombinator.com