hackrmn

Every time XML comes up, I feel obligated to share my opinion (I too wrote XML a the turn of the millennium and have seen it become and still witness on occasion it being excommunicated).

XML is verbose and therefore uglier than it ought to be. I think most of the haters hate it for that alone -- there's not much else to hate because you don't have to deal with the rest, it's not really imposed on you unless you really have to deal with someone else's XML application.

What do I mean? Well, the brackets thing and the necessity to repeat name of every element twice, in correct (LIFO, last in first out) order, isn't great, admittedly.

What XML has that the dev-bro alternatives that have flooded the void XML left since, haven't gotten and thus see being reinvented, are: namespaces, attributes and interop using the former two. Sure you can write JSON and YAML (the latter deservingly being incredibly hard to parse correctly -- they tried to design a better XML but failed IMO) -- but these suck as meta-languages because there's not much "meta" there. JSON, for example, allows you create properties and has a few types (kind of more than XML, really) but it leaves semantics up to you and namespaces are up to you to re-invent, poorly. If you think I am stretching the argument, see if you can represent an HTML document (no, not Markdown) with a JSON file.

YAML is a similar story, albeit with a few cool things like aliases. I think it's a better attempt to give the world a better XML, but the jury is still out on that one.

The killer thing with XML, for better and for worse, was plethora of tools to work with it. I wrote a fair share of XSLT documents to transform data, back when there was momentum in XHTML, for example. XSLT barely supports JSON and it's not pretty. XPath cannot natively understand YAML -- unless you convert it to XML which I guess re-animates XML as some sort of Frankenstein's monster. And even if it were a [pretty] monster, dealing with intermediate representation for the kind of purpose, is a can of worms all of its own.

Ironically nobody seems to hate HTML 5, seemingly. Or React basically turned it into a greasy cogwheel nobody needs to look at. Because if you look at it, it's in my opinion an abomination even compared to XML (unpopular opinion) -- the parser is quirky and behaviour is defined by the standard per element type (i.e. some elements need a closing tag and some do not, and what happens if you forget a closing tag is element-specific; care to remember the set of rules to ensure your document renders to your liking?). It has no namespaces but it has "custom elements" which require a dash in the name as poor' man's namespaces and you can't omit one, and now we have a Web of `x-spinner` and `x-carousel` because it turns out everyone rightfully wanted default namespace but didn't get one. Anyway, it's all plumbing, right -- the idea of _writing_ HTML has largely come and gone us by. And I am digressing.

In our shop, I wasn't one of those who knew Docker in and out, got just enough into it I could containerise applications we needed to have containerised, which was of a modest scope -- no crazy networking setup that required bleeding edge or anything like that. Anyway, after only a few months into Docker, organisation announced migration to Podman across the board. Initial impressions were soured by, ironically, poor out-of-the-box installation experience _on Red Hat Enterprise Linux_ (which we run everywhere where Linux is used) -- getting `podman` to do much of anything useful in the "rootless" mode matched the typical anecdotal evidence requiring a bunch of incancations you may or may not understand fully, as RHEL itself wasn't ready for the package, apparently. That was in 2024 though, and it rapidly got better after that. These days I have all but forgotten we used to use `docker` but use `podman` instead, but then again I have had to learn plenty enough about at least the latter -- enough I am able to navigate problems better than earlier (what with UID/GID mapping, for example -- which too had to be done manually occasionally when we first transitioned).

There is however, the LLMs that pull their fair share of documentation, or rather, replacing it. Not opening that can of worms here, but heck am I glad I can query `$AI` about occasional Podman "burst pipe", instead of hitting Google and looking for [that one e-mail message from a guy who had exactly the same issue, solved it _and_ had the wherewithal to post the solution](https://xkcd.com/979/).

We never got into use of `docker compose`, not in any capacity to speak of, and these days we use Kubernetes and OKD/Openshift for things that Docker -- in my understanding -- solves with swarm and composition. It works well enough, I almost don't find it worthwhile to mention that it does :)

These were my thoughts more or less, but how many Chens does the world's largest software company need to at least maintain the now "legacy" code before they find a way not to need them any longer. Maybe they're betting on large language models having trained on the cumulative output of experts like Chen, but I think that's fit for contingency situations -- maintaining existing code and making sure it doesn't break the bottom-line -- but for all the praise of AI I have my doubts Microsoft are crazy enough to just leave it to AI to develop Windows containing hundreds of thousands of SLOC of the kind only Chen can effectively debug.

As for 25 year olds -- I am sure there will always be those around, people have been pretty consistently varied in their pursuits, but it going to be so niche they'll be like COBOL/FORTRAN developers hired by the banks today -- far and in between and paid so handsomely they can pick and choose consultancy any day of the week anywhere in the world. So I guess good for them, but again -- can Microsoft depend on that form of provision of labour they still need (and will need for a few years ahead at least)?

> Writing few characters more has never been an issue, at best it's annoying.

I don't think the implication is that writing is the issue. In my experience it's the _reading_ that is an issue. I don't mind writing verbose code -- I don't enjoy it but I'd understand the rationalisation in a team of developers that prefer that -- not as much as I mind _reading_ verbose code myself. It feels like you hit the brakes and the accelerator interchangeably. Which proves the point the law is trying to make, for my part.

It's a great idea but I've lately adopted the habit of just looking at the code and noting SLOC count. I am bewildered how people today add code like there's no tomorrow, I suppose the advocates would quote "literate programming" and onboarding and what not, but I think reality is showing the code gets the better of us and we're absolutely squeezed by the volume of code that kind of works and kind of doesn't, exhibits issues (including vulnerabilities) and at the end of the day just rots looking at the next kid taking over. And I am not loving it anymore.

20K SLOC for a site widget? There's nothing great about that. But sure -- I guess it works. Everything can be ignored because "it works", but in my experience the gears are bound to start flying sooner or later and someone needs to look under the hood -- whether it's under the hood of Townsquare or something that has long replaced it. And it better be service-able.

The fact that Raymond Chen is debugging these kind of issues, tells me Microsoft is short on staff that has his particular set of skills, handing him the hairiest issues from the annals of Windows. The new hires are probably all about .NET and JavaScript and what have you -- whatever Microsoft is about these days. I doubt it's C/C++. Chen is probably on standby and is paid handsomely as a de-facto VIP consultant. He is a legend, but he's becoming somewhat of a vintage developer.

Verbiage? What about the _nounage_?

Damn, tough reading about the 1 week deadline for finding work, then getting one after telling them you're jailed and them taking the chance on you.

I also found the article written so well (I suppose we don't encounter native English speakers in the blogosphere as much as we think we do), that it was a joy to read, if I can say so considering the subject matter.

As opposed to, I don't know, a _file system_?

But I didn't mention any law? My first sentence is written the way it is, for a reason?

If the kind of proxying isn't illegal, in my opinion it should be -- saying it's bordering on circumvention of fundamental assumptions about Internet routing and IP address leasing (and ownership), would be a sorry understatement compared to what Bright Data has managed to package into a product payment:

> you are allowing Bright Data to occasionally use your device’s free resources and _IP address to download public web data from the internet_. (emphasis mine)

I think the misleading part -- to the end-user -- is the "download public web data" part. If the data is public why can't Bright Data download it themselves? Well, because the other end doesn't want them to, apparently. The product is make you help Bright Data circumvent the undesired properties of the "public" data providers, on behalf of someone who happens to have the cash but as of yet is at the short end of the Internet stick (for all the right reasons, I'd say).

This is absolutely deplorable, but knowing the directions this is heading, I am neither surprised nor concerned, frankly. People have long voted with their wallet -- it's not the privacy-conscious Joe the Hacker that is being proxied through here, it's our parents and millions of people who just want entertainment at the end of the working day, including _parents_ of small children.

Day by day the dark Internet theory sounds more plausible, and frankly I am all there for it. The Internet will collapse into a feudal internetwork where any routing will need hop-by-hop key, so real people (and agents, frankly) can maintain a measure of trust that right now is being actively circumvented.

The point is that MCP solves a problem that doesn't _really_ exist. While consuming context, which is still at a premium. Claiming that services wouldn't be accessible to agents without MCP is at best misleading -- they certainly do [have access] through exactly what article sheds light on -- command-line tools, including but not limited to, input and output of said tool(s). Also, from a purely technical standpoint, MCP is "non-compositional" compared to command-line tools, and those who don't value composition are IMO doomed to discover so at their own peril, sooner or later.

And to be blunt, a) you're investment bias'ed and b) whether you're selling the product (MCP) to a gazillion companies doesn't exactly disprove a).

Just look at Microsoft -- they've buried more technology than most, and there's little correlation between usefulness and how deeply buried it is, and some would claim that the correlation is _inverse_. Organisational factors are what drive them, just as I suspect they are now driving OpenAI's insistence on MCP. I understand it's hard to see that from inside.

I've been using the em-dash for years, having started doing so well before the dawn of LLMs -- needless to say the fact it is used as a telltale sign of LLM writing, doesn't gladden me one bit. Also because I value concise writing through picking correct grammatical elements -- like the em-dash.

I feel like your sentiment mirrors my thoughts exactly on this.

Since this isn't the Reddit comment section (I hear people here prefer a bit more elaboration and argumentative nuance with their $BEVERAGE), I feel compelled to add some of my own personal experience.

I don't think Windows can be fixed anymore. I think the choices Microsoft have been doing for _decades_ now, with only the _mechanisms_ coming and going, have become endemic to Windows, a part of its identity. Copilot, for example, is just another gadget Microsoft simply cannot not put in. In '95 is was Clippy, but the deliveries never stop, and frankly I feel like an old man that finally decided to kick a bad habit because I truly see now all the empty talk from Microsoft I've heard countless amount of times before, wrapped in different packaging, and that Windows is like it is _by design_ and that it's bad for my health (in a different way than Linux can ever be, I feel).

Ever since Windows '95 the addition of slop has been accelerating, admittedly Microsoft _were_ much different then, but it's the _curve_ I am referring to, not that they were always _as bad_. Frankly, the "churn" is insane now, I think it's one or the other adage I can't recall where "available operating system" fills "available resources" and Microsoft are there to prove it.

The problem is also they are experimenting on their users to no end. I don't mind being part of the "user experiment" for "user experience" but how many decades do they need to arrive at the same fundamental conclusions -- that people prefer less bloat, and fewer interruptions in their face? Occam's Razor tells me it's rather that Microsoft is pretending to care but their agenda is their own alone (surprise).

Just the other day I had to spend 2 hours trying to "fix" some very-background OneDrive update because I suppose I am sucker enough to use OneDrive -- one of the least liked of Microsoft products I've had the misfortune to use -- with Windows using my laptop as a BitCoin farm, wasting cycles in some infinite loop produced by what evokes comparisons to those monkeys with typewriters. Half a dozen Powershell commands and 3-4 reboots later the `wsappx.exe` process finally was healthy enough to idle. These things happen constantly to people everywhere and there's little Microsoft can or wants to do anything about. It's a cost they're willing their users to pay.

To stop rambling, one of these days -- summer vacation perhaps -- I will remove the blasted thing finally (after decades of using both Windows and Linux) and grit my teeth through Linux, which I have tried avoiding only because I am on a Thinkpad and there's always another tweak that's needed for the whole thing to work as well as Windows does on a _good_ day. To be clear, I prefer Linux by and large, it's just that I want to avoid spending weekends configuring sleep, power states, Trackpoint, full-disk encryption, the docking station, etc.

The fact I am going to do it anyway, just to rid myself of the Windows experience that's just been getting worse and worse, says it all really.

> These machines are roughly the size of double-decker buses. To ship one requires 40 freight containers, three cargo planes, and 20 trucks. They are the world’s most complex objects. Each contains over one hundred thousand components, all of which have to be perfectly calibrated for the machine to produce light consistently at the right wavelength.

As a software engineer by trade, the above parable communicates to me two very important things and little else by comparison: that the machines are ultimately fragile and nowhere near "optimised", since the complexity is by own admission substantial to put it mildly; the machine is not a commodity, exactly, one of the million pieces breaking subtly likely renders it inoperable; its cost is proportional to its complexity (read: astronomic); by mere fact it's a focal point of geopolitics only supports the rest of the argument it's a machine of current stone age much like siege engines were at some point the closely guarded secret win-or-lose multiplers of feudal culture.

I mean it's certainly interesting to read about the complexity, but reducing the complexity and commoditising the whole thing is what's really going to be impressive I think :-)

I am probably speaking out against the nerd in us, and none of what I said should detract from enjoying the article or the subject, it's just that I think complexity here is the giveaway of us not having conquered UVL exactly, not quite yet :-) Or maybe we lack the right materials which would allow us to reduce the machine or make it less complex or prone to calibration related errors.

I mean to write "not a panacea", my bad. That it's not the universal cure people think it is. And people _do_ think that re-factoring will magically solve problems, while it doesn't do all that much in practice, less so when you factor in the costs spent on re-factoring.

Assigning to `notSoOpaque` (or any other) property on an object in this case doesn't modify its behaviour, because the property isn't structurally part of the interface -- there's no code defined by the creator / owner of the object (e.g. through the class) that uses it. So it doesn't violate the contract. Private fields are inaccessible, everything else is accessible and is thus part of the interface. I am not saying (and never did) this is the same level as Ada, but your example looks contrived to me -- I don't get the relevance.

Re-factoring code is a _panacea_ -- it's more likely factors that contributed to the code needing re-factoring in the first place, are very much in place still to contribute to the same condition repeating eventually, and another round you go. The factors that produce the causes of re-factoring, usually border on psychological causes embedded deeply within the brains of the developer or developers that are owners of the code. Habits, beliefs, convictions, even "professional traumas". Related here is Conway's Law, where the team, for all individual capacity and capability, cannot but build software that mimics the structure of the developers' ultimate (larger) organisation, thus tying the success of the former to the success of the latter. Re-factoring will only largely repeat the outcome if the organisation hasn't changed.

The exception being obviously a team approaching someone else's codebase -- including that of their predecessor, if they can factor in for Conway's Law -- to re-factor it.

But the same person or persons announcing re-factoring? I always try to walk away from those discussions, knowing very well they're just going to build a better mouse trap. For themselves.

Don't get me wrong, iteration of your own then-brain's product is all well and good, but it takes _more_ to escape the carousel. It takes sitting down and noting down primary factors driving poor architecture and taking a long hard look in the mirror. Not everything is subjective or equivalent, as much as many a developer would like to believe. It's very attractive to stick to "as long as we're careful and diligent, even sub-optimal design can be implemented well". No, it won't be -- this one is a poster-child exception to the rule if there ever was one -- your _design_ is the root and from it and it alone springs the tree that you'll need to accept or cut down, and trimming it only does so much.

Here's an opaque type wrapping numbers, in JavaScript:

    class Age {
        #value;
        constructor(value) {
            if(typeof value != "number") throw new Error("Not a number");
            this.#value = value;
        }
    }

I completely forgot about closures. Frankly, they're still my go-to method for encapsulation, in part because the Java-isation of JavaScript done with the private class members and the onslaught of the "Alan Kay's ideas meet Simula" OOP flavour, is relatively new and I am still unsure whether it's a critical thing to have in JavaScript.

Can't argue with that.

But in defence of JavaScript -- since it enjoys routine bashing, not always undeserved -- it now has true runtime-enforced private members (the syntax is prefixing the name with `#`, strictly as part of an ES6 class declaration), but yeah -- this doesn't invalidate the statement "kind of got there 32 years after Ada, stumbling over itself".

* only if `x` is _an object_ (read: has methods)

To preempt the obvious: yes, I know _everything_ (nearly) in JavaScript is an object, but a module exporting a `Function` can expect the caller to use the function, not enumerate it for methods. And the function can use a declaration in the module that wasn't exported, with the caller none the wiser about it.

I find multiple "strange" flaws with the article, even for my appreciation of Ada _and_ the article as an essay:

* The article claims only Ada has true separation of implementation vs specification (the interface), but as far as I am able to reason, also e.g. JavaScript is perfectly able to define "private" elements (not exported by an ES6 module) while being usable in the module that declares them -- if this isn't "syntactical" (and semantical) separation like what is prescribed to Ada, what is the difference(s) the article tries to point out?

* Similarly, Java is mentioned where `private` apparently (according to the article) makes the declaration "visible to inheritance, to reflection, and to the compiler itself when it checks subclass compatibility" -- all of which is false if I remember my Java correctly -- a private declaration is _not_ visible to inheritance and consequently the compiler can ignore it / fast-track in a subclass since it works much the same as it has, in the superclass, making the "compatibility" a guarantee by much the same consequence

I am still reading the article, but having discovered the above points, it detracts from my taking it as seriously as I set out to -- wanting to identify value in Ada that we "may have missed" -- a view the article very much wants to front.

The article states, quoting:

"JavaScript's module system — introduced in 2015, thirty-two years after Ada's — provides import and export but no mechanism for a type to have a specification whose representation is hidden from importers."

Then:

"in Ada, the implementation of a private type is not merely inaccessible, it is syntactically absent from the client's view of the world."

Am I missing something -- a JavaScript module is perfectly able to declare a private element by simply not exporting it, accomplishing what the author prescribes to Ada as "is not merely inaccessible, it is syntactically absent from the client's view of the world"? Same would go for some of the other language author somewhat carelessly lumps together with JavaScript.

I loved the article, and I have always had curiosity about Ada -- beyond some of the more modern languages in fact -- but I just don't see where Ada separates interface from implementation in a manner that's distinctly better or different from e.g. JavaScript modules.

Hey, $DEITY did its absolute best with the constraints and the requirements. But hey, can't please everyone apparently. Be happy you can relieve yourself well past the intended warranty period. The parts were designed to be easily _aftermarket_ replaceable with sufficient advances in technology, retaining the fundamental design without changes.

First, taking the opportunity this discussion presents, I'd like to state for the record, AGAIN, that I have long appreciated the Win32 API and still do -- not because it's great in and out of itself necessarily, it certainly has more warts than your average toad native to the Amazon, but because it de-facto worked for a long while through simple iteration (which grew warts too though) _and_ while it didn't demand Microsoft had everything for _everyone_, it kept Win32 development stable "at the bottom", as the "assembly" layer of Windows development, which everything else was free to build on, _in peace_. Ironically -- looking at the volume of APIs and SDKs Microsoft is churning out today, by comparison, through sheer mass and velocity -- they've proven utterly unable to be sole guardians of their own operating system. There's a plethora of articles shared on Hacker News on this inadequacy on their part to converge on some subset of software that a Windows developer can use to just start with a window or two of their own, on the screen. Win32 _gave you exactly that_. And even `CreateWindow2` export would have worked beyond what `CreateWindow` or `CreateWindowEx` couldn't provide, because you could count on someone who loved it more to just abstract it with a _thin_ layer like WxWidgets etc. Things _worked_. Now there's internal strife between the .NET and "C++ or bust" teams at Microsoft, and the downstream developers are just everything between confused and irritated, this is entirely self-inflicted, Microsoft. It's also a sign of bloat -- if the company could split these groups into subsidiaries, they could compete on actual value delivered, but under the Microsoft umbrella, the result is entirely different.

Second -- and this is a different point entirely -- not two weeks ago there was at least _two_ articles shared here which I read with a mix of mild amusement and sober agreement, about the _opposite_ of what the author of the article linked above, advocates for -- _idiomatic_ design (usually one that's internally consistent):

* https://news.ycombinator.com/item?id=47738827 ("Bring back Idiomatic Design")

* https://news.ycombinator.com/item?id=47547009 ("Make macOS consistently bad unironically")

What I am getting at is that this is clearly different people vocally preferring different -- _opposite_ -- UX experiences. From my brief stint with graphic design, I know there's no silver bullet there either -- consistency is on some level in a locked-horns conflict with creativity (which in part suggests _defiance_), but it's just funny that we now have examples of both, with the above, to which I should add:

> This is why we can't have nice things!

Also, while we "peasants" argue about which way good design should lean -- someone likes their WinAmp-like alpha-blended non-uniform windows and someone else maintains anything that's not defined by the OS is sheer heresy -- the market for one or the other is kept well fueled and another round on the carousel we all go (money happily changing hands).

For my part I wish we'd settle, as much as settling can be done. The APIs should support both, but the user should get to decide, not the developer. Which is incidentally what CSS was _ideally_ kind of was supposed to give us, but we're not really there with that, and I am digressing.

The ugly truth indeed. It sucks to die for the world you won't enjoy, but sometimes it's the only viable solution. Much of our progress has been to minimise casualties and human suffering in order to sustain the world most can agree is better (than the alternatives), but it seems the period of the wave just hits the troughs farther apart, but when it hits them it's like taking breath before the water swallows you, and without training it's quite the panic and suffering (and prospect of death). We know it's in our bones but we want to forget because our bodies are made to interpret pain in the most direct and literal sense -- re-conditioning is always painful too. Strong people create weak people who create strong people, etc.

So yeah _we_ will be fine, but some of us definitely won't, and with the growth in our numbers on Earth, the proportion of martyrs may be growing. Quantifying personal suffering is not possible, especially if the prospect is death.

I don't want to stir up the hornet's nest here, but in my humble opinion the entire problem rests on the unabated and unchecked modern and "late-stage" capitalism model, championed by the U.S. and since exported to and sprung good root everywhere else, even in Europe where it as of yet has a few more checks and balances (which unsurprisingly draws a lot of ire from its acolytes and priests across the Atlantic).

Soviet Union lost due to an inferior societal model, but this too is too much along what once was a relatively sustainable path. The American dream is now a parody of itself, as it takes more to end up with the rest of them, I could go on about the irony of wanting to escape the pit but not wanting to acknowledge the pit is the 99% of the U.S. -- Not Altmans, Bezos'es, Musks or Trumps or their hordes of peripheral elites.

Point being, the model doesn't work _today_ with its cancerous appetite and correspondingly absurd neglect of the human, _any_ human. We can't have humanism and the kind of AI we're about to "enjoy".

The acceleration of wealth disparity may prove to be nearly geometrical, as the common man is further stripped of any capacity to inflict change on the "system". I hope I am wrong, but for all their crimes, anarchy and in a twist of irony -- inhumane treatment of opponent -- the October revolutionaries in Russia, yes bolsheviks, were merely a natural response to a similar atmosphere in Russia at the turn of the previous century. It's just that they didn't have mass surveillance used against them in the same capacity our gadgets allow the "governments" today, nor were they aided by AI which is _also_ something that can be used against an entire slice of populace (a perfect application of general principles put in action). So although the situation may become similar, we're increasingly in no position to change it. The difference may be counted in _generations_, as in it will take multiple generations to dismantle the power structures we allow be put in place now, with Altmans etc. These people may not be evil, but history proves they only have to be short-sighted enough for evil to take root and thrive.

Sorry for the wall of text, but I do agree with the point of the blog post in a way -- demanding people become civilised and refrain from throwing eggs (or Molotovs) on celebrities that are about to swing _entire governments_, is not seeing the forest for the trees.

There's also no precedent in a way -- our historical cataclysms we have created ourselves, have been on a smaller scale, so we're spiraling outwards and not all of the tools we think we have, are going to have the effect required in order to enact the change we want. In the worst case, of course.

I started using Git around 2008, if memory serves. I have made myself more than familiar with the data model and the "plumbing" layer as they call it, but it was only a year ago -- after more than two decades of using Git, in retrospect -- that a realisation started downing on me that most folks probably have a much easier time with Git than I do, _due_ to them not caring as much about how it works _or_ they just trust the porcelain layer and ignore how "the sausage is made". For me it was always either-or situation -- I still don't trust the high-level switches I discover trawling Git's manpages, unless I understand what the effect is on the _data_ (_my_ data). Conversely, I am very surgical with Git treating it as a RISC processor -- most often at the cost of development velocity, for that reason. It's started to bug me really bad as in my latest employment I am expected to commit things throughout the day, but my way of working just doesn't align with that it seems. I frequently switch context between features or even projects (unrelated to one another by Git), and when someone looks at me waiting for an answer why it takes half a day to create 5 commits I look back at them with the same puzzled look they give me. Neither of us is satisfied. I spend most of the development time _designing_ a feature, then I implement it and occasionally it proves to be a dead-end so everything needs to be scrapped or stashed "for parts", rinse, repeat. At the end of the road developing a feature I often end up with a bunch of unrelated changes -- especially if it's a neglected code base, which isn't out of ordinary in my place of work unfortunately. The unrelated changes must be dealt with, so I am sitting there with diff hunks trying to decide which ones to include, occasionally resorting to hunk _editing_ even. There's a lot of stashing, too. Rebasing is the least of my problems, incidentally (someone said rebasing is hard on Git users), because I know what it is supposed to do (for me), so I deal with it head on and just reduce the whole thing to a series of simpler merge conflict resolution problems.

But even with all the Git tooling under my belt, I seem to have all but concluded that Git's simplicity is its biggest strength but also not a small weakness. I wish I didn't have to account for the fact that Git stores snapshots (trees), after all -- _not_ patch-files it shows or differences between the former. Rebasing creates copies or near-copies and it's impossible to isolate features from the timeline their development intertwines with. Changes in Git aren't commutative, so when my human brain naively things I could "pick" features A, B, and C for my next release, ideally with bugfixes D, E and F too, Git just wants me a single commit, except that the features and/or bugfixes may not all neatly lie along a single shared ancestral stem, so either merging is non-trivial (divergence of content compounded with time) or I solve it by assembling the tree _manually_ and using `git commit-tree` to just not have to deal with the more esoteric merge strategies. All these things _do_ tell me there is something "beyond Git" but it's just intuition, so maybe I am just stupid (or too stupid for Git)?

I started looking at [Pijul](https://pijul.org/) a while ago, but I feel like a weirdo who found a weird thing noone is ever going to adopt because it's well, weird. I thought relying on a "theory of patches" was more aligned with how I thought a VCS may represent a software project in time, but I also haven't gotten far with Pijul yet. It's just that somewhere between Git and Pijul, somewhere there is my desired to find a better VCS [than Git], and I suspect I am not the only one -- hence the point of the article, I guess.

more like old man shouts at someone else's computer