lobster_johnson

Varnish uses GCC to compile VCL into a dynamically loaded library. Not a general-purpose language, but it's done at runtime.

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.

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.

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.

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