[slashdev]

I agree about quick and dirty, Python has been my goto there for over a decade.

But I find with more complex type systems and more expressive languages (which applies to both Haskell and Rust) I spend too much time thinking of which way in going to code something, what abstractions I'm going to use. Then I spend too long trying to make the compiler happy for decreasing marginal returns in reducing bugs. Then the compiler takes too long every time I want to run it. On top of all that, the tools are subpar. I like Rust, I find it so well thought out and elegant, but I still reach for Go to get things done.

All of that makes me considerably less productive. In Go I just use loops, slices, structs, and interfaces. There is usually only one obvious way to do it. It compiles right away, and I get on with my life.

It's not as pretty to look at, probably more lines of code, but it takes so much less time.

On larger teams having simple, consistently styled code is an understated advantage for code review and understanding the system (which together are probably 3/4 of the job.)

[sanxiyn]

I think it indeed heavily depends on your marginal return in reducing bugs. I agree Rust is unsuitable for most software, because rightly or wrongly, bugs don't matter in most software.

[fauigerzigerk]

Some of the bugs that Rust prevents do matter in most software but only occur in languages without GC.

In my view, Rust has a good chance of gradually replacing C++, because C++ devs don't shy away from using a large, complex language, and they can appreciate what the borrow checker does for them.

[eloff]

Yeah, that's where I use Rust now, where I previously would have used C or C++ (and if I previously needed C I always used C++ with extern "C".) These are places where I can't use Go because I need a language without a heavy runtime.

I use TypeScript for the browser and React native, because that is much better done in JavaScript land.

For short scripts I use Python.

Everything else I use Go.