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...
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."
"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.
...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, ...).
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)
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
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.
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.
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.
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".
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.
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.
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.
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).
... 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.
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 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.
"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 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.
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.
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.)
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.
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'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?
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.
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.
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.
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.
"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
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.
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.
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].
httpcontrol looks particularly handy:
https://github.com/facebookgo/httpcontrol