Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub’s engineering team has moved to Codespaces

github.blog

Post reply on HN
Print view View original

131–140 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#131

Post by jordemort »

I wonder why they're not telling the security & compliance side of the story here. Getting rid of local development means they have to worry a lot less about what's going on on their engineers' workstations. They've reduced them to dumb clients; any code going in or out of the repository has to be created, or at least pass through, a VM that GitHub controls. That lets them move the security boundary; I wouldn't be surprised if the next step is to cut off the ability to clone or push to certain sensitive repositories from outside of Codespaces.

That being said, while it has a lot of advantages from an enterprise perspective, I wouldn't want to live that way :)

Re: GitHub’s engineering team has moved to Codespaces

#134

Post by simonw »

The amount of time I've seen lost to engineers spinning up (or fixing) development environments is staggering. This kind of thing is going to save SO much money.

(I've run a team responsible for the tooling for a company's development environments in the past so this hits really close to home.)

Re: GitHub’s engineering team has moved to Codespaces

#135

Post by Raed667 »

keithwhor wrote: post #115
gosukiwi wrote: post #91

Ugh, now not only you don't own your code ( ahem copilot cough ) you also don't own the tools to develop code. The direction the web is taking is worrisome. The issue is not so much senior devs, but new devs. If they start off with things like that, there' so much magic under the hood, they won't understand how anything works. They don't understand they don't own shit until it's too late. I remember when I first saw…

The same thing was said about every programming abstraction to ever be introduced. How do we expect people to build memory-efficient applications when they become reliant on a garbage collector?

The difference is that you don't pay a monthly subscription to use a garbage collector.

Re: GitHub’s engineering team has moved to Codespaces

#136

Post by decebalus1 »

gedy wrote: post #2

Unpopular opinion with a lot of my peers, but "fragile local dev environment" is usually a sign of an unwieldy, tightly coupled codebase with a lot of parts, scripts, etc. Trying to hide that complexity with docker or codespaces, etc is just a bandaid in many cases vs dealing with the root issues.

It depends on how exactly the tools are used. If you're using docker for reproducible builds with locked-in/platform specific versions of dependencies that need to work seamlessly across platforms then that's pretty good. If you NEED docker/codespaces/etc.. because in order to do basic development and run tests you need N servers running with some specific state, duct taped with non-idempotent bash scripts then this type of stuff is just piling on tech debt.

Re: GitHub’s engineering team has moved to Codespaces

#137

Post by geofft »

gosukiwi wrote: post #91

Ugh, now not only you don't own your code ( ahem copilot cough ) you also don't own the tools to develop code. The direction the web is taking is worrisome. The issue is not so much senior devs, but new devs. If they start off with things like that, there' so much magic under the hood, they won't understand how anything works. They don't understand they don't own shit until it's too late. I remember when I first saw…

I assume a huge part of why GitHub is okay with this is that VS Code / Codespaces and Azure are both products from the same company. :)

I do think there's a serious autonomy question here, and I think companies do actually care a lot about maintaining their autonomy from other companies, and in many cases the incentives align a lot. The whole stack here seems like something that you can run internally / self-host:

- Codespaces are specially-configured containers. All the standard infrastructure for running containers (Docker, Kubernetes, etc.) is FOSS and is quite reasonable to run internally. It's not even like OpenStack where it's a knockoff product of what the major cloud vendors run: it's literally what the cloud vendors run.

- Shallow clones, pre-built running containers, etc. are all deployment practices, not products.

- You can ssh into a codespace.

The big problem here in my eyes is that it's reliant on VS Code, whose remoting stuff is not FOSS (and, having tried it at my own workplace pointing it at our self-hosted Kubernetes, it's been a pain to get it to work well with our authentication setup, proxies, etc. without access to the code and we have a number of open bugs filed). I think the challenge is for a free-software IDE to adopt the VS Code model of the IDE running locally but executing code (including running the LSP backend) remotely.

And, in a sense, Emacs already supports this just fine with TRAMP. It's just that the experience of using Emacs and the experience of using any modern IDE (VS Code, any of the JetBrains IDEs, whatever) are very different... and none of them are FOSS.

If you have a FOSS IDE, I think you can get this whole setup working well in a way where you have autonomy over the setup and where you can understand the details just fine. And even if you're using VS Code, you can set all of this up in a way where you're not contacting any external services.

Re: GitHub’s engineering team has moved to Codespaces

#138

Post by AYBABTME »

gosukiwi wrote: post #91

Ugh, now not only you don't own your code ( ahem copilot cough ) you also don't own the tools to develop code. The direction the web is taking is worrisome. The issue is not so much senior devs, but new devs. If they start off with things like that, there' so much magic under the hood, they won't understand how anything works. They don't understand they don't own shit until it's too late. I remember when I first saw…

The real problem that Codespace for stuff like the GitHub codebase solves, is not having to bring up the dev environment. Non trivial, organically certifiably grown commercial software has bunch of services that all eat different things in winter. And things like the Rails monolith that GitHub's main service is, have a tendency of being rude to a dev's laptop, squatting the place with whatever port and file they want laying around, installing packages and software to variously namespaced-or-not locations. If you deal with any set of service, they'll all have various hygiene standards and run well or not on your machine, depending on wether your machine looks like the core dev's machine. And then everyone famously wants a custom work machine with freedom to manage it however they want.

Codespace stuff is a way out of insanity. It's a mediated common ground. You could standardize on Docker or Vagrant or whatever, but they come with a lot of pitfalls and the local dev story with them all kind of suck. Codespace on the other hand is a solution that mostly doesn't suck. It's actually a pretty decent experience.

Re: GitHub’s engineering team has moved to Codespaces

#139

Post by [deleted] »

gosukiwi wrote: post #91

Ugh, now not only you don't own your code ( ahem copilot cough ) you also don't own the tools to develop code. The direction the web is taking is worrisome. The issue is not so much senior devs, but new devs. If they start off with things like that, there' so much magic under the hood, they won't understand how anything works. They don't understand they don't own shit until it's too late. I remember when I first saw…

[deleted]

Re: GitHub’s engineering team has moved to Codespaces

#140

Post by tptacek »

mastax wrote: post #93
blueplanet200 wrote: post #49

Earlier quoted context omitted.

The article says they support web based development, or ssh'ing into the codespaces machine. There are other IDEs besides VS Code and shell based ones.

Don't most IDE's have the ability to edit remote files over SSH? I know VSCode can, and I remember reading a comment from an emacs user doing that. It looks like IntelliJ can do that too, though it seems to edit local copies of files and sync over SSH. There's also SSHFS, though I don't know how good of an experience that is. It can be a pain to set up, but is it more of a pain than setting up a dev environment the o…

Emacs has TRAMP, which does a very credible job of making remote resources appear local, not just to edits but to most Emacs libraries as well. Its most normal mode of operation is over SSH. It's not very hard to set up and it's pretty magical once it is. Even Magit just works. I was skeptical earlier this year, but 6 months later I'm doing 80-90% of my development in TRAMP buffers without thinking about it.
Post reply on HN