Hacker News Reader

Comment by lucideer | Hacker News Reader

> My friends, I’m here to tell you I was a Codespaces skeptic before this started and now I am not. This is the way. ~@iolsen

I don't actually doubt that this (and the 4 other glowing employee quotes) are real, but even assuming they are, I can understand people remaining skeptical about the sample size of 5 being broadly representative of the 100s (1000s?) of engineers at the company.

Also slightly hilarious that "This is the way" is a Star Wars callback referring to a character blindly following dogma before eventually realising the error of their ways...

On the other hand, there's quite a few "hints" littered throughout the article that their current setup is a bit of a beast, so I can definitely imagine some engineers being relieved to be able to get such a behemoth off their physical laps/desks: I guess if the local development experience is sufficiently brittle & frustrating, any alternative may seem welcome.

View on HN

I’ve very recently become a GitHub engineer, and I got pre-access to the beta too and I must say - my absolute favourite thing about CoseSpaces is being able to dev on a repo you don’t work on regularly and probably wouldn’t contribute if it meant having to set up environment etc. It’s really nice to just dip into a project with a working environment in seconds, make your PR and then move on.

This is a problem that can be solved without Codespaces too. For example, if GitHub were to embrace Nix, every project could have a shell.nix file for all of their dependencies, and the new engineer bootstrap script that installs Nix could then just add an internal Nix binary cache (or use Cachix). Any time the shell.nix changes a GitHub Action could push the closure to the binary cache.

With this setup, you can use whatever local tool you want and, as long as environment variables are respected, they’ll just work. The only requirement on your end is to either run nix-shell first, or to use direnv and ask it to load the nix env for you.

The downside is you still are compiling locally, so you still need sufficient CPU/memory resources, but that’s it.

Unfortunately most companies still aren’t paying any attention to Nix.

-insert comment about that hacker news comment about how dropbox could be replicated with linux here-

I'm not sure that comment applies here. The suggest Dropbox replacement was more complicated than Dropbox, and had more steps. On the other hand, Nix is about the same amount of complexity, and same number of steps for the developer.

Yes, the parent comment looks a bit complicated, but that's just the one time setup, not something that needs to be done by every developer. And Codespaces will require some of that setup too; it's not like it'll magically know what packages and dependancies your project requires to build.

- I see comment about iPod, no wireless, less space than a nomad. lame

Nix is a prototype-grade implementation of a very narrowly useful model of computation.

Does it take 10 seconds to spin a new one up?

If not, then it misses the main benefit outlined in the article.

Yeah, it’s really fast. In fact before I joined, I also set up a default CodeSpaces environment for my own repo and then I was up and running in only a few minutes, and that was the first time so I was learning and reading the docs. I could then set up all subsequent new CodeSpaces to start in seconds.

But yes, once a project commits to using CodeSpaces dev environment (even and especially ones with large code / heavyweight environments) there is a lot that can be done to optimise the spawn up time, that cannot be done as easily for local dev.

How does it work when you work on several packages at once,e.g. a lib and an app using it? Is it a monorepo, do you configure both dependencies to be locally editable copies, etc.? For example patching an upstream open source project that is a blocker for your app.

You can also create a separate codespace for each package if they’re independent of each other and you don’t need to test things in the downstream repo in a way that requires your changes being available “locally”.

The codespace is backed by a regular Linux VM, so we can clone the upstream repo and edit/compile/debug/etc in that just like we would locally on our laptops and workstations.

This was my first idea for introducing Codespaces to my team -- set up the infrastructure to be able to spin up a codespace on our less-used component repos where people don't have a local dev environment prepared.

I'm a big fan of capturing the toolchain(s) with the repo. I have had to hack this for embedded toolchains out of necessity for years (decades?) using VirtualBox on a Mac. I still have a Windows 95 VM sitting around containing a copy of Keil or something that is the only known way to rebuild the code for a certain weird-ass micro from some consulting gig in the late 90's. I wonder if it still boots? Hopefully, that customer forgot about me...

> . It’s really nice to just dip into a project with a working environment in seconds, make your PR and then move on.

That sounds incredibly useful actually. Is that the main sales pitch for codespaces?

Well I use them for regular dev in work too on especially larger repos with heavier toolchains, and both are big plusses for me personally!

I've been playing around with a homegrown version of this. It's really not that hard: just set up a docker context to your home lab server and use VSCode remote containers.

I've been able to remove WSL from my PC: Docker desktop was gouging itself on resources. I can now also shut down my desktop and continue exactly where I was on my laptop, and visa-versa. I don't have to pull WIP commits back and forth between the two machines.

It's a major leap forward, and there is no need to use GitHub infra.

I also started doing this, but using containers locally (on a Mac). The ability to have a set dev environment without needing to install local programs or compilers is great. And really once you flip to this model, it doesn’t matter if you’re running your dev in a container or remote VM. So long as you can get a command line to your dev environment, it really doesn’t matter where it is.

(Or who hosts it)

Though I like this model, the problem with dev containers on macOS is that the disk io is bog slow. This makes some IO heavy tasks (pip install, npm install) painfully slow.

I have started to run some dev tasks on a remote Linux server, with Dockers, and then just configured automatic file sync on save over SSH.

> This makes some IO heavy tasks (pip install, npm install) painfully slow.

Aside/HTH: The new Yarn has "Plug 'n Play"[1]. They claim that committing [their version of] node_modules is a reasonable thing to do, so that's one way to avoid install entirely. I don't trust that claim, yet (it smells like noisy diffs). You can instead re-enable the global cache[2], and then mirror your host cache directory into your container (whatever `yarn cache dir` gives you).

I have tried none of this myself because I'm not working on anything JS right now. pnpm[3] is what I've been using up til now, and is also a direct upgrade in terms of speed (but I suspect it won't work with mounting host directories).

[1]: https://classic.yarnpkg.com/en/docs/pnp/ [2]: https://yarnpkg.com/features/offline-cache#sharing-the-cache [3]: https://pnpm.io/

Very true. It really depends on what the workflow is. But once you’ve already moved to a disconnected dev environment, moving from a container to remote server is a small step.

I've never used Docker. Is this sort of like using tmux/vim on a cloud server?

I'm guessing that VSCode has a distinct back-end and front-end. It's able to run the back-end server on the remote machine/container/whatever over a bog-standard SSH tunnel. Any autocomplete functionality, debugging, etc. will use the resources on the remote machine. It also does port forwarding for you. The front-end (GUI) runs on your local machine.

A closer analogy would be using Plan9, and mounting most of your cloud machine locally. Vim would then just be your local front-end into those mount points.

Containers/docker add the ability to share your exact machine configuration with someone else, and have them create their own copy of it with a single command. It would be almost like sharing a VM image with your team. There's been a lot written about the pros/cons of containers, but they achieve similar goals to VMs, and so-happen to bring a lot to the table in this scenario.

I'm not sure why you're being downvoted, that's a very good question. The short answer is yes*, plus some automation around spinning up a new session.

The wrinkle is that the display server is running on your local machine, and connecting to the thread of execution on the remote server. Vim doesn't really have that concept of separating view from control, but tmux does play a somewhat similar roll.

It is hard when you have millions of commits, thousands a day, and your monorepo is measured in gigs.

VS Code remotes are magic. I use a light version of it for 100% of my development on windows with WSL, but I also use it to log into a mac server and edit files on that.

I have no idea what actually went into developing the feature, but I would have to suspect that Electron would have contributed to making the separation of an app client vs server easier than something totally "native".

So how do you edit media files, using some ssh fuse mount magic ? What happen when you need to work from a shitty internet network ? In train ?

> So how do you edit media file

This only does code. You'd probably have to do those locally and SCP them over or, yeah, some mount magic.

> What happen when you need to work from a shitty internet network ? In train ?

You'd have to commit your work, but you'd be able to bring the environment up on your laptop. There are still merits to this, such as the repeatable nature of containers. Depending on where you've worked, you may have been through the hell of a huge list of setup steps when on-boarding a project: that's one thing that containers are really good at automating.

You may not be the target audience, though.

> this only does code.

VS Code remotes allows you to drag and drop files from your desktop and they're placed where you want them in your remote environment. I don't understand why this would be any different.

You edit media file in an editor?, wouldn't you just upload it? You can drag& drop into vscode and probably find the path to the tmp folder and work off that too.

oh right, my home lab server, that must be around here somewhere...

They aren't as expensive as you'd expect[1][2] ($70-$200). Hell, you could use a RPi for many use cases.

In my case, my homelab is my laptop (which I connect to from my desktop). I don't actually have a server blade lying around (although those can also be relatively cheap when big cloud upgrades their servers).

[1]: https://www.ebay.com/sch/i.html?_nkw=dell+optiplex+3040+micr... [2]: https://www.ebay.com/sch/i.html?_nkw=intel+nuc&_udhi=200&_ud...

I pay 30$ a month for a server (yes, a virtual one, if you want docker, you have to pay a bit more) with org-domain and tls cert. I would recommend that to every developer. Yes, some administrative work is required but that is also a valuable learning experience. You would own all the tools that you need to develop efficiently.

Personally I use Gitea, which should be usable by someone used to Github. I don't switch workspaces too often, but I am sure some tools are available.

I have an HP 4u from 2010 with 80 threads and I think a quarter TB of memory, 6 SAS, and 2 1TB ssd, currently running Ubuntu 16 and Wok, for VMs. It took a lot of effort to get this working and it's still a huge pain - I have no UPS for it since it uses 220VAC, and UPS cost more than the server cost me, for example.

I can't use docker in general because my internet is too crappy. That was annoying in 2012 when I first used it, but it's even worse now. I've always worked with VMs, since 2001 or earlier - virtualbox, wok, AWS, wok, and now proxmox.

It helps to know what your use case is, I don't run a ton of VMs, just one or two at a time that can use almost all of the resources of the server, and I generally do infrastructure and computing work in general.

I presume none of this counts as a homelab, though, since I don't program in rust.

> It took a lot of effort to get this working and it's still a huge pain

You make an attractive case it for! :) Yeah, this is why I don't have a "home lab".

> Also slightly hilarious that "This is the way" is a Star Wars callback referring to a character blindly following dogma before eventually realising the error of their ways...

My friends, I’m here to tell you I was a Codespaces skeptic before order 66 and now I am not. Good engineers follow orders.

Brittle local development in from what I've seen is either due to another symptom of tech debt - an aging monolith with too many different build systems, dependencies and what have you that you end up with way too many Docker containers or the need to have a very long doc for newcomers with "run this script here, then that script there, unless it's a Monday, then run this script over there". Or a team that's gone all-in on a distributed microservices architecture with lambdas all over the place and a dozen or more repos and it's literally impossible (yes there's LocalStack but...) to get a faithful end-to-end local environment up and running.

The nightmarish local development experience of either case are symptoms of deeper issues than local development itself being a problem.

It's also a sample of people who, if they run into issues with Codespaces, are just a Slack message away from someone who can fix it.

yes but thats the great thing about dogfooding. give it a year or two of this tight feedback loop and Codespaces will be really really solid

Given that they apparently couldn't get their setup scripts in order[0] in 13 years I wouldn't get my hopes up.

[0]: https://news.ycombinator.com/item?id=28145556

Do you know whether they use the public Codespaces or a customized version?

I don't. My initial comment is assuming they use the public version. Whether they use the public or a private version they still have back-channels for support that the rest of us don't have access to.

Not about Codespaces, but about Web IDEs in general, they're amazing. I've not used Codespaces but I have used what is being talked about here [0]. It's one of the biggest productivity improvements I've seen from Google. I never really have to think about what packages or software is setup on my laptop and I can change laptops or computers while having the entire state of my IDE preserved. It's a pretty amazing experience.

The only people who I don't think would instantly like this sort of thing are people like game developers who basically don't do any unit testing of their code and run the binaries they generate. For those users you could find quite a few ways around that.

[0] - https://www.quora.com/What-does-Googles-web-IDE-look-like

I think people like not having their physical machine tied to their dev environment. IMO "the way" to do this is with ssh and tmux, not a web app. As long as people have choices I guess it doesn't matter.

If you read the article, that's an option with Github's code spaces setup.

> Visual Studio Code is great. It’s the primary tool GitHub.com engineers use to interface with codespaces. But asking our Vim and Emacs users to commit to a graphical editor is less great. If Codespaces was our future, we had to bring everyone along.

snip

> From there, GitHub engineers can run Vim, Emacs, or even ed if they so desire.

I did not understand that part. Every heavy Emacs or vim user have its own customizations of editor. How does it work with shared image?

The repo owner gets to define the base Docker image that’s used in the codespace. And then it also looks for a dotfiles repo under your user account, which you can use to install all of your personal customizations. You can see mine at https://github.com/dcreager/dotfiles

The codespaces can have their own dotfiles.

Just use an sshfs mount and a local editor.

I think this defeats the purpose of Codespaces, because it would mean that all the code runs locally and only thing that remote server provides is storage?

The lame part is that they have to spin up vscode just to ssh

Quotee here. I agree! I use tmux and vim via ssh for github.com development in Codespaces.

Interesting… Can you use Neovim? Can you persist you custom vimrc config and plugins between sessions?

Yes, I use neovim myself! Codespaces looks for a dotfiles repo under your user account, which you can use to install any personal customizations. Mine, which installs a bunch of neovim plugins and configs, is here: https://github.com/dcreager/dotfiles

Ah, fantastic! That sounds like a really good solution. I also have my carefully crafted configuration preferences for Neovim, and wouldn’t be happy with codespaces it didn’t allow me to configure it. But for what you are telling me, they have done it in a smart way. Nice. And it’s nice that they had the people who work mostly in the terminal in mind when creating this. Neovim is a great editor right now, it has been such a fantastic evolution over Vim, adding a language server, for example. Cheers, thanks for replying.

> I think people like not having their physical machine tied to their dev environment.

I'm curious to know if this statement is true. Most experienced developers these days have a regular desk and a chair where they like to code and focus. How prevalent is the move-and-code scenario?

It's not just that. There is also the matter of laptop getting broken (we all have proper backups, right? right?), stolen, ...

So I do see the appeal in thin client. My only issue is that the experience his closely tied to latency, so sometimes working over ssh is... irritating. Especially on mobile connection.

It’s all Docker images under the covers, so our devs also have the option of downloading and running that image locally instead of in a Codespaces VM. That was always possible before, of course, but Codespaces gave us the impetus to invest the effort in Dockerizing the dev environment more rigorously.

Oh, that is cool. Sounds like a nice mix actually. Local vim, browsers, known system. And container with mount-bind to actually compile and run stuff in.

I like it a lot.

My usually setup is chrome dev tools and some node servers fired up, so quite easy to replicate.

But I still prefer to just move my laptop around.

Thank you for ruining the mandalorian. I just started season 2.

Reply on news.ycombinator.com