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.

Not sure what you mean by this. You can dynamically add to a wait group using the Add() method.

You can easily cancel worker goroutines in Go using contexts and their associated cancel functions (listen on ctx.Done() in a select statement).

Will 2nd not being a fan of Gorm. In general not a fan of ORMs - implicit behaviours and magic query generation in a language like Go is completely antithetical to the explicit and verbose nature of the language.

Building a "Rails-like" framework in Go is honestly totally antithetical to the "Go way" of doing things.

Rails has a ton of magic, implicit behaviours, monkey patching, ERB, and so on.

Go is a touch below Java verbose, explicit, no magic, every function call can be very easily traced without having to do meta programming and code generation in your head to understand what's going on.

In my 8 years of writing Go, I would liken it the most to C, where you had to spell everything out, except without the manual memory management and the macro preprocessor.

Doing magic with Go via reflection or other implicit behaviours is generally annoying to deal with. One example is some libraries using struct tags, most of the time they work as expected, but sometimes you get some weird failure and these kinds of implicit behaviours are the culprit.

Overall, I don't rate these "all in one" frameworks highly in Go. The standard library is excellent for most applications, you only need to add some code to remove some boilerplate. For most apps that I have worked on in Go that involved web components, we maybe had to import e.g a websockets library or a more elegant routing library, but that's pretty much it.

> This is a gross misunderstanding of web3.

Literally everyday there's an article that is posted that completely misunderstands cryptocurrencies and the related ecosystem. The most common critique I see on HN of this is that NFTs are garbage and rug pulls suck.

Thats like saying the modern web sucks because a couple of shitty websites are live and you got your CC stolen by phishing e-mails. It just makes no sense as an argument.

Crypto has a long, long, very long way to go but if folks truly do not believe that transferring something that we believe to have some value (i.e bitcoin, or USD, or whatever) without the need for a middleman, while also keeping your funds truly safe from external control (i.e banks, governments, and the like) then cryptocurrency is simply not for you, full stop thank you for considering it.

In the first world, the full value of such decentralization and trustlessness will never be understood until they get burned like Sri Lanka, Lebanon, Cyprus, and other countries with massive hyperinflation and complete loss of wealth (temporary or not). The daily fluctuations of BTC are literally nothing next to the hyperinflation of the Turkish Lira, the Lebanese pound, the Zimbabwean dollar, and so on.

As a side note, its getting kinda tiring to see these boring, lame takes on crypto which seem as half assed as they are uninsightful posted on HN. Lets get some moderation done on this front IMO.

As someone who works in crypto this is God freaking hilarious! Kudos.

Because any negative news on crypto is automatically HN-worthy.

/dev/null is quite webscale as well, writing to it is as fast as heck!

> A Git-compatible DVCS that is both simple and powerful

We all know the dig here - Git is not simple.

Like many tools, Git has evolved significantly over the years. Git today was not like Git 10 years ago.

Also, like many replacements to existing tools and software, they always start out simple and beautiful. Then they grow in complexity to serve the domain. The reason Git is complicated - not "simple" - is mostly because version control _is_ complex.

I also don't agree that Git is hard to use. I feel it is an odd goal to try to make everything - even tools that experts use - simple to use, when they are fundamentally not simple. I feel like Git is sufficiently complex - no more than it needs to be and certainly not less.

Disagree with this. Most middle managers wouldn't understand the difference. One canonical version is enough, any more and there's just confusion, not enlightenment.

Agreed, a single point of authority is useful.

Although in this scenario, isn't code of conduct something much more "local" that the ringleader doesn't really need to step in every time to enforce?

CoC is just something I expect everybody to enforce when needed. Having a dedicated team to do that seems odd to me. I guess you still need someone to issue bans and to wield the ban hammer, but it _should_ happen infrequently that simply informing the violator of their violation should be enough (unless they're a troll and will continue violating, in which case they can be kicked).

Article is paywalled.

I'm not sure if this is a good thing or not. I for one like the fact that I can easily manage my subscriptions from inside the settings app. I cancel a subscription, and I'm guaranteed not to get double charged again. It's as easy as pie.

With every Tom Dick and Harry app linking to their own subscription and payment system, this already becomes incredibly more complex for the consumer (in this case, me).

I have already been avoiding using apps that require me to sign up manually (i.e without the "Log in with Apple" option) because it's simply inconvenient and I know one day or another each of these websites will be compromised, my e-mail leaked, as well as other payment processing info.

This just fragments the ecosystem even more and I'm quite happy to avoid such applications and stick to those that use Apple for payment processing and subscription management (if these are only the Apple related apps, e.g music, TV, etc., so be it).

What's the advantage of using BerylDB over Redis? Is it speed, or something else in the feature set (current or future)?

I don't think I like any of these proposals. None of them add something that makes me think, "hey, I really need this". Heck, I don't think any of them would even be nice to have.

Go error handling in practice actually works very well. I've been writing Go for a long time and I've never had an issue with it. It's not as fancy as Rust but it works and works well, so if it ain't broke, please don't try fixing it.

Can you explain why you think it's wrong?