lostintangent

This is so fun, and I just learned a couple things from it :)

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

Out of curiosity: what size do you think constitutes a “team” vs. a “department”?

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 (the GitHub Next team) use and love Apache Spark. So we made sure to connect with ASF before releasing GitHub Spark, and confirm they were comfortable with us using this name.

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.

If folks want to see what Copilot Workspace looks like, here’s a sample session where I addressed a feature request in an OSS VS Code extension I maintain: https://copilot-workspace.githubnext.com/lostintangent/gitdo....

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.

We definitely intend to explore a VS Code extension in the not too distant future. And we decided to build a web client + integrated cloud terminal, simply because that allowed us to create an experience that is one-click away from an issue, and could be accessed from anywhere and any device (i.e. we’ve deeply optimized CW for mobile, and I do quite a bit of code thinking in that modality).

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!

I can definitely echo the challenges of debugging non-trivial LLM apps, and making sure you have the right evals to validate progress. I spent many hours optimizing Copilot Workspace, and there is definitely both an art and a science to it :)

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.

One of our main goals with Copilot Workspace is to help offer a "thought partner"/rubber duck for developers, and potentially even other members of a software team (as you said, PMs, designers, etc.). And code generation is obviously just one means of helping you think through a problem, along with a fleshed out spec (what are you trying to accomplish?), and plan for how to approach the problem (how might you actually accomplish it?).

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 :)

Is this like Weights & Biases for prompt-based LLM experimentation (as opposed to model training)?

No one interacts with my tweets anymore. Meanwhile, I get response on Mastodon that reminds me of the early days of Twitter, before they betrayed their developer community and hired a legion of people to cut ad deals.

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

Wow, this looks awesome! I noticed that the sample notebook doesn’t include SD 2.0 by default, and says that it’s too big for Colab. Is that a disk size/RAM limitation?

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

Understanding Michael Porter: The Essential Guide to Competition and Strategy

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.

True! But you don’t need actors to enable horizontal scaling?

Ah! That makes total sense. Thanks so much for that additional context.

Then how do any of these distributed systems tools/frameworks write a meaningful or concise landing page? Making informed trade-offs are obviously important. But in a world of saturated information, it seems like there’s even more value in being hyper clear about what the purpose of a thing is? And even better, what it’s _not_. Unfortunately, many of these tools claim to be broadly applicable, in a way that makes it hard to understand their true purpose, without also investing significant time into them. That seems kind of unfortunate.

Any insights that you’d want to share with someone not using Java/Scala or Erlang/Elixir? I’d love to get the benefits of actors in Node, Python or Go, but I’m not entirely sure what I’m missing yet.

How much of the value in actors do you think is related to the awesomeness of the Akka framework specifically? I only ask since it seems like there’s a decent correlation between people using Akka, and those that identify as using “actors”.

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)

Are you using Akka for your explicit actors as well?

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

I _really_ appreciate this reply! Naively speaking, when I look at actors, I just can’t think of why they’d be superior to coordinated queues/channels, except for within an arbitrarily configurable, rules-based system (e.g. game NPC behavior, network routing). But I couldn’t help but assume this was dramatically oversimplifying the problem/missing the point.

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?

Very dumb question: when you say backed by Akka, what exactly do you mean? That you’ve configured a “binding” between Flint/Spark and Akka, which spins up actor instances (Java/Scala classes?) whenever some events occur? Or that Flint/Spark use Akka behind the scenes?

Yeah good point! Though I was also thinking about the ability to easily create/edit/delete gists, by means of file system operations. For example, it would be pretty cool if you could create a directory in some “gists” mount point, and have it transparently create a gist for it. Then, as you add/edit/delete files in that directory, those changes are reflected in the gist’s repo.

Very cool! I love using GitHub repos and gists for managing my personal notes/code snippets, and currently use GistPad as an editor-level virtual file system (for VS Code). But having an OS-level equivalent is _super_ useful.

Any plans to add support for gists to Hubfs?

Out of curiosity: what is it about Observable that you don’t care for?

This is awesome! And it’s so exciting to see folks investing energy into this problem space.

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?

Looks really interesting! Thanks for sharing

Yeah GitJournal is great. I used it for a while, and the dev is super responsive and awesome.

Is cloud storage anywhere near as opinion-inducing as note taking workflows though? :) There are like a dozen new entrants each month, and so it’s probably meaningful for folks to get super clear on their core requirements. Otherwise, you’d spend all your time evaluating tools, as opposed to actually writing.

It’s a little bit clunky, but you can use GitHub.dev/<repo> on your phone. I do a lot of browsing/quick edits that way, and it works well enough. That said, I also use Working Copy for iOS to sync my notes repo, and will use that sometimes as well.

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.

Congrats on the release! I _really_ love the simple approach this tool takes. Though personally, I view note taking as “commodity” enough, that I prefer to own my data, and use my existing editor setup. If folks are looking for a productive, yet low-ceremony note taking workflow, GitHub.dev might be worth a look, since it provides the benefits of using Markdown, a GitHub repo, and VS Code, all from the browser: http://aka.ms/githubdev-fun, https://twitter.com/lostintangent/status/1429483662257446916.

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.

Speaking of education/CS50: we (the Codespaces/Live Share team) have actually been very excited/privileged to collaborate with the amazing CS50 team, as they've built their student experience on top of VS Code/Codespaces (http://code.cs50.io). Lowering the barrier of entry for learners, and supporting student success, is a huge goal of ours, and so I'm looking forward to getting our tools in the hands of more developers, and iterating based on feedback.

I'm really sorry to hear you had this experience :( I'm not sure who you spoke with, but this perspective definitely isn't representative of the team and/or how I'd ever want to see us talk with developers.

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.