HNHacker News
TopNewBestAskShowJobs

SBArbeit

242 karma · joined February 2, 2013

Programmer, writer, author, mystic, music lover, baseball fan.

Statically-typed languages > dynamically-typed languages, for all tasks > ten lines of code.

submissionscomments
SBArbeit··on Ask HN: GitHub employees what's going on? Why?
Ex-Microsoft, ex-GitHub, laid off nine months ago, not going to violate any agreements, but I will give some context. A lot of this applies to any large engineering org, really. Hilarious that this entire thread is people speculating on things they have no idea about.

If it sounds like I'm defending GitHub a bit, yeah, I am. I can't think of a comparable situation that any other web site has been through. This isn't "oops, we didn't plan for the Black Friday sale", this is a once-in-a-generation event focused on one, important web property that no one would have handled perfectly. (Even us all-knowing commenters here on HN.)

You know that old trope in every submarine movie, where the captain tells the driver to dive lower than they've ever gone, and someone says "I don't know if the boat can take it!" and then they switch the camera to some engineering room where the boat is groaning under the pressure and a bolt comes loose and water starts spraying everywhere but someone runs up with a giant wrench and tightens it and looks around at everyone else in the room like, "whoa, that was close..."?

Or Scotty and Star Trek, "It canna take much more, Captain!"

That's what GitHub has been going through. It's had problems, but it's still here, and usually working well.

- Let me start with: GitHub is ~3,000 talented and really nice people trying to do the right thing, with a great culture. That's the most important thing I want to communicate. While I'm sure no one at GitHub is happy about their uptime, believe me when I tell you that GitHub Engineering is exceptional. They have great leadership, depth at all levels (Distinguished / Principal / Staff / Senior / earlier-in-career) and if you ever get a chance to hire someone from GitHub, you should. I hope all of you get to work with engineers as good as GitHub's.

- GitHub has been improving all aspects of its infrastructure steadily for many years now. The GitHub Engineering blog https://github.blog/engineering/ has been documenting this the entire time. Go point your favorite LLM at it and ask for a summary of all of the major system improvements since 2020. If that work hadn't already been done, GitHub would be a smoking pile of servers at this point. There's a lot I could list, I'm not sure which are already public, but improvements on the order of using thousands fewer CPU's to serve even more traffic than before have been made, and still are, I'm sure.

- GitHub was already serving billions of requests/day before agentic coding hit. Their challenge wasn't scaling a fresh new system with a few users an order of magnitude; it was taking one of the busiest and most important sites on the Internet, and getting hit with 14x traffic in a year, and having to plan for 100x. If you think your systems and infrastructure would have survived that, if you think you would have been able to politically navigate and succeed in getting projects green-lit at a large company to prepare for 100x scaling before it hit, to get those resources for "we might have scaling problems in a year or two" instead of getting them to ramp up on AI coding and other features that were crucial to growth right now, you don't understand large organizational dynamics. That's not a complaint about GitHub or Microsoft; it's an observation about capitalism and how any mature management group prioritizes things in software. I'd expect everyone in the San Francisco/Silicon Valley Reality Distortion Field to understand that.

- We talk in terms of "14x commits" to Git but that's only part of the story. GitHub Actions, webhooks, github.com itself, and other parts of GitHub, have all been under pressure. It's the totality of it, the seams that have been exposed at scale that couldn't have been exposed without that scale, that have caused the instability. That's why architecture gets overhauled.

- Yeah, GitHub has had less consistent uptime since the 2018 Microsoft acquisition. The GitHub that existed before that had much less functionality, an order of magnitude fewer users, and had received very little improvement in the few years before. Microsoft invested and enabled GitHub to grow into something much bigger than it ever could have without them.

- Be grateful that Microsoft - with a 50-year history of shipping developer tools, and more experience operating enterprise software than any other company on the planet - acquired GitHub instead of Google, which was the other major player in contention. Spend a minute or two thinking about the product journey GitHub would have taken under Google, and then think about how many non-search, non-advertising products have succeeded there. Which amazing developer tools from Google do you use regularly? Yeah, I thought so. On behalf of Microsoft, you're welcome.

- Did you notice that GitHub swapped out one of its data centers last year for one 3x larger? No? Maybe that's because they executed it flawlessly, with no downtime. If you've ever done that on a massive web site with as much scrutiny as GitHub receives, you get a gold star.

- Did you notice that over 50% of GitHub read traffic is now being served from Azure instead of GitHub's own data centers, and growing, and that all GitHub Monolith traffic is scheduled to be served from Azure instead of GitHub's data centers by the end of CY26? This massive migration is taking place while traffic is going insane. From https://github.blog/news-insights/company-news/github-availa...: "GitHub can now serve a larger share of customer requests from independent Azure capacity, reducing reliance on any single datacenter while preserving performance. Monolith read traffic served from Azure Central US peaked at 52.75% on July 28—the first time we consistently remained above the halfway line. Git traffic in Azure reached 47%, up from 43% in June, and 29% of all repositories now have a second replica in Central US, making failover less disruptive when a region degrades."

- OpenAI and Anthropic obviously have significant scaling challenges as well, but there's a huge separation between the GPU-based inference part, and the CPU-based front-end systems. Their CPU-based systems are significantly simpler and newer than GitHub's, so I'm not surprised they have fewer outages, but it's still non-zero.

- Ruby on Rails is not the problem (and, for the record, I don't even like Ruby or Rails). Most of the performance-critical systems that were built on Ruby have been migrated to Go or some other language that takes full advantage of multithreading. The web endpoints still served by Ruby are fine.

- Spare me the "Azure sucks" comments. Please. Microsoft Azure is the second-largest computing system on the planet - only AWS is larger in terms of hardware but not in terms of the number of products they ship - and Microsoft's first-party systems that run on it, all at the same time, are among the largest, busiest, most important systems on the planet. Entra ID, Azure SQL, Service Bus, Event Hubs, Office 365, Cosmos DB, OneDrive, etc. all in the tens-to-hundreds-of-billions requests/day. I'm not even counting the massive customer-owned systems that run on it, including almost the entire Fortune 500. Nothing is perfect, everyone has downtime, we all always want more and better features, I want improvements from Azure, too, but, please, grow up. I have opinions, too, I've been programming since the Apple ][+, there are popular technologies that I don't like, but I know that's subjective. "Your favorite technology sucks, mine is better" is not an objective statement about anything.

Anyway, if you haven't shipped at GitHub's scale, in this dynamic of a world of feature churn, and one-of, if not the largest, traffic spikes in the history of the web, have fun saying whatever you're going to say. I've never worked at Google or Amazon, I have opinions about their product design and culture, but there's nothing I can say about their infrastructure and systems because I have no idea about them, and what we all do in this crazy world of programming is harder than it looks.

For some, this won't be the answer to "what's going on?" because I'm not pointing fingers at any one thing. To me, the real answer is: an unprecedented scaling event on what was already one of the busiest sites on the web exposed seams in their systems, including the need to move from their own data centers to a much more scalable cloud provider - that are being addressed as quickly as possible.

I'm not telling you not to look for alternatives, I'm not telling you what to do about it, I'm not saying that all of their problems will magically be solved soon, I have no idea. I'm even launching a new version control system myself very soon to compete with them. But I do know that the thought "GitHub doesn't know what they're doing" is wrong and unhelpful.

SBArbeit··on Windows 11's built-in Weather app wastes more than 1 GB of RAM
I can name lots of things I can't stand about MacOS and iOS and Apple hardware, but that wasn't the point of the comment. Some of the things I can't stand about Apple are things that people used to Apple's stuff don't mind. Cool for you. But I'm still not moving to The Villages, ever.
SBArbeit··on Windows 11's built-in Weather app wastes more than 1 GB of RAM
Easy workaround for this:

1. Install uBlock Origin in Edge.

2. Start Edge, browse to MSN Weather.

3. Click the "Add an Application" button in the address bar to get a Start Menu icon for the page.

4. Delete the in-box Weather app icon.

Now you get the same Weather app in about 130MB of RAM, with no ads. It's not as nice as a native app, of course, but it's 1000% better than the useless ads and MSN feed that you can't block from the built-in Weather icon.

(Also, go into Widget settings and turn off "Discover / Microsoft Start feed". Same crap, different surface. Get rid of it.)

SBArbeit··on Windows 11's built-in Weather app wastes more than 1 GB of RAM
Super interesting; it's been exactly the opposite in my experience. MacOS/iOS users put up with whatever Apple is telling them they should love - Liquid Glass, right? App Store restrictions, right? Lousy AI, right? - whether it's true or not. Linux users are willing to put up with any amount of work - i.e. bullshit - to make their installations work just to get a UX that's almost as good as Windows from 20 years ago.

As for Windows, I like living in cities. If you live in a city long enough - at least through a couple of major macroeconomic cycles - you'll see it improve in some ways and some neighborhoods, get worse in some ways and some neighborhoods, then improve again, etc. Cycles. Windows found itself in a downturn the last few years, primarily due to the org structure that took Windows shell away from people who could really look after it, and, yes some of those execs have earned my permanent scorn, like a bad local politician would. Now there's a focused team making that neighborhood better. I'm here for the whole ride.

I'll use Linux on computers I don't have to log into very much, so I don't have that UX problem (case-sensitive command lines? Seriously? The 1970's called...). I'll never move to MacOS City; it's like wanting to live in The Villages. Manicured lawns with no soul.

So I live in Windows Town, it's not perfect, no city is, but it's always changing, always moving, going through ups and downs, and now it has a new "city council" that's making changes for the better. And I'm expert enough to make it great for me, and avoid the "neighborhoods" that suck.

This article highlights a problem that Windows has right now, and one which I agree with, which is shipping web apps instead of native. For now, I have a workaround for it:

1. Install uBlock Origin in Edge. 2. Start Edge, browse to MSN Weather. 3. Click the "Add an Application" button in the address bar so I have a Start Menu icon for the page. 4. Delete the in-box Weather app icon.

Now I have the same weather site, no ads, running in about 130MB of RAM.

Enjoy your choice of operating system. Live where you want. Sometimes your city has problems. Move if you want, but don't think you've permanently solved your UX issues if you do, you've just swapped them for different ones.

SBArbeit··on The AWS SDK for .NET: A Code Quality Wake-Up Call
This SDK is widely trusted, but it carries significant technical debt:

    Performance risks
    Memory leaks
    Design flaws
    Maintainability issues
Popularity does not equal quality.
SBArbeit··on Electron-based apps cause system-wide lag on macOS 26 Tahoe
Avalonia. https://avaloniaui.net/platforms
SBArbeit··on The LLM Lobotomy?
I know that OpenAI has made computing deals with other companies, and as time goes on, the percentage of inference that they run their models on will shift, but I doubt that much, if any, of that has moved from Microsoft Azure data centers yet, so that's not a reason for difference in model performance.

With that said, Microsoft has a different level of responsibility, both to its customers and to its stakeholders, to provide safety than OpenAI or any other frontier provider. That's not a criticism of OpenAI or Anthropic or anyone else, who I believe are all trying their best to provide safe usage. (Well, other than xAI and Grok, for which the lack of safety is a feature, not a bug.)

The risk to Microsoft of getting this wrong is simply higher than it is for other companies, and what's why they have a strong focus on Responsible AI (RAI) [1]. I don't know the details, but I have to assume there's a layer of RAI processing on models through Azure OpenAI that's not there for just using OpenAI models directly through the OpenAI API. That layer is valuable for the companies who choose to run their inference through Azure, who also want to maximize safety.

I wonder if that's where some of the observed changes are coming from. I hope the commenter posts their proof for further inspection. It would help everyone.

[1]: https://www.microsoft.com/en-us/ai/responsible-ai

SBArbeit··on Ghost sharks grow forehead teeth to help them have sex
Everything about the title of this article is frightening.
SBArbeit··on Visual Basic 6, in the browser, written in C# with Avalonia
You can see it deployed as a web site at https://bandysc.github.io/AvaloniaVisualBasic6/.
SBArbeit··on Show HN: Test your website on 180+ device viewports (with multi-device mode)
This is brilliant. Thanks for building it.
SBArbeit··on Grace Version Control System
The fact that most of your Git commands are local-only is an artifact of how Git works, but I expect that ~100% of the time, you have an internet connection, so the fact that Grace needs to be connected to the cloud just isn't a thing I worry about.

I'm not writing a new VCS based on the 0.00000001% "but I'm on an airplane without WiFi" case.

There's ~0% reason in 2024 to build software for offline use cases, and even less reason in 2026 and 2028. I'm happy to cede that to Git if you really need it.

As an industry, we fetishize offline for version control only because Git sort-of does that. Again, it doesn't really... you still have to push to do real work with your team, but we need to stop pretending that's a hard requirement. It's totally not, it's just a "feature" of Git that gets in our way today more than it helps us.

> Also I once had a case of working on an air-gapped network.

Coming from Microsoft, and being familiar with the air-gapped Azure instances for government, I designed Grace to be able to run on those Azure clouds. In other words, all of the PaaS services that Grace would use on Azure are present in those clouds.

Even the air-gapped world isn't "offline", it's totally networked, just on a network that's not connected to the Internet.

I haven't specifically looked at similar AWS instances, but I have to believe it's possible there, too.

SBArbeit··on Grace Version Control System
> Any plans to assimilate the build system as well?

No plans, not at all.

One of the design questions I've had in mind the entire time I've worked on Grace is: "What belongs to Git, and what belongs to GitHub?" (or GitLab or Azure DevOps or etc.).

I'm interested in completely replacing Git, but being very selective about pulling anything into the version control level that really belongs at the hoster level.

The only big thing I blurred the lines for is the including of Owner and Organization entities, to make multitenancy easier to support. My implementations of Owner and Organization are super-thin, just really hooks so the hosters can connect them to their existing identity systems.

The big hosters already have massive CI/CD and build platforms. The Grace Server API - and Grace Server is just a modern, 2024-style ASP.NET Core Web API, with no special protocols - will give us the ability to create, for instance, GitHub Actions that take the place of the Git fetch action that we all use today in our pipelines.

I'm happy to let the product and engineering teams at the big hosters figure out how to integrate with Grace.

SBArbeit··on Grace Version Control System
Eh, I'm not really an Elvis fan...

One of the problems that GitHub and GitLab are going to face in the coming years, as Git gets supplanted whatever wins, is that "Git" is in the company name. Those names are going to sound they like provide yesterday's tech, in a hurry.

Not gonna make that same mistake for Grace.

SBArbeit··on Grace Version Control System
It's totally cool. It's not a product yet, it's a one-person project so far. I'm not asking anyone for any money. I expect one day that it will be a product.

It's still an alpha (see the highlighted note towards the top of the readme). There are features I intend to ship in 1.0 that aren't even started.

And even if all goes as well as possible, it won't ship 1.0 until 2026 at the earliest, which means early adopters, and mass adoption not until 2027 or 2028.

If you're going after something as big as Git, it takes time. It would be irresponsible to not think about where computing will be in a few years vs. today as I work on it.

SBArbeit··on Grace Version Control System
I'm a long-time C# dev who got into F# about five years ago. F# is so awesome, I hope that if Grace catches on, that more people will pay some attention to it.

And .NET is so fast. No-brainer.

SBArbeit··on Grace Version Control System
Thank you, I appreciate even the one data point.

I'm a Windows user (and former Windows network administrator). I only use Linux as a target for containers, and rarely use a Linux terminal, so I know I'm not the right person to understand what Linux users want and need. I was a Unix admin in the late '90's for a couple of years, it was a bad enough experience to make me not want to be back in that world ever again. It's all subjective, of course.

I am pretty decent at designing UI's, and I hope Grace will be a non-terrible GUI for you (and for me).

SBArbeit··on Grace Version Control System
> Hi - can Grace support partial commits somehow?

Not at the moment, and probably not for v1.0 unless that bubbles up as a huge blocker.

You could accomplish it with something like:

- Make the changes in your branch - Make a new branch off of `main` and cherry-pick the changes you want from your branch into that new one - Commit and promote from the new branch; at this point you can delete the new branch - Auto-rebase will run and propose a good merge to your original branch, which would include the partial changes you now have both in `main` and in your branch.

I still have to write cherry-pick - not sure that I'll call it that - and promotion conflict processing using LLM's. But something like the above steps would do what you're asking without too much effort.

There's no way to tackle the entire surface area of 20 years of Git in one release. I'm sure we'll see workarounds like that in v1.0 and learn from them to improve 2.0 and 3.0.

SBArbeit··on Grace Version Control System
> My bet is it will be forgotten in a year.

How much? ;-)

SBArbeit··on Grace Version Control System
> This doesn't really make any sense. Most people are not "large Git hosters"

I do work for GitHub, so I do know what it takes.

Most people don't run their own Git servers, they use GitHub / GitLab / Azure DevOps / etc. and I intend to create something that's easy for those hosters to adopt.

Grace is also designed to be easily deployable to your local or virtual server environment using Kubernetes - and if you're large enough to want your own version control server, you're already running Kubernetes somewhere - so, party on if you want to do that, but I expect the number of organizations running their own version control servers to be low and shrinking over time.

And Git isn't going anywhere. If that's what you to run on your own server and client, I won't stop you.

SBArbeit··on Grace Version Control System
Thank you. <3 I do ignore them.

There's no way to build something with an intention as big as "replace Git" that won't invite knee-jerk reactions.

I know I'm building the thing that aligns with my creative and technical vision. That's all I can do. It will succeed or it won't, and the reactions from people who are already super-comfortable with the existing technology matter less than the reactions from people who only understand the basics of Git and are afraid of it. I'm building it for them (which includes me).

SBArbeit··on Grace Version Control System
Not with something like GitHub Secret Scanning monitoring things, or we could imagine a local ML model automatically checking every save before it gets uploaded.

This is an easily-solved problem. And in case one slips through, versions are easy to delete in Grace.

SBArbeit··on Grace Version Control System
Don't get hung up on what GPT-4 can do. That's irrelevant. Even Sam Altman calls GPT-4 "mildly embarrassing".

"Don't skate to where the puck is, skate to where the puck is going." In 2028, for instance, will GPT-7 (or whatever) be able to handle solving a merge conflict? I expect it will.

SBArbeit··on Grace Version Control System
> inadvertently committing secrets

Devs already do this all the time. That's why GitHub has Secret Scanning. The need for that kind of service doesn't change if the VCS changes.

> temporary large files

Saves in Grace are ephemeral, so those files will be deleted when the save references are deleted. There is a repo-level setting for how long that is, current default is seven days, but we'll see what makes sense.

> The storage and networking demands for this would be enormous.

Fortunately, Azure Blob Storage and AWS S3 and Google Cloud Storage are effectively infinite compared to any requirements from a version control system.

I've only written the Azure Blob Storage implementation so far, but the idea is that Grace offloads all file upload/download traffic to those object storage services, using Azure SAS tokens [1] or AWS Presigned URL [2], etc.

[1] https://learn.microsoft.com/en-us/azure/storage/common/stora... [2] https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareO...

SBArbeit··on Grace Version Control System
"Cloud-native", to me, means "built to scale up well". I find that's the connotation that most people associate with it.

Git, or any file-server based software, is not built to scale up well in today's world. Large Git hosters have to invest entire teams to manage their file servers and their Git front-end systems to create a web-scale service on top of a file-server based piece of software. I'm just skipping to the part where you don't need that anymore because Azure / GCP / AWS PaaS services already handle that.

And, in any team dev situation, you're not getting anywhere until you `git push`, and that requires an internet connection. Assuming ~100% connectivity for devs around the world, in the late 2020's, is the right assumption to make. If offline is a hard requirement, Git isn't going anywhere.

> through non-http transports like mail

yeah, I'm not building a new VCS for that 0.0000001% case.

SBArbeit··on Grace Version Control System
> It sounds like Linux is not a priority now?

The "probably Linux" line was when I was thinking of using .NET MAUI for the GUI, and they were considering adding Linux support. My bad, I need to change that.

.NET MAUI has decided not to do that, so I'm going to build the GUI with Avalonia, which does have Windows / MacOS / Android / iOS and Linux desktop support, as well as WASM support, all from the same code base.

If I weren't using a cross-platform GUI framework like Avalonia, I really might not bother with a Linux GUI, or at least deprioritize it; I expect most Linux devs will just use the CLI. I'm totally curious how much GUI usage there will be on Linux...

SBArbeit··on Grace Version Control System
When I hear "cloud-native" I think "built to scale up well". As opposed to "built to run on file servers" which means "doesn't scale well at all".

Is that just me?

Also, [1]. I start by saying it's centralized. I'm proud of it. It's the right direction for moving version control forward. And modern use of Git isn't really distributed anyway; it's centralized. We don't push to production from our dev boxes.

[1] https://github.com/ScottArbeit/Grace/blob/main/docs/Frequent....

SBArbeit··on Grace Version Control System
> I think you're trying to fabricate problems where there are none.

No, I'm not. The problems with Git's UX are well-documented, and have spawned many projects over the last 10+ years trying to deliver "Git, but easier" or "Git, but better", so it's not just me who sees this.

I'm happy for you that you're comfortable with Git, or so indoctrinated to the workarounds required to use Git well that you're used to them. I believe it's time for something very different, and much easier to understand.

> why do you think Git managed to become the world's de facto standard VCS

I think it was because Git has lightweight branches, and an ephemeral working directory, both of which made it nicer to use than the older, slower, centralized VCS's. I've kept both of those features in Grace.

I also think it was because of GitHub wrapping a lightweight social network around Git and popularizing it, at the same moment that shared open-source dev really started to catch on as an idea. Without GitHub, Git wouldn't have won.

I do not think it was because Git is easy to use, overall. Again, maybe 20% of devs really get it, and the rest don't and just hope nothing bad happens. It was better in some important axes, and we've all paid the bad-UX tax to get those better parts, but 2005 was a long time ago, with a very different set of network and hardware conditions, and we can do better.

SBArbeit··on Grace Version Control System
^ this
SBArbeit··on Grace Version Control System
> History will be riddled with invalid state: Code that won't even compile, code that compiles but just had something important deleted without yet being replaced, etc.

No, it won't.

Saves are ephemeral; they're for your personal use to look back at the changes you've made recently, to enable a time-limited file-level undo, and to help you get back into flow after an interruption by being able to review what you were thinking and working on. Saves will be automatically deleted after a repository-level settable length of time, I'm thinking 7 days by default, but we'll see what makes sense.

Checkpoints are also ephemeral, they'll just have a longer life before getting deleted. They're for your reference, to help you keep track of your work, or keep track of an interesting version, or whatever you want to use them for. Or don't. Up to you. I don't imagine caring, for instance, what versions you checkpointed nine months ago.

This eliminates the "squash vs. no squash" debate. The only references that get to `main` are promotions. Nothing to squash.

All of this makes version control more ambient, more something that just happens in the background, effortlessly. Once you try it, it's really nice. Obviously, I've been the first beneficiary of it.

I wouldn't want to have to explicitly "push" changes to my OneDrive files, and in the same way, I don't want to have to explicitly "push" changes on my own branch anywhere, that should just work.

SBArbeit··on Grace Version Control System
> In Git these mistakes are more easily avoided as you are deliberate about what you commit and what stays local.

And yet GitHub has built an entire security feature - Secret Scanning - because developers do not easily avoid checking in secrets.

We have to face the fact that Git not being able to delete versions easily is a bug, not a feature, and that we do indeed sometimes need to delete versions from a repo. And so we've built a set of workarounds for Git to prevent pushes from succeeding when secrets have already been committed locally. It's not ideal.

Grace will enable a combination of hoster-level Secret Scanning with a native ability to delete a version that you don't want. Imagine that you accidentally save a secret, it ends up in your personal branch as a Save reference, Secret Scanning catches it and prompts you about it: "A secret was detected. Should I delete that version for you?"

No rewriting, no "hey Copilot how do I fix my repo after I committed a secret?", just one click and it's gone.

Page 1 of 4Next →