Live data from Hacker News

Virtualizing development environments in 2023

hocus.dev

71–76 of 76 posts

Re: Virtualizing development environments in 2023

#71

Earlier quoted context omitted.

If your stack is trivially setup via a docker-compose script, great! there are more complex systems out there for which that's insufficient.

I think they meant Nix.

I didn't mean one specific thing. There are numerous tools in this space that approach the problem from different angles using different technologies.

My point really, was if your local dev environment requires you to jump through a bunch of hoops doing manual setup to get it working you're doing it wrong.

Re: Virtualizing development environments in 2023

#72
post #62

Earlier quoted context omitted.

Don't use VirtualBox. It's literally the shittiest VM you can choose.

What other option do you have if you want to support developers across Linux/Mac/Windows? VMWare player? Besides it not being OSS, I didn't notice any performance benefit. The bottleneck (for my web development needs), is around the spottiness of shared folders and JS tooling that needs to keep a watch for file changes.

If you're using vagrant to manage the VM and either use widely-supported or self built base boxes, each developer can use whichever works best on their platform.

So you might have a windows dev using hyperv, another usimg vmware workstation, a mac user with parallels, a linux user with lxc and another with kvm.

Re: Virtualizing development environments in 2023

#73

Earlier quoted context omitted.

I think this hits the nail on the head. Plenty of companies have software stacks so large / complex to configure that there's no reasonable way to run the entire system on a single laptop. As much as I dislike the experience of remote dev environments in general, there are certainly times where it may be worth the pain.

> have software stacks so large / complex to configure I think that’s your problem right there

I haven't worked at many places like this, but the last time I did they had services that managed and operated on petabytes worth of data. The full suite of front end applications, rest services, ingestion services, maintenance, queues, billing, communication, scheduling and other systems is large enough that I probably only saw the source code for maybe 1/3 at most, let alone modified.

I do like local development better, every time it is feasible, but there's not much point in doing so if it can't reasonably reproduce a production system.

Re: Virtualizing development environments in 2023

#75
I keep trying to use Jetbrains Gateway. It spins up the IDE on a remote machine and renders it locally.

I honestly can't find a use for it. My personal machines are ancient quad core setups, but I have a beefy server at my disposal.

But the benefit of faster build times isn't worth the hassle. Between the suboptimal performance of the remote interface, syncing files back to my local machine, and all of the little idiosyncrasies of setting up the remote environment, it's still faster to develop locally. I just go grab a glass of water when I start my compile.

This might make more sense if you're working on some C++ monstrosity with millions of lines of code that takes hours to build on a mainframe, but if you're in the region of minutes per build, there's just no benefit.

Or I guess if all you have is a thin client, this might be better than nothing. But then again, you can get an IDE and compiler for most languages on an android tablet. If you have a machine with a processor, it can compile your code.

Re: Virtualizing development environments in 2023

#76

Earlier quoted context omitted.

I think this hits the nail on the head. Plenty of companies have software stacks so large / complex to configure that there's no reasonable way to run the entire system on a single laptop. As much as I dislike the experience of remote dev environments in general, there are certainly times where it may be worth the pain.

> have software stacks so large / complex to configure I think that’s your problem right there

Sometimes thing are just comped complex. I know we want to see epicycles and simplify and be able to reduce the system, and sometimes that's even possible. (Don't get me started on being all in on all of AWS.) But sometimes it isn't and, well, that's where we are as an industry.
Post reply on HN