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.
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 :)
> 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.
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)
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.
Personally, I find “learning through demystification” really effective. So putting the humor aside, I’d love to see more things written like this.