swagonomixxx

I kind of get where you're coming from but at what point do we admit that such use cases are the fringe and not the main?

Agreed. Over 10 years of development using Git and I perhaps ran into an issue like 10 times, which is once a year on average.

I can't think of any other tool that hasn't given me headaches at least once a day.

Git is actually remarkable tech and its unfortunate that the prevailing hivemind opinion is that its bad.

Another thinly veiled AI product. Yawn.

I have personally witnessed "legacy" rails apps (were ~4 years old, Rails 5 was around but we were on Rails 3 IIRC) and they are not really unlike normal legacy apps but they definitely let a lot of crap seep in due to loads of contributors and almost zero ownership on the codebase.

I wouldn't say this an exclusively rails problem though. Testing was a complete nightmare, and there was so much random middlewares that were "mission critical" but no one knew what they did. And as you said, scaling was horrible. We had like a hundred servers, each running 20 unicorn instances, to serve our API at the scale we had (~5 million users or so, I forget the DAU)

I think this is one point that I don't see being made often enough. ChatGPT is exceptional at retrieval of information, but if it starts passing tests like the MCAT and LSAT and so on, I feel this is more that our testing is just crap, rather than ChatGPT being "smarter" than humans.

I see SICP listed on every list but I really feel its becoming Knuth-esque. I mean, I didn't learn through that specific book, but after going through it a couple of years ago I found that its kinda alright, but I don't really get this legendary status it has. I've also seen this opinion shared with many seasoned vets throughout my career, just feels overrated.

As someone who works in crypto this is bloody hilarious.

But std::vector has been around since C++98 (and in the STL even before then). What's changed?

That's an interesting take that I didn't think of. I think the burden on having a cloud-based development environment on ops teams will be non-zero though - some set of individuals (or a dedicated team) will have to maintain these very beefy hosts of your code that run the tests for you.

That said, I'm not against the idea in principle if access to the internet is guaranteed and constant. In some places that I'm in, internet access is shoddy or just too slow for this kind of thing, and my preference there would be to work easily on a local machine without access to the internet.

Partial suite is certainly an option. You can build tools that only test code that has changed and whose changes can have cascading effects on other code (i.e dependent code). Do you know if such tools exist, or would I (as in the software engineer working on the codebase) have to build them?

Wow, that's really impressive! Do you plan on adding support for Golang?

Using Python decorators is a very strange choice for constructing computational graphs. Then again, I don't really use Python for this kind of thing, I roll my own solutions (of just functions being composed together).

One big issue I have with the proposed approach is that it's very difficult for me to see at a glance the actual compute graph. I suppose you can build some tools to visualize it from the DSL in the decorator call, but I'd much rather be able to see this directly in code, with no weird magic, so that I can very easily interpret and update it if need be.

> But all technology evolves, and git is already showing its weaknesses. Fork-and-pull isn't the final form of development workflows.

I kind of get what this is saying, but technology evolution doesn't have to mean completely replacing said technology with something else.

I think that's one weird thing about the software field, whereby we keep moving to these shiny new things that we think are better than the tools of yesteryear, yet in the end there is only a marginal gain in productivity.

Fork and pull is an incredibly productive and powerful workflow. CI is incredibly, incredibly useful. If these things were not the case, then neither of these would be even discussed by this article. There is a reason for their success - and it's not because GitHub is the most ubiquitous code hosting service out there. Git is _actually_ pretty great. CI is _actually_ very useful and has secured codebases for decades at this point.

So if one were to proclaim the "End of CI" I really need to see a viable alternative that addresses the same problems as CI and significantly improves upon it. An incremental improvement is not enough to shift and rewrite everything - there needs to be a significant jump in ability, productivity, security, or something else in order for me (and I imagine many others) to consider it.

Running tests locally is pretty much a no-no for many codebases because they are so large and tests take a long time if they don't run on a beefy test server or in parallel.

Common examples of this are multi-million line C++ codebases (e.g proprietary game engines) and monorepos in any language.

Running tests on my computer uses up valuable CPU cycles that I can use to work on something else while the CI servers are running my tests.

However I can see this working for small to medium sized codebases that really don't need CI for testing.

Just had this thought: are there any decentralized code hosting services?

To me, I don't really see a difference between GitHub and sr.ht. Companies can start out with these "friendly" attitudes towards FOSS, but when they reel in many paying customers, they can pretty easily, and without consequence, change their policies to be more aggressive (geared towards profit) and greedy. It just seems inevitable to me.

However, decentralized hosting and governance might make it so that there can't be a hostile takeover and incorrect (relative to license) usage of FOSS code. I'm thinking something akin to IPFS but more specialized towards e.g git repository hosting.

Not sure how such hosting would be feasible in terms of breaking even between hosting costs, but a decentralized service hosting distributed VCS databases seems more along the lines of the philosophy of DVCS's in general. DVCS's in general do not have timeliness requirements (i.e your "git push" most of the time doesn't have to propagate worldwide immediately) and the other goodies that come with being on GitHub (e.g CI/CD) seem orthogonal to the actual code hosting itself, and I don't see why that can't be built separately without being part of the service.