The one thing that would put rust over the top right now is something along the lines of gofmt - something simple, with zero configuration, that can be run on commit or even save.
Right now almost every company and even separate teams develop their own coding conventions document and configure their tools and infrastructure for it. But if all programmers agree that "coding style does not matter as long as it's consistent" and every one is willing to accept a project's coding style when joining that project, why not pick one style for all and put it into programming languages themselves. I imagine a lot of paperwork and human time would be saved.
I find gofmt to be too opinionated about certain things and I will never use it for my go programs.
Or just clean up some nags so that version control behaves better. But if the only option is not running it at all or having all the code automatically fit to whatever the people On High have deemed to be visually pleasing? Yeah...
That seems good in theory.
The point of an automatic formatter isn't to make the code look pretty. It's to make the code non-ugly, with as little effort as possible. Obviously, there will be cases where the formatter screws up and writes out something pretty ugly. The point is to train yourself to ignore these, because honestly time spent looking at, angsting over, and fixing bad formatting is about the worst possible use of your development time. Instead you could be thinking about solving a problem that hasn't been solved before, or making the product easier for a user to use, or refactoring semantic issues in the code that trip up developers.
2) Everyone and their mother is doing code reviews now, and a lot of code reviews get (very visibly) bogged down by style disputes.
3) indent and his modern friends (eg clang-format) generally only answer trivial whitespace questions, and not even things like method capitalization. gofmt is the obvious extension of indent.
The main issue for me is that your code reviwer isn't looking at the code from my company. So why should I give a damn what they think about how spaces around the parens of a function call should look like in the code I'm editing?
I'm not convinced that this should leave the bounds of a project. Within that, sure! Let's put a .rustformat right next to .gitignore, and whatever your source discombobulation utility is called just takes its hint from there. Certainly nothing wrong with a language having a good indenter, doc tool and linter in the core distribution. But one language, one style, one tab width!?!
This is especially annoying when you've got a pretty unified style across all other algol-/C-ish languages, yet can't keep this in your newest one. For the sole reason of pleasing some community that'll never see one line of your code.
The point isn't to have a "house" style, it's to have an "everything" style.
Making it optional or configurable defeats the purpose.
If you want to solve the problem that people are writing in different styles and there should be one true style for a language, why? You're bound to get something wrong in your style initially, and it will be annoying from then on, and hard to change. It actually seems the antithesis to how Rust was developed, which was to keep trying things to see what worked.
And gofmt is generally less bound to the style than, say, PEP8 since everyone could trivially mechanically update their source to the new standard.
All kept equal by hatchet, ax and saw…
It's rarely a good idea to reproduce the same patterns in two different languages (except for things that are common anyway, like indentation etc.).
And the main argument for a language-global code style is that you don't need to teach new commers (to your company/project) which code style you follow, you don't need to have long discussions about whether the article #36 is being respected in that last commit, if the code style version you had is up to date, etc.
One great example: Python and PEP8. It's the standard, everybody accepted it. That means that all libs use it AND (almost) all companies use it internally, which makes friction between different modules from different sources minimal.
Of all the C pretty-printers I tried (about a year ago), clang-format came closest but none were idempotent on the codebase I threw at it.
go fmt is idempotent, which means I use it in an editor save hook. I got used to the convenience, so now I miss an automatic formatter when writing other languages.
gofix: way more useful!