ths

> The issue isn't tooling, it's hardware resources and in some cases licencing.

Hardware resources are definitely an issue. That's why we generally recommend using remote development environments, which aren't as resource-constrained as the local dev machine. Making that comparably smooth to the local dev experience (e.g. for live reloading of services without rebuilding containers) needs some clever tooling (which is partly the reason we're building our product).

With production-like remote dev environments, you get the same capabilities as your CI environment, but can run test suites ad-hoc (and without having to spin them up and tearing them down for every test run).

There's no fundamental reason why CI environments should have capabilities that individual dev environments can't have—it's all a matter of automation in the end.

> The real challenges, like determining seed data etc is too project specific to be abstracted away.

Very much agree with that! The generic stuff (dependencies, parallel processing, waiting for things to spin up etc.) should be taken care of by the tooling, but without constraining the project-specific stuff (which is highly individual).

Sounds like Garden Core could be a great fit here.

The motivation behind Garden was that, like you, we had built our own home-grown kubernetes dev environments, but felt like there should be a polished, general-purpose framework + tool for this sort of thing.

(Garden co-founder here)

Garden supports in-cluster building, using buildkit or kaniko.

This way, you don't need to have Docker or k8s running on your dev machine as you're working.

It also automates the process of redeploying services and re-running tests as you're coding (since it leverages the build/deploy/test dependencies in your stack).

We also provide hot reloading of running services, which brings a similarly fast feedback loop as with local dev.

The idea is to have a dev environment that has the same capabilities as the CI environment, and to be able to run any/all of your tests without having to go through your CI system (which generally involves a lot more waiting).

Indeed! I disagree with people who think vim and emacs are ugly: they have their own nice 8bit-esque aesthetic which I'd expect hackers to like, given that they've chosen to stare at terminals all day (I've rolled my own colorscheme for both vim and emacs). And they make good use of screen real-estate, very important when coding on a laptop.

I haven't tried Evil, in my last emacs phase it wasn't mature yet IIRC - maybe I should give that a go and see if it tips the balance yet again.

Even if the mouse were quicker on average for long jumps, the moving of the hand from mouse to keyboard feels like more of a combo breaker, more distracting. Speed is very important, but equally important is for the editing experience to have a low attention footprint to leave more space for the train of thought behind the changes being made.

I rock back and forth, depending on the languages I'm using. Emacs does more, but is in my experience more kludgy, even after having in aggregate spent many days customizing it (maybe it would rub better if I wasn't hardwired to the vi/vim modal editing/motions method). Vim feels cleaner and less annoying, but sometimes the easy integration with external tools tips the balance in emacs' favor. E.g. I use vim for Rails apps (where I didn't really feel enough difference from vim + terminal), but if I were writing Clojure, stuff like the repl integration would probably mean emacs.

Sublime is really pretty, and has great functionality out of the box.

Ultimately, vi/vim's contribution is the modal editing method (and derived things like motions), which can be transplanted to any other IDE or editor that cares to support it. But for the fundamendals - editing and switching between files - I've so far found vim to be the cleanest, most natural vim.

I wonder if this could have some great research applications. A year ago I watched some lectures from Stanford on ethobiology (i.e. the branch dealing with the biological processes underlying behavior) on YouTube by Robert Sapolsky, and he talked a lot about the difficulty of figuring out what parts of the brain (and which interplays of brain centers) are responsible for behavioral patterns, especially when it comes to the more complex things. One joke was something like: "You know that feeling when someone calls you and you don't really want to talk, but feel uncomfortable with saying that actually you're busy and would rather just read a book than talk? I think we've found the brain center for that." We have learned a lot from what happens when people have certain parts of their brains damaged. But maybe we could learn much, much more about the brain by being able to fiddle around with many different kinds of signals to different brain centers, and trying out hypotheses by stimulating several centers simultaneously in order to produce (or not produce) certain behaviors?

I should have been clearer: I'm not advocating anarcho-capitalism, just having an academic discussion. My point was that a state isn't necessary to enforce contracts, although the competing entities that would theoretically replace the state are quite state-like in many ways as you point out. The Icelandic Commonwealth was anarcho-capitalistic though, wasn't it (anarchy + property rights)? Worked okay for a few hundred years.

I do see your point that anarcho-capitalism isn't really anarchism, though. The societies they envision are radically different.

> Without the state, corporations (and capitalism) are not possible.

A state is not necessary for enforcing contracts - that could be done by private parties, as in anarcho-capitalism. Also: Cooperatives can exist within a capitalist system, but the converse is not true. So I guess it comes down to whether or not all property as defined by the status quo should be redistributed or reallocated, presumably by force; if that were not the case, there wouldn't really be any disagreement between left-anarchists and anarcho-capitalists, right?

If you want a lisp that compiles to JS, ClojureScript is also a good option. It's ready for use, and there's a lot of smart people working on making it better. The Clojure/ClojureScript community is also very good - intelligent and friendly.