james-mcelwain

shellcheck is amazing. I write enough shell scripts that I remember most of the syntax and tricks, but am far from an expert. shellcheck has taught me so many things and makes me feel more safe writing scripts in the event I forget one of the million gotchas.

Yes, of course. A centralized repository for a package manager is always going to be a single point of failure.

Unless you've found a serious bug / security vulnerability, Docker doesn't mess with your OS. On OSX / Windows (and this is definitely an argument against Docker ux), it's not even running on your OS but a separate VM.

The big thing I've found missing is discussion of containerization primitives, e.g. cgroups. The other Linux namespaces are discussed where appropriate, but in 2017 it would be nice to have a section on all these together.

I totally agree that it depends on domain, but I think that's part of the point -- making these comparisons, i.e. Clojure vs Haskell in the abstract aren't particularly interesting, as it seems obvious that no general purpose language is perfectly general for every purpose.

Right, but most of the statically typed code in the world is written in C++, Java, etc. If you're presenting Clojure to your organization, the choice isn't going to be Clojure vs Haskell/Idris, it's going to be Clojure vs Java. The sort of boosters for static typing in this domain are the AbstractSingletonProxyFactoryBean people. I think defenders of static typing have at least some burden to defend "actual existing type systems" rather than immediately falling back to "well, in Haskell..."

I'm not a fan of Java, but the JVM is an incredible piece of software that centuries of man hours have been spent optimizing. And while Java might not be a pleasurable language, the enterprise masochists have written millions of lines of battle tested code in libraries. The deployment and monitoring model for the JVM is very well understood, which means Clojure is uniquely positioned to be introduced into large organizations.

Doesn't this memo create an "us" vs "them" dichotomy in itself?

Here's a great testing library that leans heavily on Nashorn. https://github.com/intuit/karate. I find this a beautiful use of JavaScript in Java.

Vox is most certainly a liberal outpost. You're correct that many elements of the left reject liberalism, which is why Vox et al. are center-left liberal rags and not "leftist."

I feel you... I use some unholy abomination of Emacs, Vim, and Spacemacs. Sometimes based on convenience, but mostly based on what I learned first.

I use Emacs for languages I work continuously in and have strong (or am forming) opinions about. Willing to invest 1-2 hrs configuring. Save it in a git repo.

Not everyone share's preferences (tabs, spaces, etc.) across languages. Maybe I'm crazy but I use 2 vs 4 in different languages.

If I'm just trying a language out for the first time, I find it much easier to use vscode + vim plugin + language plugin to try something out.

Killing a process on an exception you can't handle is sort of best practice anyway in Node--assuming you're not building important financial services or whatever in Node (lol).

Like, you want to be careful not to open yourself up to cascading failure, but if my application has a random exception, the 100ms start up time of the JavaScript VM means its almost always worth the cost of restarting to ensure your application isn't in an unstable state.

Isn't it possible that when you hire 1000 bright engineers to build something like Twitter to scale, they build a bunch of crap and unneeded complexity that makes it difficult to get lean?

It's also worth noting that a huge percentage of those employees are ad people who are sorta necessary for their current revenue model.

Put enough bright engineers in a room and they'll over-engineer a monstrosity. They probably didn't need as many engineers as they have to scale, but it's entirely possible that they've introduced enough unnecessary complexity into their systems that scaling back down isn't easy or even possible in the short term.