lostintangent

Personally, I find “learning through demystification” really effective. So putting the humor aside, I’d love to see more things written like this.

GitHub Next is 18 people (inclusive of all roles), which seems appropriately-sized to be called a “team” (certainly in a large engineering company).

But apologies if that came off as misleading.

We felt like there was sufficient difference between the two products, that there wouldn’t be any confusion. Especially with the target audience that GitHub Spark ultimately intends to reach.

That said, we plan to validate this during the Technical Preview phase. Since we absolutely want to be respectful of Apache Spark, and its impact on software.

You can see the originating issue and the resulting PR from there. And note that while the initial spec/plan/code was mostly good, I iterated on a couple parts of the plan, and then made a minor tweak to the code manually (everything in CW is editable). Which is a key part of our goal with CW: to help bootstrap you with a task (or think out loud with AI), and then provide the iteration primitives to explore further.

In the meantime, when you open a Codespace from Copilot Workspace, you could open that Codespace in VS Code desktop. And use that as a companion editor to the web client (since we bi-directionally sync file changes between them). But totally agreed that a more integrated VS Code experience will be compelling!

That said, I’m optimistic that tool builders can take on a lot of that responsibility, and create abstractions that allow developer to focus solely on their code, and the problem at hand.

And so while we want to help generate code for tasks (e.g. from issue->PR), we also find that it's just super helpful to take an idea and make it more tangible/concrete. And then use that Workspace session to drive a conversation amongst the team, or spark the implementation. Especially since that might only take a couple clicks.

Within the GitHub Next team, I'll often file issues on one of the team's project repos, and then pause for a moment, before realizing I'm actually curious how it might be accomplished. So I'll open it in CW, iterate a bit on the plan, and then either 1) realize it's simple enough to just fix it, or 2) understand more about my intentions and use a shared session to drive a discussion with the team. But in either case, it's pretty nice to give my curiosity the space to progress forward, and also, capitalize on serendipitous learning opportunities.

So while AI-powered code generation is clearly compelling, I agree with you that there are other, more broadly interesting benefits to the idea->code environment that CW is trying to explore. We have a LOT of work to do, but I'm excited about the potential :)

Out of curiosity: is your excitement about ActivityPub, based largely on a greater amount of perceived engagement, as compared to other channels?

As an aside, it would be cool if you versioned that notebook in the repo, so that it could be easily opened with Codespaces.

This is a commonly cited book about “strategic thinking”. But despite that, it’s one of the few business books that I actually read every page (as opposed to spotting fluff and selectively skipping pages), and it had a notable impact on the way I think/write/communicate.

In general, I’m curious whether there’s significant value in someone who is using Node or Python (for example), to look for a way to use the actor pattern. Or if actors are primarily great when used along with platforms that specifically “elevate” this concurrency model? (e.g. Erlang/Elixir, Java/Scala, .NET)

And could you share the distinction between typed and untyped actors? Is that related to how the caller addresses/accesses methods on that actor?

If someone were using Go routines and channels, what do you think is the “clear” moment that they would benefit from actors? When the sequence of steps in a workflow are non-deterministic?

Any plans to add support for gists to Hubfs?

Out of curiosity: did you add support for multiple backends because you don’t think Git will ultimately be sufficient for the experience you want to create? Or did you just want to ensure that the tool didn’t become unnecessarily coupled to Git?

Personally, I don’t find that I do a lot of “deep writing” on my phone, as opposed to quick recall or in-the-moment scratch padding. So as long as I have a way to access my notes, make quick edits, and then sync them with my laptop (where I’ll do my primary thinking later), then I’m pretty content.

I also _really_ like the concept of “spells”, so congrats on this experience as well. It would be interesting to explore implementing the same behavior using GitHub Actions (many of which, probably already exist?), with push/cron triggers. The benefit of that is that you could share your note taking workflow as a repo template, and then others could fork it and be up-and-running without any new accounts/tools/etc.

I'm actually a PM for both Live Share, Codespaces, and some of our education-related experiences (e.g. the GitHub Classroom extension for VS Code). A web client for collaboration, with zero-install/onboarding, has always been our north star, and so your intuition/feedback was 100% right back in 2018.

Now that we have Codespaces, vscode.dev/github.dev, and Live Share support for the web, we're actually looking to further optimize our support for education, since we believe we have a lot to offer. In fact, I'd love to connect and hear your thoughts, to make sure we're going in the right direction. If you'd be interested in letting me make up for that terrible conversation in 2018, you can reach me at joncart@microsoft.com. Thanks for sharing this feedback, and letting us know where we can do better.