I had to google to see what that meant. It appears that some moderator is a bit touchy regarding the Go programming language, because of all the comments I've made that's the only one that was modded as negative.
That's how science goes: a phenomenon is observe, an hypothesis is formulated, and then it is tested. As it isn't possible to test economic policies on countries, economy often deals with hypothetical models whose limits aren't tested.
In addition, it's terrifying how a service that forces you to identify yourself tries to gather information not only on your social network but also on what search queries you run, who you talk to, what you talk about, and what videos you watch. Imagine what Cardinal Richelieu would do with all that information.
Blaming the EPA for companies abusing a bug in the way tracking numbers were managed is like blaming the victim of a home invasion for putting up a defective lock.
Hacker News, through RSS feeds. Wikipedia is always fun to browse. I used to browse slashdot but once the shill epidemic kicked in, it started to become a complete waste of time.
Not true. While the "domain of keys" format is implemented through a list of tuples, the compressed row/column/diagonal storage data types, which are the formats used in popular matrix algebra/solver packages, are implemented as three arrays.
The data structure scheme you've described is only used in a single application: populating a sparse matrix. Then, in any application where a minimum amount of efficiency is required, that data is converted to one of the formats I've mentioned before, and no format you've described is actually used beyond that corner case.
Quite true. In fact, comparing MessagePack to JSON can only be interpreted as comparing $own_project with $most_popular_project, with hopes of getting some attention.
What is there to be glad about? Considering Facebook's track record on privacy, censorship, and disabling accounts, and considering the number of alternatives out there, there is nothing to be glad about.
looks like the real problem lies in some libraries being broken and poorly thought out. If your code chokes on invalid input then the problem lies in your code, not the input.
Sure, UI code tends not to be that processor-intensive, but it is a braindead idea to dump efficient state-methods with a bloated, inconvenient, and ill-conceived state-changing method which is both needlessly verbose, inefficient, unreadable and unjustifiable. Rube Golberg isn't a software design pattern's guru.
You repeat yourself yet again. How exactly can you claim with a straight face that a workspace doesn't need to be referred to in $GOPATH, and then proceed to claim that you only need to set $GOPATH to a directory which contains those workspaces? You start off your post by claiming it's not true, but then you repeat exactly what I said. Are you joking?
So, when faced with criticism mentioned in the blog post and referred to in a post, instead of thinking about it you mindlessly insult others and say absolutely nothing about what has been said. Who exactly is the troll here?
These are not source modules I'm talking about. If it was only necessary to set $GOPATH to point to source modules then everything would be fine. The problem is that go requires that $GOPATH points to a project's source tree to be able to build it, if the project is organized to store other go source files in subdirectories. We aren't talking about packages or modules intended to be reused in other programs. We are talking about how source code trees are organized.
I'm not talking about gc. I'm talking about go. You know, the program which is extensively marketed as the only program which is required to build and run Go programs, and the standard and default way to deal with Go, from installing third-party packages and running your program through an interpreter.
Referring to gc makes as much sense as referring to gccgo.
Supporting declaring variables with new(), make and local variable assignment isn't mandated by the need to make the grammar regular. It's simply a braindead idea. Go might have significant improvements over C, but they screwed the pooch on this one.
That approach is nice and all if we are dealing with modules which we wish to reuse. If instead we would like to organize our source tree following a deep directory structure, we are forced to screw around with $GOPATH, which is a braindead idea.
You started your post by claiming it wasn't true, but you proceeded to say that yes, it is in fact true.
As it is stated in the screencast, a programmer needs to add the workspace to $GOPATH to be able to build the source. That means that for each project being developed in Go, you need to add the path to that project to $GOPATH to be able to build it.
He forgot to mention how programmers need to add each project directory to $GOPATH to be able to include files stored in project subdirectories. Talk about a braindead idea.