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

LLVM doesn't support a number of architectures that distributions/OSes like Debian and NetBSD support using GCC. Linux does in theory run on Qualcomm Hexagon, but as far as I can tell most of those shipments have been in SnapDragon SoCs running ARM chips, and the Hexagon chips are used for Qualcomm-proprietary reasons or specialized multimedia or AI purposes. Mercurial is never going to run on that for anything besides a demo.

The problem with these obsolete architectures is that various groups of volunteers do care about them, but only just barely enough to keep them alive and operational while small amounts of work are required. But there's just not enough interest, ablility, or willingness available to implement anything new for them.

And that's certainly fine and understandable.

But, don't then pretend that the lack of maintenance effort available for these obscure/historical architectures is some sort of problem with the newer compilers and languages. Or, try to convince people that languages which use LLVM should be avoided because it has "limited platform support".

If you mean "I wish enough people still cared about 68k enough for it to remain a viable architecture so I could keep using it", just say that, instead of saying "LLVM's limited platform support", as if that was some sort of actual problem with LLVM.

You didn't go far enough and missed that bit:

> Those are file*names* not opaque identifiers. They are supposed to be interpreted by humans (and therefore decoded) in a wide range of tools

Users don't care who's in charge of _their_ files, kernel or whatever else.

"were"? https://lwn.net/Articles/784041/ Case-insensitive ext4

Now _that_ (case sensitivity) really never belonged to a kernel IMHO. Realism?

Cheers,
Wol

Although in case of trouble-shooting readable file-names are a remedy.

Yet all VCS provide some sort of auto.crlf insanity, go figure.

Just in case someone wants to use Notepad-- from the last decade.

Python: It's a [unstable] scripting language. NOT a systems or application language.

https://docs.microsoft.com/en-us/windows/win32/fileio/nam...

Also, whatever your complaints are about whatever language, with respect to filenames, the win32 api is worse.

It's amazingly inconsistent. The level of insanity is just astonishing, especially if you're going across files created with the win api, and the .net libs.

You *have to p/invoke to read some files, and use the long filepath prefix, which doesn't support relative paths. And that's just the start.

Admittedly, I haven't touched it for almost a decade in any serious fashion, but, based on the docs linked above, it doesn't seem much has changed.

It's remarkable how easy they make it to write files that are quite hard to open..

As for the rest, a lot of infra-related things are being rewritten in Go just because containers (k8s and docker both use Go). That has little to do with the benefits offered by the language. It’s good old network effects. When you’re the container language, and everyone wants to do containers, being decent is sufficient to carry the day.

No one will argue that Go is less than decent. Many will argue it’s more than decent, but that’s irrelevant for its adoption curve.

I'm familiar with libraries stomping on each other at run-time, e.g. with races around fork(). I'm familiar with C libraries stomping on each other with symbol collisions during linking. I've even had listening port collisions with two components in the same container. But my Rust project links multiple versions of some libraries (which libraries, and which versions changes over time), and I haven't had any problems with that so far in practice.

Besides, it's not like Java will detect that there are two different versions of a library on the classpath unless you use special measures to prevent that. It'll just crash later when something tries to call a method that isn't there any more or something like that, so it's not like your approach of “let's just forbid it” prevents anything.

So yeah, I'm not buying it. Libraries should be isolated from each other, anything else just doesn't scale…

At that point, the pyramid crumbles under the weight of its technical debt and wipes out all past “savings”.

> Standalone surrogate code points have either a high surrogate without an adjacent low surrogate, or vice versa. These code points are invalid and are not supported. Their behavior is undefined.

> On Windows, if we get a (Unicode) string we extract the wchar_t * and return it; if we get bytes we decode to wchar_t * and return that.

I believe this means that the Windows version of that module will never try to encode Unicode strings into UTF-16LE (or any other encoding), meaning it won't "catch" invalid surrogates. They should pass straight through to the Windows *W APIs.

This is also supported by the os.path docs, which say the following:

> Unfortunately, some file names may not be representable as strings on Unix, so applications that need to support arbitrary file names on Unix should use bytes objects to represent path names. Vice versa, using bytes objects cannot represent all file names on Windows (in the standard mbcs encoding), hence Windows applications should use string objects to access all files.

Since they only call out bytes objects, I think the implication is that str objects are not a problem on Windows. But the fact that it makes no mention of os.fsencode() and os.fsdecode(), nor the surrogateescape handler, makes me suspicious of whether this documentation is still up-to-date.

By far the most common way to pass a path to a program is on its command line. In Rust you pass a command-line argument by calling Command::arg(...) to add the argument to the command you're building, and Command::arg(...) accepts Paths. Each platform has a standard way to pass arbitrary filenames as command-line parameters, and Rust does what the platform requires.

A few programs accept arbitrary paths as strings on stdin; they need to define how those paths are encoded on stdin. On Linux the program could read null-terminated strings of bytes; then in Rust you would use std::os::unix::ffi::OsStrExt::as_bytes() to extract the raw bytes from a Path and write them to the pipe. That code wouldn't even compile on Windows, which makes sense because a null-terminated string of bytes is not a reasonable way to represent a Windows path. A Windows program accepting paths as strings on stdin needs to define a different encoding, e.g. null-terminated strings of WCHAR, in which case the Rust program would use std::os::windows::ffi::OsStrExt::encode_wide() to produce such strings.

Rust makes it about as easy as possible to reliably pass non-UTF8 strings to other programs.

str.encode(..., errors='replace') # Replaces bad chars with U+FFFD.
str.encode(..., errors='ignore') # Silently drops bad chars.
str.encode(..., errors='xmlcharrefreplace') # Replaces with XML &-encoding
str.encode(..., errors='backslashreplace') # Replaces with \u.... syntax.
Or write your own and hook it into the standard system with https://docs.python.org/3.8/library/codecs.html#codecs.re...

Python is, after all, a "batteries included" language. This is a solved problem.