httpcontrol looks particularly handy:

https://github.com/facebookgo/httpcontrol

[1] https://github.com/facebookgo/runcmd/blob/master/patents

It looks to be more or less the same as the relevant clause in the Apache 2.0 license that says "you can use our patents but if you sue us your right to use this software is automatically revoked."

It looks to be more or less the same as the relevant clause in the Apache 2.0 license that says "you can use our patents but if you sue us your right to use this software is automatically revoked." "

It 100% is not the same as Apache.

1. If you challenge any facebook patent's validity, at all, you lose the right to use the software. Apache has no such clause. (This is the "(b) that any right in any patent claim of Facebook is invalid or unenforceable.")

2. Apache is a tit for tat clause (for lack of a better term). If you have apache licensed software X, and sue someone about patents in X, you lose any granted patent rights to X. You keep rights to other software.

In Facebook's wording, if you have facebook software X, and sue Facebook about software Y, you lose granted patent rights to X.

The breadth is not the problem though. I'm perfectly fine with folks trying to prevent others from suing them.

However, this broad clause also applies to counter claims.

So if facebook sues you, and you counter claim, at all, you lose patents rights to all facebook software.

I actually know they have their good reasons to want to do this, but it is not a simple "you should feel good about this" type of situation.

Also, your paraphrasing leaves out the crucial bit that you only lose your rights if you sue Facebook for patent infringment. If, say, you decide to sue Facebook because you're sick of seeing the stupid Buzzfeed articles your so-called friends keep liking in your news feed, you can continue using their software.

Every time someone comes up with a new license, the review work must be redone to ensure it respects the philosophy of Open Source. Which is why I prefer project published under well-known licenses (GPL2/3, LGPL, Apache, Mozilla, BSD, ...).

If you're not big enough, then it probably doesn't affect you anyway.

How so?

I believe we're the only ones doing using Go in production at Facebook. Join us! https://parse.com/about#jobs

edit: the files have "Copyright Facebook, Inc." anyway

With their own GitHub username, they can just use whatever word they want for the package name (tool, counting, stack, subset, grace, inject) without risking a collision with other Facebook projects.

I see that it's a bunch of packages, under the heading of "Facebook Go". I assume this is something related to Google's Golang?

I click on "tool" ("Go library that wraps the go tool"). This has a README that points to a documentation link. And that documentation says things like, "Build the Command and return the path to the binary."

So, I guess we're talking about some kind of compiler here? A Golang compiler? How to I get it, how do I use it, and what -- if anything -- does this whole mess have to do with Facebook?

> This is a collection of tools and libraries for Go that Facebook has developed.

How did you figure that out? (And thus, in the future, how can I figure it out?)

You're right it's not the proper name that the go language team at google assigned, but it's certainly the colloquial (and notably more unique) one.

Go and formal methods? Seriously? It's one of those things that I imagine the Go community rejecting as being academic and not about getting stuff done.

^ that's not a value judgement, btw. I have no experience with applying formal methods myself.

https://github.com/facebookgo/httpcontrol/blob/e815eb2/httpc... (tab size 2)

https://github.com/facebookgo/httpcontrol/blob/e815eb2/httpc... (tab size 4)

https://github.com/facebookgo/httpcontrol/blob/e815eb2/httpc... (tab size 12, seems to be the maximum)

Unfortunately, there seems to be no such entry in the account settings. I'd love to set this value once and for all, or maybe once per file suffix (2 spaces for stuff.xml, 4 spaces for stuff.go).

In fact, this is the only remaining issue I have left at https://shurcool-legacy.github.io/bettertogether/.

But this isn't just a reaction rooted in practicality. To me, this looks and feels absurd. It kind of hurts to read. Again, this is just my personal take.

I prefer scope indentation of any kind to render as 4 spaces, but I'm okay with 2 as well.

Yes, it was just a personal opinion.

It was only used when you invoked the other option to use spaces instead of tabs. Both options are now removed. gofmt doesn't care how wide your tabstops are.

Groups of spaces and tabs are semantically different. Tabs mean indentation. Spaces mean spaces.

Sorry but this is false. The only thing a tab means, is tab.

Please provide your reasoning for the down voting. Thank you.

"A key on a computer keyboard that, when pressed, inserts a special ASCII character used for formatting text, as in indenting a line or block of text."

Actually going back it means tabulation which was an early form of alignment of tables on typewriters. The tab key advanced the carriage to the next tabulation point. It was repurposed as a way of indenting code later and it has become an additional definition of that fact.

(I'm old enough to have owned a typewriter, a nice Selectric one as well ;-)

Anyways, that's besides the point, and I think you missed the meaning behind my comment.

The reason why a tab space cannot semantically mean indentation in our world, is because nobody can agree on what that indentation should be. Since you are old enough to have owned a typewriter, maybe you are old enough to remember that by legacy, a tab was equivalent to exactly 8 spaces, and much of our software that runs the internet makes that assumption. Now however, people are saying "use tab to mean indent and everyone can have their way" To quote mikko, "There is no style guide or coding conventions saying that the tab character should be the indent. This assumption is easy to make because it allows you to stick your head into the sand, ignore the surrounding world and by singing “let the users pick their own tab width” mantra."

Again, this wasn't to start a tab vs spaces war for go, and why go chose tabs. It's fine to make a choice, but it was your second statement that provoked my comment.

It means 1 indent, not 8 spaces, 3 bananas or one tree. It is a unit. How the user displays that is up to them.

I used to hate tabs and want 2 spaces only, until I started working with other developers. Then suddenly tabs made sense, especially when you've got IDEs coercing every edited file to a person's indentation standard. Standardize on the tab and the pain goes away.

Sure there is: http://en.wikipedia.org/wiki/IEEE_754-1985#Positive_and_nega...

I agree gofmt is amazing, and for any language I'd happily trade whatever my personal style is for consistency and and gofmt-like tool.

Can gofmt really change semantics? I would assume that's a bug?

It is definitely not supposed to change semantics. If you ever see an instance of that, then it is a big fat bug and should be reported to the developers ASAP.

I doubt you'll see such a bug though. The language is designed to be easy for a computer to parse.

The "standard" alternative (e.g. the google c++ style guide) advises 2-space indentation with 80 column lines. That specific format works well with almost every tool in existence. Tabs, not so much.

You can google "jwz tabs" to get a more in depth discussion. It's not a "big" deal, and as noted, in many ways it's better to standardize on the "wrong" decision than to constantly hash it out over formatting sugar.

I use emacs and various command line tools. Tabs don't give me problems. FWIW.

It was my impression that gofmt was essentially a pretty printer. Can you point to examples where it changes semantics?

Edit: I see, import order can affect the order that the init()s in different packages are invoked, presumably. I stand corrected.

Edit 2: But that should not matter since the language doesn't specify any dependence on that.

The same exact argument applies. The code was broken to begin with, the implementation behavior did not break anything.

And, just like with map iteration ordering, it's very difficult/impossible for the compiler to say "hey don't depend on this!".

The only way that I can think of to get this concept (that import order in code and init() order in runtime are unrelated) is to have things break.

I suppose if the runtime randomizes things, at least you would never experience it consistently working in the first place, so maybe the issue wouldn't ever come up.

Regarding static initializers, I use them for precompiling regexps and templates, but not much more than that.

It is also incorrect to rely on the order of import initialization at all, because it's undefined, implementation specific and may change.

Undefined behavior is another thing. Surely, it's poor form to rely on undefined behavior. However, that doesn't mean it isn't possible for such a situation to arise. An accurate description of how that can happen doesn't deserve a downvote.

On the contrary, it's quite valuable for a newbie (like myself) to learn the facts, not just the dogma. Downvoting an accurate description of the behavior of the tool because you think the situation shouldn't arise in the first place is simply a misplaced use of a downvote.

https://bugs.launchpad.net/gocheck/+bug/1178806

0: https://news.ycombinator.com/item?id=8601850