Facebook Go Libraries | Hacker News Reader

Facebook Go Libraries

github.com

227 pointsakavel92 comments

This is neat. I like that everything's packaged independently like this.

httpcontrol looks particularly handy:

https://github.com/facebookgo/httpcontrol

This is the first time I see a patent file in an open source project [1] and now I know I won't use this until my lawiers take a look at it. Sad world...

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

Well, if you read the file you'd see that it's a grant of rights to use this software regardless of any patents Facebook has that may apply to said software.

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."

...and the Apache 2.0 license belongs to a short list of licenses that have been extensively reviewed and can be trusted.

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, ...).

The package in question is licensed under BSD 3-clause license. I'm guessing the patent file is included as well to cover their bases.

BSD is generally viewed to have an implied patent license. The patent file is usually there to give you a different set of rights than you would have gotten, be it good or bad (and i've seen both :P)

"Well, if you read the file you'd see that it's a grant of rights to use this software regardless of any patents Facebook has that may apply to said software.

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.

I was merely trying to point out that contrary to what the OP seemed to be suggesting, this file is not a list of patents that Facebook says apply to this code, or anything else particularly nefarious.

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.

Why is it sad? If you're big enough to have lawyers on the payroll, it doesn't take that much effort to have them take a look.

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

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

How so?

Looks more like Naitik Shah's open-source libraries.

He seems the main committer there, indeed... but "Naitik Shah's open-source libraries" seem to be present already at: https://github.com/daaku?tab=repositories ... so what is the "facebookgo" thing then?

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

I wonder why these aren't under the main facebook account ( https://github.com/facebook ) o_O?

Better organization? Once you start to have more than a few pages of projects on a single group it starts to get very difficult to find them on GitHub unless you know exactly what you're looking for.

It gives them more freedom in package names. It's nice when a package name is the same as the last element of the URL, and that URL's reasonably short. And you repeat the package name whenever you use an identifier from the package, so it's good if it's 1) short, and 2) if possible makes the full identifier read nicely à la counting.Reader.

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.

These were all developed on the Parse team. Naitik is a huge contributor :)

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

Nice. Thanks for open sourcing these libs :)

I've heard there are a few other little sprinkles of Go in other places, but no large codebases like this.

I have no idea how to evaluate this, or even tell what it is. Could someone help me out?

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?

The name of the language is Go, not Golang. This is a collection of tools and libraries for Go that Facebook has developed. I don't see any compiler, though one of them wraps the Go tool that is used to compile Go programs.

I've been working with go for the past year, and let me tell you - golang is king when it comes to google's own search engine queries.

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.

I don't see that it is the colloquial name of the language even if people sometimes search for it. In conversation, AFAIK it tends to be called Go. For example, look through the golang-nuts mailing list and count how many people say "Go" versus "Golang" when not referring to the website or mailing list.

Have you tried debugging something and search for for "go" rather than "golang"? You're both correct here: the name of the language is Go, and when searching google for help with an error or something, it's best to search for golang rather than go, or you'll be wading through a bunch of unrelated pages.

Thanks!

> 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?)

Well, I think the primary difference is that I'm a little more familiar with Go, so I have slightly more context. Most of these say things like "Package that provides such-and-such functions" or "Library for doing this thing".

The crappy documentation is very much in line with many Go libraries, sadly. There doesn't seem to be a great culture of documentation. People often just write bare API docs without explaining why the library is useful or showing a lot of examples.

It may be a cultural difference of system programmers (including Go designers and developers) and (consumer) application programmers (e.g., as in the Apple camp). System programmers regard themselves higher, prefer terse symbol names, specs, docs, mathematical expressions, and formal methods, don't seem fans of Objective C or Java style readability and verbosity. But then again, it's open source software -- No one owes anyone anything.

> formal methods

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.

Never experienced this, godoc https://godoc.org/ is a good resource

I was complaining about exactly the docs I've found on godoc.org.

OT but I think GitHub should show tabs as 4 columns. I find Go code is hard to read with all this whitespace.

Or better, we should save source code files replacing tabs with spaces. That's the best practice that makes everybody happy.

Go uses tabs. That's the law. It's in the documentation.

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

My apologies, thank you for the clarification.

>Tabs mean indentation.

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

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

The dictionary in front of me disagrees:

"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 ;-)

We are talking about computer semantics which exist in a discretized world, not english language semantics. By your logic, the word integer would be any number not a fraction or decimal down to negative infinity up unto positive infinity. There is no concept of infinity on a computer.

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.

I get what you mean but a tab is purposely meaningless and unqualified.

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.

This. Absolutely this.

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.

> There is no concept of infinity on a computer.

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

Ok sorry. There is no true representation of infinity.

...or Scotsmen.

Semantics is contingent upon meaning. Meaning varies and changes. Meaning is defined over time. That's the case with most words. In formatting text, it's as semantic to say that tabs are for "tabulation" and "indentation" as much as spaces are for "space" and "spacing characters." Tabs have always been semantically better as indentation in computing.

Spaces are tolerated, but the usage of tabs is very encouraged.

The Go team has made the decision that the language supports tabs for indentation, and it’s enforced by `go fmt`.

While this is clearly the wrong decision, one has to applaud the Go team for building `go fmt` and thus putting and end to unproductive discussions about formatting. (Although it would have been nice if `go fmt` didn't change code semantics.)

I'm relatively new to Go, and like you I wholeheartedly agree with the idea of solving formatting once and being done with it (and as an aside, I agree that tabs are the wrong decision).

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

go fmt will reorder your imports, which means that if there is an import ordering dependency, it will either be exposed (or hidden) by go fmt.

you should never have an import order dependency, since initialization order is unspecified.

Shoulda woulda coulda:

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

I say that's great! It helped uncover an otherwise unnoticed bug.

I'm just going to say whoever is downvoting this is a jerk. This comment is actually correct. Whether or not it reflects the way you believe things should happen, this is an accurate description of how things do happen (I assume, based on the other comments, I don't actually know myself).

Yes and no. `gofmt` is a tool to make your code follow certain style guidelines, and the ordering of imports is part of those guidelines. You are always free to ignore the guidelines, but then don't complain about the tool which is created to enforce them.

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

So it sounds like... yes and yes. Guidelines are guidelines. If they are more than guidelines they must be enforced at the language level.

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.

It does not change semantics. If it does in some case, that's a bug and please report it.

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.

no, the order is unspecified, so it shouldn't be relied upon. The only order enforced is that imported packages are initialized before the package itself.

In fact, you should be glad that "go fmt" exposed the fact you were relying on something that you should not have. Better to find a bug sooner rather than later, and relying on implementation details of your particular language implementation is a bug.

It seems to me like it would be very much in line with the Go philosophy to automatically uncover this in some way other than just an impossible-to-debug pre-compile sort, like disallowing it on a language level. Perhaps that's a Hard Problem, though, so not a reasonable request.

Well, they could do what they did with map iteration: make it happen arbitrarily different each program execution.

Breaking it randomly and requiring debugging is not the same as telling you you're doing something wrong and where.

Worked for maps :)

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 guess I've personally never seen the value of static initializers (in other languages at least), they always seem like the source of hard-to-find bugs. So perhaps that's really where my complaint is. Is there a compelling use for them in Go over explicit initialization?

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.

Right, that's the idea.

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

Wait, why is it clearly the wrong decision? I think using tabs for indentation is great.

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 not a particularly interesting discussion to have. The short of it is, if you only ever use one tool (or family of tools) to look at code (say an IDE), then tabs are not unreasonable. Once you start using multiple families of tools on multiple machines, now you have to maintain T*M tab configurations, which is awful.

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 think this stuff is actually pretty interesting, it's programmer tools UX!

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

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.

That's only if the developers use go fmt though. The only place I've worked at that used Go didn't use go fmt.

That's craziness. Why wouldn't you?

"Sometimes people work faster with code formatted like they are used to" - Code Creator "Well, if we all standardize on the same style we can get used to working faster with the same format giving everyone a net win" - Me "Well we'll have to do it after... later... deadlines... shipping" - Code Creator

I feel it's worth pointing out the irony in "While this is clearly the wrong decision" and "thus putting and end to unproductive discussions about formatting" considering this is part of a discussion about Go's formatting.

Why? n spaces encode a specific preference for indentation, while tabs just represent a level of indentation. How many columns these actually are is entirely up to personal preference and editor configuration. That's why tabs are always superior for indentation.

It's actually quite a bit more subtle than that. Even `go fmt` uses tabs to format indentation, but uses spaces to format alignment. This is distinct from mechanical typewriters which used variably sized tab-stops to handle tab alignment.

No, it should show it as tabs, because that's what it is. Ideally, it should show it as 8 column tabs, as that is what gofmt assumes by default.

Sorry, changed "spaces" to "columns".

... and the only reason for it to be four columns is that you personally find it hard to read, or do you have another, more compelling argument against using 8 column tabs?

Personally, I find 8 columns to be an incredible waste of horizontal space. I frequently place editor windows/panes side by side, and using 8 columns or spaces wastes valuable screen real estate.

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.

I agree. For me, I want enough indentation to make the structure obvious. 8 columns is way overkill in that regard.

> and the only reason for it to be four columns is that you personally find it hard to read

Yes, it was just a personal opinion.

But not personal enough not to be the basis for an argument about what github should do to display Go code.

What are you arguing about exactly? Am I not allowed to think Github should display them as 4 columns?

I'm kind of surprised that 8 column tabs is even being discussed, I thought 2 or 4 were the normal values?

I don't think gofmt assumes any width for tabs. It, prints `\t` for indentation, and that's all.

It has the -tabwidth option, defaulting to 8. I have yet to figure out what it's used for, but presumably there is some case where it is used for alignment.

> It has the -tabwidth option, defaulting to 8

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.

Actually, you can configure GitHub to do that. Just add ?ts=TABSIZE to the url. For example:

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).

I, too, would like to see an entry to set my preference for my account. I prefer tabs of size 4.

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

Wow, Facebook sure uses a lot of languages. PHP, Hack, C++, Erlang, OCaml, D, Go, JavaScript, …

... Python, ...

Is there any repo of Facebook D code? I thought they were making an investment in D. But this is a bit surprising because it seems possible that they use more Go than D.

Why surprising? I guess they use many different languages. And Go and D are probably sufficiently different to have distinct uses for them.

This is not a lot of Go - it's mostly small contained packages for doing useful things. It was also written by the Parse team, who are the only people using Go at FB in production[0].

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

Reply on news.ycombinator.com