I worked at a shop where there was some Ruby code and autoformatting was argued against from one of the senior tech leads because "[ruby] wasn't designed for an autoformatter. go was built that way"

Absolutely blew my mind. I love go fmt, prettier, black, etc and cannot understand why people still love to argue over styling at this point. I get that he was saying the formatter ships with Go but I don't subscribe to the idea that you can't use an opinionated formatter because the language authors didn't make one.

I can kind of understand it. If it's a first class part of the language, then it's never going to get painted into an ugly corner.

As a nearly related example, the LESS css pre-processor language was developed prior to `calc()` expressions. As a result, the LESS language parses arithmetic expressions. So `calc(10em + 10px)` compiles to `calc(20em)`. So in order to do `calc()` expressions, you have to use nasty hacks like `calc(10em ~"+" 10px)`. If LESS "shipped" with CSS, this wouldn't have happened.

I see your point. I think that's a little apples-to-oranges because LESS transpiled to CSS - it wasn't a formatter for CSS.

In the analogy, there may be a new language feature that breaks assumptions made by a 3rd party code formatter.

I don’t think it’s about being opinionated so much as being configurable. If you can change its behavior then sooner or later you will find someone who insists you do, and then you don’t actually have a standard anymore.

I like the authoritarian approach of go fmt and the strong idioms in Golang generally. Maybe because I lost many an hour arguing about the correct way to configure PerlTidy, only to have my hard-won righteous perfectionism destroyed when everyone joined the Cult of Moose.

SML, D, etc., are compiled GC languages but not in wide use. These days you can make a good argument for .NET/Java, although the traditional implementations are not compiled.

The compiler does “guide you” in memory management in Rust, but its “guidance” consists largely of refusing to compile buggy programs. Getting the program to compile e.g. doing the memory management correctly, is still a difficult matter, although this varies a lot by experience and program requirements.

To put it another way, if you are interested in shortening the time between writing a program and having a crash-free version, Rust will improve your situation. Although it will be a long time either way because bug-free programs are hard to write. If on Theo the hand you wanted to get something running your machine by this evening, Rust will spend a lot of time complaining about issues you are unlikely to immediately encounter.

I haven't done it for almost 20 years, but aren't there tools to compile Java into native executibles? There certainly used to be...