You can write bad code in any language, Rust included. This article is cherry-picking.
How do you know which tools are the best?
1. Come up with a set of options by doing research, talking to people who have solved similar problems before, etc.
2. Rank them by some criteria (e.g. availability of libraries, documentation, raw performance, hireability, support, quality of tooling, etc).
3. Do some prototyping in your problem domain using the top 2-3 (more if you aren't confident in your ranking) and pick whichever you like best.
4. Always be willing to change your mind down the road. Avoid the sunk cost fallacy and try not to lock yourself in too much until you're confident in your choice.
A language is not just the basic control flow operations, but includes package management, performance gotchas, correctness gotchas, standard library, library ecosystem, data representation, etc. Then there are details and edge cases that you just don't hit without months or years of hard work with a language.
My experience tells me to take choose a reasonably robust language, then stick to that language until you have an overwhelmingly compelling reason to switch.
I believe that programming language has the power to push its user to write in a certain way, not just a mere tool to convert idea to machine code.
What I learnt by writing Rust turns out to be useful when applied in other language.
My argument was:
> I believe that programming language has the power to push its user to write in a certain way
Not:
> I believe that programming language has the power to enforce its user to write in a certain way
In contrast, your argument here is more debunkable:
> You always write in same style, regardless of programming language.
You cannot ALWAYS write in the same style with disregard to your programming language choice. The black swan: Try writing GLSL and Haskell in the same style