[xondono]

Another point is that using rust is great for products, but not so much for PoCs, since the compiler will complain about most ‘hacks’ to release early, or even refuse to compile.

I have not much experience with go, but my feeling is that it should be faster to have something working, and then if it’s worth it (e.g. if it needs high performance with concurrency), migrate to rust.

[capdeck]

Yes and no. Yes, Rust requires more "mental cycles" to think upfront about the design, even of a simple tool. But, as they say, nothing is more permanent than temporary. A tool that you write as a one off, before long, ends up running critical infrastructure in production.

We all have been in the situation where we quickly put something together. With Rust -- you internalize some of the things you know the compiler will demand -- so tenth time you write something in Rust will be faster. But the beauty is that Rust compiler will force you to _gradually_ fix the design of your tool and the extra time you spend fixing it pays dividends when this code eventually becomes something everyone relies on.

Coding in Rust is like an investment: it requires some commitment and slows you down initially (for the right reasons!), but pays huge dividends and return grows exponentially over time.

[xondono]

> Coding in Rust is like an investment: it requires some commitment and slows you down initially (for the right reasons!), but pays huge dividends and return grows exponentially over time.

Kind of my point. Sometimes you don’t want to make an investment, sometimes you just need something to show.

[dralley]

You can cut corners plenty easy. .unwrap(), .expect() and so forth. The great thing about that is, all the places where you cut corners are blatantly obvious and searchable.