> If you're running Ubuntu anywhere there's a bit of bureaucracy, like a government or large business

> businesses that can’t afford $500/year/server

Pick one

As a "rails folk", we aren't all like that :)

anti-virus software is the most dangerous malware that exists, it extracts money from you while slowing down your computer and generally making your life hell for no next to no benefit whatsoever

the amount of productivity lost to useless anti-virus software is incalculable

Can tell it's AI generated because the "plot" makes absolutely zero sense, lol.

Buddy, have you ever heard of this thing called "cryptocurrency"?

Mercurial should have won, it's superior in every way. For pesonal projects I use Fossil, which is fantastic.

I organized the migration from CVS -> Mercurial at my last job, and finally after several years when it became clear Git was where industry was headed we switched from Mercurial -> Git. After resisting it for a long time and then being forced to use it for a collaborative project with another firm, I have to say git is way better at being a DVCS than Mercurial.

I think, as other have mentioned, that once you truly "grok" git you begin to understand the elegance and simplicity of the system and how its layered. Ultimately git's use of branch pointers was a way better solution than encoding branch data in the commit itself. To it's credit Mercurial did attempt to rectify this later with bookmarks, but ultimately DVCSs are about branch management, and git has always excelled at it.

Mercurial's branch management makes more sense. If you want to know which branch a commit originated from in git, good luck.

Many things in git, are frankly anti-patterns in any other sane versioning system - comitting partial changesets because of the index? gross. Rewriting history and force pushing? absolutely insane.

The fact that I don't have to "grok" mercurial like you need to git is actually a plus. Mercurial can do everything that git does (and more: check out changeset evolution in mercurial, it blows anything you can do with git rebase out of the water) and it doesn't require Ph.D. level knowledge in directed acyclic graphs to do it either.

> Mercurial's branch management makes more sense. If you want to know which branch a commit originated from in git, good luck.

`git merge --no-ff former-branch` by default includes "former-branch" in the auto-generated merge commit name. When it matters what branch a commit "originated" on, it's very easy to use `--no-ff` (which doesn't rewrite history and won't need any sort of force push!) and most PR tools used to default to that before "rebase" and "squash merge" became some people's favorites because of some weird (in some cases OCD) wish to see SVN-like straight lines only in their commit history.

It isn't a "weird ... wish", a linear history is the correct default. Merges have always been, and should continue to be, a tool of last resort. In general it is good to minimize complexity in life.

Merges are the default state of life in any source control system with more than one person or machine involved. They are a regular, required need. Sweeping them under the rug, pretending that they don't happen, acting like they are rare is exactly the sorts of things that added complexity to systems such as CVS, SVN, TFS, Perforce and much more. It is exactly what adds complexity to so many of these rebase-only and squash-only workflows people like to constantly post about using in git.

Linear history is a punchline that ignores the reality of source control. The only truly "linear" history I'm aware of in source control is systems built on patch theory/operational transforms/CRDTs and that form of linear is subject to reordering and still needs explicit merge commits with (implicit) multi-commit dependencies even if there are few stated needs to visualize that as a DAG.

I agree with you, in general it is good to minimize complexity in life, which I why I eliminate rebase workflows and squash merges from mine. I prefer to see the evidence of where merges happened (and they should happen early and often), and graph data structures are very familiar to me as a software developer, including traversing them. (And git offers useful traversal tools such as --first-parent for when you want to view the DAG more like a linear history and ignore some of the noise. There's no reason to artificially simplify the DAG when DAG traversal is easy and accurate.)

good

Friend of mine started driving for Door Dash recently and when he told me they can see up front what the tip is going to be I was just flabbergasted. That's not how it's supposed to work, at all.

I had never heard that before, and now that I have I won't ever use them again.

I double checked with him just to make sure, and he confirmed with me that he can see the tip.

As somone that use to write a lot of functional-style code (in ruby), and generally prefers functional style, and have created many many many "pipelines" like that in ruby code - I've actually started to "regress" to "status-quo" (as the article puts it) mostly because I work with developers that don't understand functional style and it just becomes point of contention in review that I just don't care about getting into anymore. I can see this same kind of thing happening with this operator in JS-land (I may be wrong, haven't written any significant javascript in years, but people tend to be stubborn).

I just write things as stupidly as possible now, and just do the second one even though there are nicer "ruby-ways" to do them - maybe this is "bad" but I find it easy to read and grok...and it doesn't cause arguments during review <.<