What this prompt does
This prompt produces a balanced, conditions-based decision between Rust and Go for a specific project rather than a religious verdict. You describe the [project_description] and [team_profile], and the AI works through ten dimensions: performance needs weighing [performance_needs] against [go_performance], development speed and time-to-market for [deadline], error handling for [error_scenarios], concurrency for [concurrency_needs], ecosystem maturity, the learning curve, memory-safety versus garbage-collection trade-offs, deployment, hiring, and a side-by-side code comparison. It is built to give an honest recommendation you can actually defend.
The variables anchor the recommendation to your reality rather than generalities. [team_skills] and [deadline] weigh productivity against raw performance, [required_libraries] checks ecosystem coverage for both languages so you are not surprised later, and [comparison_feature] drives a concrete code comparison so the trade-off is not abstract hand-waving. Crucially, the prompt asks for an explicit confidence level and the specific conditions that would change the recommendation, so you understand not just the answer but exactly when it would flip the other way.
When to use it
- Choosing Rust or Go for a new backend, data pipeline, or performance-sensitive service
- Justifying a stack decision to a team or stakeholders with real, written reasoning
- Weighing a tight deadline and an unfamiliar team against raw performance needs
- Checking whether both languages have mature libraries for all your dependencies
- Comparing the error-handling and concurrency models for your specific workload
- Getting a confidence level plus the conditions that would change the call later
Example output
You get a structured comparison across all ten dimensions, each weighing Rust against Go for your stated project and team rather than in the abstract. It includes a side-by-side code sample implementing your [comparison_feature] in both languages so the ergonomic differences are concrete, then a final recommendation with an explicit confidence level and the specific conditions, such as a slipped deadline or a harder latency target, that would change the verdict. Because each dimension is weighed against your stated [team_skills] and [deadline], the conclusion is grounded in your situation rather than a generic benchmark comparison.
Pro tips
- Be honest in
[team_profile]and[team_skills]; the learning-curve weighting depends entirely on real, current experience - State
[performance_needs]concretely with latency targets and throughput so the performance section is not hand-wavy - List your actual
[required_libraries]so the ecosystem check reflects your real dependencies and not assumptions - Set a realistic
[deadline]; time-to-market often outweighs raw performance for an MVP under pressure - Pick a
[comparison_feature]representative of your core workload, not a toy example that hides the real friction - Describe
[concurrency_needs]precisely, since Go's goroutines and Rust's async models shine under different connection and CPU mixes - Pay close attention to the conditions-that-would-change section; it tells you exactly what to re-evaluate later
