lobster_johnson

Thanks for the clarification. I saw the readme, and I assumed (wrongly) that each rule just receive a file name.

I wonder where you draw the line between a "linter aggregator" and a "linter". golangci-lint incorporates all the rules themselves, though it imports the linter logic as libraries, so I'm not sure that it's fair to call it an aggregator. Gometalinter runs linters as child processes and I don't think it contains any linter code, so it's a pure aggregator.

My point is that while your project is admirable, the Go world isn't large enough for so many linter projects. Personally, I just want one good linter that is maintained and that incorporates all the rules I want.

I've not used Berkshelf, but I suspect your problems were related to Chef and the fact that they've built their own dependency system that also interacts with Bundler/RubyGems.

Anecdotally, my company has used Ruby since around 2004, and Bundler since its first release, and we never had any issues. That doesn't mean nobody has ever had any issues (clearly! [2]), but it generally seems like Ruby package management is a solved problem, and that it would be a good model for any dependency system to use.

Bundler does have one feature (or misfeature) that Russ Cox criticizes: "bundle install some_gem" can cause unrelated gems' minor (or maybe it's minor) versions to be upgraded even if you don't tell it to. I've never liked that, and would much prefer to use "bundler update" to perform explicit upgrades. But I don't think that behaviour is at all tied to its solver, or that MVS is needed to fix it.

[1] https://github.com/bundler/bundler/issues/5068

[2] https://github.com/bundler/bundler/issues

Thanks for the explanation!

The fact that dep parses import statements (as does Glide) is something I've never liked. It means that if you run "dep ensure --add" on something not yet imported, it will complain, and the next "ensure" will remove it. This is never in line with how I actually work. I need the dependencies before I can import them! There's no editor/IDE in existence that lets you autocomplete libraries that haven't been installed yet.

It also means that "dep ensure" parses my code to discover things not yet added to Gopkg.toml. That's upside down to me. I want it to parse its lockfile and nothing else; the lockfile is what should inform its decisions about what to install so that my code works, my code shouldn't be driving the lockfile! If I try to compile my code and it imports stuff that isn't in the lockfile, it should fail, and dep shouldn't try to "repair" itself with stuff that I didn't list as an explicit dependency.

I'm sure there are edge cases where the current behaviour can be considered rational, but I don't know what they are. As you point out, dep has to do a lot of work -- but why? Running "dep ensure" when the vendor directory is in perfect sync with the lockfile should take no time at all, and certainly shouldn't need to access the network. Yet it takes the same amount of time with or without a lockfile.

> Now Cox's solution might indeed be better (though I think it's an overkill ...

vgo is actually much, much simpler than dep. The sheer number of words in Russ Cox's series of blog posts belies its simplicity. vgo doesn't need a SAT solver. If you look at many of the issues dep is struggling with, they're related to solving N libraries with transitive dependencies up the wazoo.

Cox's long treatise reflects the complexity of the problem space. Developers tend to brush off package management as being simple. But once you include range-based version constraints and transitive dependencies, it gets a bit messier. Look at NPM and Yarn; they're still struggling to get all the details right. On the other hand, there's Ruby's Bundler. It came out in 2009, RubyGems in 2004, and I've never had a single issue with the toolchain (other than messing up my own constraints). I don't know what kind of magic elixir they were drinking, but somehow those guys managed to nail it from day one.

Testing and package management aren't mutually exclusive. If you're in a monorepo, all your code evolves in lockstep. A core tenet of versioned package management is to get reproducible builds that only need to break once you choose to evolve forward in time (i.e. upgrade).

Historically, most languages (C, C++, pre-Maven Java) haven't had package management at all, and so dependencies have typically been managed by vendoring the code (or JAR files). JAR files worked okay, but vendoring incurs maintenance overhead that isn't acceptable in today's environment. git submodules are theoretically a solution, but also high-maintenance.

Here [1] is the "dep ensure -v" output for a project of mine. It takes almost 12 seconds even when there are no changes to the actual file. I don't know why, or whether it's actually the solver (though the output seems to indicate it).

[1] https://gist.github.com/atombender/7c28f1d371fcb139e1e742a08...

Every Go project I've used uses git tags prefixed with "v", e.g. v1.0.3.

https://github.com/gogo/protobuf

https://github.com/olivere/elastic

https://github.com/golang/protobuf

https://github.com/sanity-io/litter

Nothing yet. The new tools should land in 1.11, but will be an experimental opt-in, with the aim of full support in 1.12.

Cox discusses Cargo here, and why he doesn't like it: https://research.swtch.com/vgo-repro

The vgo proposal explicitly rejects the "Cargo way" [1]. There's no lock file, and the MVS algorithm requires, as far as I recall, that the go.mod file is modified whenever the developer wants to update to a new version.

[1] https://research.swtch.com/vgo-repro

Rust/Cargo had the luxury of being a greenfield project that could adopt semver from the beginning, whereas Go made the mistake of starting out, and then going years, without any official package management solution. As a result, Go has a swathe of applications and libraries that use specific workflows as well as a mélange of community-developed package management tools such as godep, Glide and dep. The semver standard, in particular, has been inconsistently adopted by the Go community.

In other words, any new Go tool either has to support/import existing code, or to wipe the slate clean and say that for a package to be importable it has to follow a new spec. dep decided on the former, and my impression is that this has had unfortunate consequences, because that inherits a lot of historical baggage.

We've been using dep for a while (having escaped the bugfest that is Glide, which used a very similar approach), and it's pretty evident that the solver is buggy and slow and also complicated enough that fixing issues like [1] can only be done by a select few that already understand the codebase. I'm not in a position to judge what the causes of all of these issues are, though I'd wager they're not entirely unrelated to the inherent complexity of SAT solving. The current dep issue tracker is full [2] of reports mentioning the solver, not to mention that dep currently has problems with known libraries such as the Kubernetes client [3] and Protobuf. (Google-related projects have historically used godep.) Again, possibly related to this specific implementation and not necessarily something that would apply to a hypothetical "Cargo for Go", but I don't know.

Any idea how Cargo compares to dep overall?

[1] https://github.com/golang/dep/issues/1306 — this one is a nightmare if you work anything related to Kubernetes.

[2] https://github.com/golang/dep/issues?q=is%3Aissue+is%3Aopen+...

[3] https://github.com/golang/dep/issues/1207

You missed my point; I didn't say it's new, I said it was simpler than it might seem, and that thinking of it as a state machine makes it easier to understand what the core of Kubernetes really is.

And of course "nothing but a pattern" is nonsense. Pre-container systems like Puppet and Chef -- which are also, vaguely, based on converging real state towards desired state -- are firmly rooted in the traditional Unix model of mutable boxes. You can't implement a consistent reconciliation loop if your state can't be cleanly encapsulated (as with containers).

Disagree. OpenShift and CNCF are arguably exactly that, but Kubernetes itself isn't. It came out of the engineering team at Google, and its technical merit shouldn't be confused with the considerable marketing effort being put behind it.

Docker Swarm is much more deserving of this kind of cynicism -- a weak, badly designed solution forced on users by a company that's realizing their invention has been commoditized and is no longer a platform they control. Swarm was redesigned at one point to work more like Kubernetes because they realized it was a much saner model.

Kubernetes has more complexity, but it does scale down to single-node clusters.

Wonderful novel, though. The book is by the great Friedrich Dürrenmatt, and is basically a deconstruction, as well as a subversion, of the detective novel (in fact, its subtitle is "Requiem for the Detective Novel").

J and K are extremely terse, though. They just chose other ASCII symbols that exist on everyone's keyboard.

I meant neuter! I studied German for three years in school, but my brain got its wires crossed there for a second.

At this point gender in most languages has almost nothing to do with the semantic meaning of the words themselves -- biological gender or whatever -- and we might as well call it something less culturally loaded like "noun class". A famous example is "das Mädchen" in German -- a masculine (edit: neuter, I mean!) noun for a biologically feminine person. Languages are littered with such inconsistencies, and as a language learner almost all of the genders are not discoverable from the semantic meaning of the word. Why is "ei bok" (Norwegian for "a book") feminine, when it's categorically an inanimate thing?

Sure, it might work. A binary format still has to be parsed, of course, but it would likely be a little more efficient.

One question is whether that efficiency gain would be worth the hassle of a binary format. Binary formats have generally not been a good fit for the web; DNS and HTTP/2 are the only widespread protocols I can remember off the top of my head that are binary. gRPC is binary, and look at the lack of mature toolchains to work with it -- while there are some tools now, the selection is minuscule compared to those available for HTML and CSS.

Binary formats are also trickier to extend and keep backwards-compatible.

I've been waiting for something like this! Gometalinter is notoriously inefficient, and it's always bothered me that it runs every linter separately as opposed to parsing the code once and then running analysis on it. There's really no need to spread lint logic around in dozens of little projects when a single, monolithic linter (with modular rules) would be much easier to make performant. This project looks exactly like what's needed.

The only negative is the name -- I understand the desire to market your hosted linting product, but "golangci-lint" is hard to remember and something of a mouthful.

I don't see it mentioned in the GKE release notes, so I assume there's no option to enable it yet.

This is great. Anyone know what Google's plans are when it comes to rolling this out on GKE?

Some good, fairly recent data from Pew [1] and in this [2] NY Times article. From what I gather from this, border crossings are going down, but illegal visa overstays are going up.

[1] http://www.pewresearch.org/fact-tank/2017/04/27/5-facts-abou...

[2] https://www.nytimes.com/interactive/2017/03/06/us/politics/u...

"Brains scrambled" implies permanent negative effects. I have never encountered any evidence that psilocybin has contributed to psychological damage, unlike LSD and its famed/apparent tendency to provoke flashbacks years later.

On the other hand, there are increasing numbers of recent studies that refute the idea that psilocybin is as dangerous as some people have claimed in the past [1] [2]:

> We failed to find any associations between lifetime use of psychedelics and past year serious psychological distress, receiving or needing mental health treatment, depression, anxiety, or suicidal thoughts or behavior in the past year. Rather, lifetime use of psychedelics was associated with decreased inpatient psychiatric treatment.

I'm unable to find any studies showing a link between psilocybin and the triggering of latent mental illness. There's some debate about whether age is possibly not coincidental, in the sense that the heaviest users of "hard" psychedelics like LSD tend to start at an age which coincides with the emergence of latent disorders such as schizophrenia, implying that there isn't necessarily a cause and effect.

Nobody is obviously promoting irresponsible use of psychedelics. That said, everything in life has risk. The risks involved with psilocybin seem infinitesimally small compared to those of, say, alcohol or smoking.

[1] http://www.emmasofia.org/wp-content/uploads/2015/02/Psychede...

[2] https://cogumelosmagicos.org/comunidade/attachments/j-psycho...

It's pretty clear from your comment that you don't know anything about magic mushrooms.

I could understand your response if the parent were speaking about LSD or bath salts or something else that have been known to give people bad, destructive trips. But shrooms?

Psilocybin is known as the gentlest and most enjoyable psychedelic there is. Adverse reactions are rare, and as far as I know nobody has ever come out of a shroom trip with their brains scrambled. Personally, I find that the experience isn't so much a "trip", but rather a gentle, beautiful and interesting set of visual effects. I don't hallucinate people or supernatural beings, but I do see colours around the edges of things, and repeating fractal patterns everywhere, and enjoy a strangely improved acuity of vision.

Shrooms are also a type of drug where you can derive a psychological benefit from very small doses (or microdoses) that essentially provides no "trip" at all. There's promising research showing benefits for depression and PTSD. Not to mention that psilocybin is not addictive.

Go already has "packages", so it's not something that can be used for what vgo calls modules.

A Go package is similar to a Java or Python package; it's just a namespace. A vgo module can be thought of as a collection of packages that have a version number and a single canonical name.

I don't find the terms particularly confusing, given that Go doesn't already have anything called a module. It would really only be confusing if you're deep into another language that has "packages" and "modules". I personally don't find it difficult to context switch like that.

Kubernetes' has a pluggable container interface, called CRI. You can implement non-Docker containers. For example, there's a runtime called Virtlet [1] that runs VMs instead of Docker.

I don't know of anyone working on CRI implementations for FreeBSD jails or Solaris Zones. At the moment, I believe Kubernetes has specific dependencies on Linux in other areas that the container runtime.

[1] https://www.mirantis.com/blog/virtlet-run-vms-as-kubernetes-...

Minor correction: Syfy doesn't produce The Expanse.

The Expanse was entirely conceived, financed and produced by Alcon, an independent film production company. Outside the US, Netflix has the exclusive distribution rights, and in the US, the show is also carried by Amazon. Alcon also produced Blade Runner 2049 and Villeneuve's earlier film Prisoners.

No doubt Alcon needs someone else to pay for the distribution rights now, and I wouldn't be surprised if it ends up on Netflix or Amazon, both of which are pushing sci-fi pretty hard. Amazon would be a good fit: The Expanse was co-produced with the Sean Daniel Company, who are also working on the new adaptation of The Witcher, and whose new production startup Mythos recently signed with Amazon Studios.

The latter. I think it's a sheepish admission that the bug (caused by unsafe C code) is a reason to prefer Rust's safety, which should help them prevent another one like it.

I suspect it's this bug: https://blog.cloudflare.com/incident-report-on-memory-leak-c...

HN: https://news.ycombinator.com/item?id=13718752

My company was using Darcs at the time when git (mid-2008) was gaining popularity. Github wasn't around yet. At the time, git felt like a big step backwards technologically. It had a terrible UI, and the whole thing felt like something put together with tape and paperclips. Meanwhile, Darcs was (and still is) pure magic.

At the time, the choice of git wasn't that obvious. There were several popular, quite attractive contenders, including Mercurial, Monotone, Bazaar and GNU arch (and its forks), and it wasn't obvious who would win. But then Github arrived and changed everything, and it felt like everyone was suddenly caught up in a historic momentum whether they liked it or not.

We've had lots of those historic moments, some of them more slow-moving than others. Mac and NeXT being outmaneouvered by Windows; Lisp, Dylan and Smalltalk being relegated to the dustbin through the rise of more popular, worse languages; and so on. Not all of these developments are terrible (I love that Nginx prevailed over Apache and that Rails took over from Java app servers), but it's ridiculous how often the paperclip solutions win over the more thoughtful ones.