Rails in the Age of Kubernetes
medium.com6 pointsby ths0 comments
So under its expressive covers, everything about Clojure is strongly
conservative, with a core overriding bias towards protecting
programmers from mistakes.
(let ((x 2) (y 3))
(let ((x 7) (z (+ x y)))
(* z x)))
(let [x 2 y 3]
(let [x 7 z (+ x y)]
(* z x)))
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).