Live data from Hacker News

GitHub’s engineering team has moved to Codespaces

github.blog

91–100 of 704 posts

Re: GitHub’s engineering team has moved to Codespaces

#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 JAM stack, basically they use external services for *EVERYTHING*, claiming it's "The future™". They don't even own the data/database.

I'd rather make things better for users, rather than companies. Stallman's essay [The Right to Read](https://www.gnu.org/philosophy/right-to-read.html) gets more and more scary.

Re: GitHub’s engineering team has moved to Codespaces

#92
post #47

Earlier quoted context omitted.

GitHub isn't forcing anybody to use a web IDE. The most broadly used access interface is VSCode. Then there are heretics like me who choose to ssh in so we can use Vim. This is described in the article.

How does setting up a desktop IDE work?

Currently, VS Code is the primary method of connection to each Codespace, and we do not support other editors officially.

If you’re looking to connect via SSH with your desktop IDE, we do have a workaround here: https://github.com/microsoft/vscode-dev-containers/blob/main... -- and I use this regularly for Jupyter Notebooks. :)

Re: GitHub’s engineering team has moved to Codespaces

#93

Earlier quoted context omitted.

The article specifically says that they support their vim and emacs users by allowing them to SSH in edit code.

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 old fashioned way?

Re: GitHub’s engineering team has moved to Codespaces

#94
post #17
post #7

Earlier quoted context omitted.

This has not been my experience. First, I work on lots of code bases and this is where a lot of the brittleness comes from. They don’t use the same versions of the same things. Second, C dependencies are a giant pain in the ass when you add the first problem above.

Meanwhile, on BSD UNIX derivatives, I can 'make world' since the dawn of time...

You still have to grab the dependencies before running make, some of which you'll grab from apt/yum/chocolatey/macports, some you'll need to compile manually and put in a platform-dependent location, ...

Then you can run `make world`. Of course, BSD make is not completely compatible with GNU make...

Re: GitHub’s engineering team has moved to Codespaces

#96
post #19

Earlier quoted context omitted.

I am wary of requiring an internet connection in order to develop, but there seem to be more and more advantages to using something like Codespaces. The article describes using pretty much any IDE, so they are just offloading the setup and running of the development environment to the cloud while letting you run your preferred IDE locally.

An internet connection is already required for dependency management and stack overflow. I already develop with an always-on connection.

Dependency management is usually not a big part of programmer workflow (unless you are a devops or something). Download dependencies and docs, go offline, write code.

People who try working offline are exactly the people who want to do it without Stackoverflow.

Re: GitHub’s engineering team has moved to Codespaces

#97

Earlier quoted context omitted.

I would be happy to let go of an employee who bank their employment on the preference of toolings. Hear me out: Toolings are, like the name suggests, a means to an end. If a web IDE is fast, works reasonably, and can continue improve itself. And the learning curve is friendly to engineers with different background and experience. Everyone should be comfortable to be nudged to use it. And if the tool additionally is a…

Yeah, whenever I hear this kind of rhetoric - if my company ever required it's time for a new job - I roll my eyes. Sure, keep pushing yourself out of more companies, there are a lot of good engineers* who will be absolutely as productive as you and who won't be a drain on everyone around them. *it's always engineers making these statements or I only know engineers

[deleted]

Re: GitHub’s engineering team has moved to Codespaces

#98
post #26

Is the direction in which all software development is heading?

The team here is part of the company that markets Codespaces. They're not actually representative of other companies, so I wouldn't take this as a direction all software development would be taking.

Re: GitHub’s engineering team has moved to Codespaces

#99

> "So we moved to 32 core, 64 GB RAM VMs. By changing a single line of configuration, we upgraded every engineer’s machine." On GitHub, that instance type is $2.88/hour or $2,073 monthly per developer for a single instance. (Granted, that's running 24/7 but still - wow, that's expensive for a single instance)

While that does sound quite expensive, companies typically have a limited budget for employee laptops, but appear to have almost unlimited budget for cloud hosted testing environments, which usually have many instances (and services like RDS / Redis etc)

Re: GitHub’s engineering team has moved to Codespaces

#100
post #14

Maybe they should have used Nix to get a dev environment that is identical for everyone... but that would be too easy. The future is long term probably in the web, I'm just not sure we are there yet.

Buy a Cachix subscription and now the org can build once on the local dev's machine, push to the service, then other users and machines can download & run anywhere the reproducible 'apps' on local dev machines, CI, and even production. CI can even build and push the architectures that aren't specific to your local machine to cover just about everything.
Post reply on HN