I would contest that Go is failing to get traction. It became mainstream years ago :)

Do you have any concrete evidence of these claims? In my 7 years of writing Go, I have never heard of anyone choosing another language because they didn't like Go's brace placement.

This has been brought up in the past and is unlikely to change.

From the why can't I put the opening brace on the next line? FAQ:

Some have argued that the lexer should do lookahead to permit the brace to live on the next line. We disagree. Since Go code is meant to be formatted automatically by gofmt, some style must be chosen. That style may differ from what you've used in C or Java, but Go is a different language and gofmt's style is as good as any other. More important—much more important—the advantages of a single, programmatically mandated format for all Go programs greatly outweigh any perceived disadvantages of the particular style. Note too that Go's style means that an interactive implementation of Go can use the standard syntax one line at a time without special rules.

I also don't believe at all your claim that enforcing a particular bracing style is what is preventing Go from being chosen as a programming language.

Closing here.

I'll note that besides the gofmt argument, which is compelling in itself, the language uses semicolon insertion to avoid requiring semicolons as a statement terminator or separator. Go uses lexical insertion of semicolons to avoid the difficulties that people have with JavaScript semicolon insertion. That choice in itself mandates K&R brace style. https://golang.org/ref/spec#Semicolons. This is not inherently insurmountable, but it's another part of the argument.

The evidence I have is entirely from my own experience, one project chose Rust instead. They evaluated Go and were positive towards to it but weren't prepared to accept the enforced brace style. In another case C++ was retained partly because of the brace issue and partly because of the risk of switching to an unknown language. So, in my experience, it is having deterrence effect which is why I raised this proposal. Incidentally I'm a Go advocate, and use it for personal projects, but I also prefer the neater Allman style and I can't really justify why it isn't supported.

@ALTree

I have been programming for almost 40 years and have written in 36 languages to date. My company develops software presently in 5 languages, if given the choice, based on a short list of variables. If required we will work with the language of whatever the inherited project originated in.

However, one language we will never use is Go, specifically because of the enforced bracing style. I personally find it completely unreadable. We also have turned down projects where we would have to use the language. We also do not contribute to any open source project that demands it. We use Allman, even in typescript.

We are one company and I am one voice. Add it to the claim you do not believe exists.

Allman should be supported. As per my understanding, K&R was created to save printing costs of physical programming books. I know programming books are still around and we need to save trees, but vertical space is not a problem on computer screens.

For old school programmers like myself, K&R looks asymmetrical and subtly disorienting. This is not to say I cannot read or work with K&R but I prefer to use Allman.

How does the following code look to you?

func main(){
	fmt.Println("Hello, 世界")}

The above code works, but I am sure you will find it odd.

What about this?

func main()				{
	fmt.Println("Hello, 世界")	}

This works too. But I am sure you will disapprove of it.

When I look at K&R, I feel the same oddness and discomfort when you see the above two bracing styles.

I hope the developers will be considerate towards that. Its your language, I dont mean to tell you what to do with it. Its just a humble request. If you like K&R you can use that, but it should not be enforced as an error.

Sorry, this isn't going to happen and the discussion is not worth pursuing further on an issue that was closed a year ago.