←back to thread

Tilt: dev environment as code

(github.com)
136 points saikatsg | 2 comments | 26 Apr 25 19:14 UTC | HN request time: 0.838s | source
Show context
hamandcheese ◴[27 Apr 25 01:24 UTC] No.43808716[source]▶
I still think "dev environments" really ought to be running tests directly with your languages native tool. e.g. `cargo test`, `bundle exec rspec`, etc. If you make me run a VM that runs Kubernetes that runs a docker container that runs the tests, I will be very, very upset. Doing this properly and reliably can still be a lot of work, possibly more work if not relying on Docker is a design goal (which must be if you want to run natively on macOS).

There seem to be a lot of tools in this space. I wish they wouldn't call themselves tools for "dev environments" when they are really more like tools for "deploying an app to your local machine", which is rather different.

replies(3): >>43809231 #>>43810096 #>>43812090 #
SOLAR_FIELDS ◴[27 Apr 25 14:13 UTC] No.43812090[source]▶
I actually have the exact opposite viewpoint: if you’re managing a platform with multiple teams what you are suggesting is way more of a pain than a standardized, container based workflow. You want a language agnostic test runner that runs generic commands. The reason for this is that you want to be able to quickly skill up engineers and have them able to quickly switch codebases since the interface (like tilt) is the same across all of them.

You give up a bit of snappiness, sure, but you can also keep the very small non container based tooling like linting outside of the container.

replies(1): >>43828431 #
1. hamandcheese ◴[29 Apr 25 03:20 UTC] No.43828431[source]▶
> You give up a bit of snappiness, sure, but you can also keep the very small non container based tooling like linting outside of the container.

You give up way more than snappiness. Doing real development work, i.e. compiling, testing, debugging, is very cumbersome in a remote environment.

So where do you want to spend your time? Bandaids to make remote development suck less, or effort to develop locally, natively? There is no free lunch. If you choose "neither", your developer experience is gonna suck. (Most companies choose "neither" by the way, either consciously or unconsciously).

replies(1): >>43840515 #
2. SOLAR_FIELDS ◴[30 Apr 25 02:19 UTC] No.43840515[source]▶
> Doing real development work, i.e. compiling, testing, debugging, is very cumbersome in a remote environment.

it really isn’t? Of course it depends on the ecosystem. But for jvm for example you literally just expose your debugging port 5005 out of the container and boom step through, and other live debugging works just as well as outside of the container. And as of course you allude to, if you’re native you are facing a “works on my machine” problem unless you are all in on a hermetic and reproducible solution like bazel or nix. And chances are unless you are having that crack team of 10xers that a good hunk of your dev user base are going to struggle with the complexity and general ecosystem issues with these two solutions.

You’ve probably seen the worst world where people do containers wrong. And a lot of people do them wrong. But it’s pretty easy to learn how to do them right. Someone can study multi stage docker builds for half a day and write perfectly fast, cached first containerized builds. Proper buildkit cached local containers are extremely fast.

There’s other ways of course, each with their own tradeoffs. You can do everything in nix, and now you are spending your time fighting with nix. You can do everything in bazel and now you are spending time fighting with bazel. In the end your stuff is gonna go into a container anyway (for most people). You still need to understand the container technology because of that. so why not both reduce your toolchain sprawl and simultaneously recreate that exact environment on the local machine?