Szorc: Mercurial's Journey to and Reflections on Python 3

Posted Jan 15, 2020 14:28 UTC (Wed) by dvdeug (guest, #10998)
In reply to: Szorc: Mercurial's Journey to and Reflections on Python 3 by foom
Parent article: Szorc: Mercurial's Journey to and Reflections on Python 3

Well, no.

For one, that's a biased view of how software development works. If your program doesn't do something people need, then the onus is generally on its creators and promoters to fix that. If my new compiler only targets ARM64, I don't get to complain at all the people who aren't rushing to retarget it to x86-64 yet consider that a missing feature. Yes, LLVM has limited platform support with respect to many of the older architectures people are trying to support in Debian or NetBSD.

For another, according to roc on this article, LLVM is not interested in adding backends for these architectures. If they're forcing people to try and maintain entire CPU arches out of tree, then that's adding quite a bit of trouble. And while you've been less dismissive than roc has here, it's still far from saying "we're recognize that it would be nice to have these architectures, and if you're familiar with them, we're happy to help you implement them in LLVM/Rust." Offering an adversarial approach to people who want these architectures is hardly the way to convince them to put the work in on them.

Szorc: Mercurial's Journey to and Reflections on Python 3

Posted Jan 15, 2020 21:27 UTC (Wed) by roc (subscriber, #30627) [Link]

> For another, according to roc on this article, LLVM is not interested in adding backends for these architectures.

Don't quote me on that; I'm just speculating. All we actually know is that an m68k backend was proposed and not rejected, and the developer never got around to moving it forward.

Szorc: Mercurial's Journey to and Reflections on Python 3

Posted Jan 16, 2020 7:36 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

> If your program doesn't do something people need, then the onus is generally on its creators and promoters to fix that.

*IF* the creators or promoters care about this particular set people. Maybe they don't? Try to imagine. It could be for any reason, good or bad. Logical or not.

> If my new compiler only targets ARM64, I don't get to complain at all the people who who aren't rushing to retarget it to x86-64 yet consider that a missing feature.

I don't remember reading so many ungrounded assumptions packed in such a small piece of text. Pure rhetoric, it's surreal. I spent an ordinate amount of time trying (and failing) to relate it to something real.

BTW: you keep misunderstanding that roc favors the reality that he merely tries to _describe_.

Szorc: Mercurial's Journey to and Reflections on Python 3

Posted Jan 17, 2020 8:09 UTC (Fri) by dvdeug (guest, #10998) [Link]

>> If your program doesn't do something people need, then the onus is generally on its creators and promoters to fix that.

> *IF* the creators or promoters care about this particular set people.

Rust promoters do care about this particular set of people, or else we wouldn't be having this discussion. Rust promoters are right here complaining that these users don't support the use of Rust because it would hurt portability to their systems. They're not saying "if Debian chooses to reject Rust in core packages over this, that's cool with me." They're telling people they're wrong for finding this particular feature important.

> I don't remember reading so many ungrounded assumptions packed in such a small piece of text.

And yet you don't name one. Implement the features people want or not, but don't get offended that they use alternatives if you don't.

> you keep misunderstanding that roc favors the reality that he merely tries to _describe_.

Roc:
>> I don't know why gcc play along; I suspect it's inertia and a misguided sense of duty.
>> I have more sympathy for potentially relevant new embedded architectures

When you start describing something as "misguided" and saying "I have more sympathy for", you're not neutrally describing reality.

Szorc: Mercurial's Journey to and Reflections on Python 3

Posted Jan 21, 2020 2:40 UTC (Tue) by foom (subscriber, #14868) [Link]

I recognize it would be nice to support these architectures, and would be happy if there was support for anything people actively needed.

Speaking for myself, I'd welcome the addition of new backends upstream, even for somewhat fringe architectures. But, I'd want some reassurance that such a backend has enough developer interest to actually maintain it, so that it's not just an abandoned code-dump. (I believe this is also the general sentiment in the LLVM developer community),

And it is definitely a time commitment to get a backend accepted in the first place. Not only do you have to write it, you have to get a patch series in a reviewable shape, try to attract people to review such a large patch-series, and follow up throughout to requests.

Anyways, I'm not sure what happened with the previous attempt to get a m68k backend added to LLVM. Looks like maybe the submitter just gave up upon a suggestion to split the patch up for ease of review? Or maybe due to question of code owners? If so, someone else could pick it up from where they left off...I'd be supportive if you wanted to do so. (But not supportive enough to actually spend significant time on it, since I don't really care about m68k.)

I'll just note here that Debian does _not_ actually support m68k or any of the other oddball architectures mentioned. Some are unofficial/unsupported ports (which means, amongst other things, that the distro will not hold back a change just because it doesn't work on one of the unsupported architectures...)