Hacker News Reader

Comment by martinced | Hacker News Reader

His second point is, to me, the most important for would-be language designers:

Standardized formatting: A standard tool to enforce formatting rules that is not subject to change based on the team members' or leader's opinions is a welcome feature for lowering the "not my code" mental barrier.

This is a godsend. The best thing to have happened to our industry since a very long time.

But his first point is oversimplified:

The compiler not only checks for code that can theoretically result in a runnable program...

It's not exactly as if Go did solve the halting problem or we'd ALL be using Go. So I think a bit more in-depth explanation would have been welcome.

View on HN

In a certain sense, languages like Agda do solve the halting program, but we're not all using them...

Seeing more total languages used in industry would be pretty cool.

Slight correction

> The compiler not only checks for code that can theoretically result in a [logically correct], runnable program...

Some examples of this:

- If you try to assign to a variable that will never be read, this is a compile-time error.

- If you try to import a module that will never be used, this is a compile-time error.

- If your dependencies don't form a DAG, this is a compile-time error.

Incidentally, not only does this make runtime errors (or logical errors) much less common, it also makes Go code more readable and vastly contributes to its impressive compilation speed.

If the biggest gain for the language is a formatting utility then that language is not worth learning.

What is the "biggest" gain a language can have is a matter of taste. Someone who considers the handling of formatting and style to be the "biggest" is likely to be one who values those things highly.

That you do not value those things as highly is not particularly profound. It doesn't mean that he is wrong to be excited about that, nor that he is excited about the wrong language, nor even that there is no reason for you to be excited about that language. It only means that there is no reason for you to be excited about that language for that particular reason.

> Someone who considers the handling of formatting and style to be the "biggest" is likely to be one who values those things highly.

Not really. Someone who values those things highly would have written the code as such, instead of relying on a utility to reformat the code.

Are you being purposefully obtuse? Do we really all just use and read our own code and not the code of others?

Having `gofmt` drastically increases the probability that any particular Go program has the same style/formatting that you're used to.

The formatting utility is really just a side effect of the decisions to Go team made regarding syntax and semantics in the language. There's also a tool to automatically update your code if the language changes (this was important during the days of rapid churn, where your programs would break every week).

They made some very opinionated choices and have largely stuck by them. You can't have an unused variable, it just won't compile. What a pain, right? Well, if there's one thing I've learned from compiling open source code, it's that you CANNOT trust programmers to clean up their code before releasing it--just play "count the unused variable warnings" next time you compile pretty much any Linux program.

The biggest gain is coroutines which are easy to add to your application. No imports, no convoluted thread initialisation just

    go myMethod()

Reply on news.ycombinator.com