Hi Rust Family,

I am in the planning stage of what will be a large, expensive, long-lived project at ${DAYJOB} and need to make some choices concerning our tech stack that will have serious consequences for the organization. Our current team of 5 people is made up of experienced programmers (average 8 years in industry) who I would consider to be of average ability in both C++ and Rust. Performance and integration are critical for our app; the latency incurred by garbage collection or a heavy runtime are unacceptable, and we cannot rewrite all our dependencies (mostly C libraries). This seems to leave us with few options other than writing in Rust or C++.

Although I think Rust is the right choice for this project, a couple of team members have expressed concern about the cost in development speed needed to get Rust's static checks. My experience is that Rust's superior error handling and error reporting more than justify the need for careful initial design of a Rust app, but the team members express unease with issues like #25860 Implied bounds on nested references + variance = soundness hole.

I looked into #25860, and this particular issue is worrisome because it has been known for a decade, its impact on the ecosystem is unknown, and the Rust team has not communicated to the community a concrete plan to address it. The Rust team has communicated that a fix will be attempted after the next-generation trait solver is in production, but it is difficult to identify which specific features of the next-generation solver enable a fix and how specifically those features will be used. Nobody on my team is an expert in type systems and we aren't qualified to judge if a solution is theoretically possible even with industry experts working on it. No (reasonably-expressive) safe subset of the language or other workaround for the issue has been identified, leaving us with a difficult decision. Although I have pointed out to my teammates that Rust absolutely does offer static guarantees over C++ (see RustBelt: Securing the Foundations of the Rust Programming Language) they remain unconvinced that these guarantees are strong enough today to justify going with Rust over C++.

In light of these things I need to take the team's concerns seriously. Since my role is more "technical intermediary between devs and management" than actual developer, I'm not in a position to override the team's preferences without strong evidence that they are misguided. Is there any information (especially concerning #25860 specifically) that I should be made aware of?

5 posts - 5 participants

Read full topic