However, we’re still implementing IPv6, so how long until we could actually use this?

We can already use custom verbs as we please: we only need to have clients and servers agree on a contract.

What we don't have is the benefit of high-level "batteries included" web frameworks doing the work for us.

That’s only true in crappy languages that have no concept of async workflows, monads, effects systems, etc.

You don't even need to sit on your ass and wait for these data types to be added to standard libraries. There are countless libraries that support those, and even if that is somehow not an option it's trivial to roll your own.

I don't think they did an exceptional job keeping teams separated. In fact, I think monorepos only end up artificially tying teams down with an arbitrary and completely unnecessary constraint.

Also, not all work is services.

named arguments

Is this supposed to be a critical feature?

Also, TIL that the IETF deprecated the X- prefix more than 10 years ago. Seems like that one didn’t pan out.

Can you elaborate on that? The X- prefix is supposedly only a recommendation, and intended to be used in non-standard, custom, ah-hoc request headers to avoid naming conflicts.

Taken from https://datatracker.ietf.org/doc/html/rfc6648

In short, although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space.

I still work on software that extendively uses X- headers.

Ah, the Microsoft tradition of always having the wrong priorities.

I wouldn't be too hard on Microsoft. The requirement to curate public package repositories only emerged somewhat recently, as demonstrated by the likes of npm, and putting in place a process to audit and pull out offending packages might not be straight-forward.

I think the main take on this is to learn the lesson that it is not safe to install random software you come across online. Is this lesson new, though?

that managers want to stay in control of everything, and they decide whether they do it or not.

That's fine, it's a call from the manager.

That doesn't make it Agile's fault though. In fact, one of the key principles of Agile is providing developers with the support they need. Blaming Agile for the manager single-handledly pushing for something in spite of any feedback does not have any basis.

I’m absolutely biased as a data engineer who loves SQL, but there are some good reasons why SQL has been the de facto standard for interacting with databases since the 80s.

I find it funny how the people who actually have to wrangle data swear by SQL as awesome, but there are always random hacks coming out of the woodwork, who don't even look at SQL at all, with sweeping statements claiming SQL sucks because reasons.

It's like the most opinionated people against SQL are the ones who don't use SQL.

excellent tui for selecting chunks like incommit -i. Arrow keys quickly fold and unfold files/chunks/individual lines

git add -p might not have a fancy TUI interface but it supports picking files/chunks without an issue. I'm not sure how this could be described as a UI problem.

commits come in 3 categories:

I'm not sure how that would be useful in Git's perspective. In Git, public commits are commits pushed to a shared remote repository, and draft/secret commits are just local commits that you don't push. I'm not sure what value those specialized types of commits add.

Git's approach sounds simpler, consistent, and coherent, and thus simple to learn. I'm not sure what was gained by pushing that level of complexity onto Mercurial.

when you rebase, your previous commits are marked obsolete and hidden from most UI.

I'm also not sure if that makes sense. If you rebased a branch, you don't expect the original branch to stay there. As the name implies, what you want to do is to replay a sequence of commits onto another branch. In the rare cases you wish to keep the original branch in place, you just create a new branch alongside the old branch and rebase the new one instead.

Keeping the old branch in place after rebasing it feels inconsistent and illogical.

I don't think the article makes a case to shoehorn git in each and every usecase that goes beyond tracking changes to project files.

For example, both git-issue and git-bug are an awkward interface to track issues whose main selling point is being git-based, which is not much to start with. They are focused on the persistence layer used to store ticket info when that's both a solved problem and irrelevant to the problem domain. To top that off, Git's main selling points are its distributed nature and ease to branch off/merge changes, which are not relevant for this problem domain, and the main value of issue tracking is to track the overall progress of a project and audit changes, and these tools offer a worse user experience than any of the tools they supposedly try to replace.

Given there are plenty of outstanding free tools that do a far better job at this in their free tier than any git-based alternative, I fail to see the real-world value of these projects.

If anyone is actually interested in a solution that bundles up revision control, issue tracking, and project management, they are far better off just onboarding onto tools such as Fossil.

From the video:

Of course there is a market for real bulldozers, but it turns out there are so many people in this world that there is also a market for miniature bulldozers. A market enough to support a company that makes nothing but miniature bulldozers. Go sit under a three and think about that one for a while. It's wild. There is a lot of people. I can't believe this thing actually exists.

...and proceeds to buy one, and record themselves playing with it night and day.

Is it not generating HTML on the server to be served to the client?

No, it generates the code that creates the DOM, sets the application state based on the user's setting, and updates the webapp to resume working in a consistent state.

It basically sends a frozen instance of a full blown JavaScript application.

What you’re describing is, in my opinion, an overly complicated form of dynamically rendering HTML on the backend.

That's because you're oblivious to the problem domain,and thus you're falling back to the unrelated but similar sounding things you're familiar with to fill in the void of your understanding of the actual problem.

Anyway, that’s my opinion on the matter

My point is that your opinion is a misinformed one,and really doesn't hold up to scrutiny.