TIL that #Rust, while amazing, isn't so amazing for quick-and-dirty coding. It's like flying the Concorde for a 1-hour car trip.
@JonYoder There are reasons I often reach for the shell for quick-and-dirty things. But for anything serious, it quickly becomes a problem. In the days of Python 2, it was a good replacement, but with Python 3's inability to correctly handle POSIX filenames, environment variables, and parameters, I wouldn't bother. Rust is actually pretty decent for a lot of quick stuff once you get used to it.
@JonYoder I wrote a series of articles on this subject culminating in https://changelog.complete.org/archives/10063-the-fundamental-problem-in-python-3 . In short, I was so burned by my effort to port #pygopherd to #Python 3 -- and the utter crappiness and inconsistency of handling non-UTF8 in even the library bundled with Python -- that I consider it unsuitable for any purpose involving filenames, command-line parameters, or environment variables. One lovely tidbit is the zipfile.py tries to decode non-UTF8 sequences as cp437 in ALL cases!
@JonYoder If you want a coffee with your reading, after that first link, you can check out https://changelog.complete.org/archives/10053-the-incredible-disaster-of-python-3 and https://changelog.complete.org/archives/9938-the-python-unicode-mess . The upshot of it is, as far as I can tell, it is impossible to write cross-platform #Python code that handles filenames correctly on both POSIX and Windows. #Rust gets this right, and Python's attempt to assume the whole world has used #Unicode since the beginning of time is a real pain.
@JonYoder Avoiding #Python - Besides the absurd inconsistencies in https://changelog.complete.org/archives/10053-the-incredible-disaster-of-python-3 and the extreme difficulty verging on the impossibility of properly handling filenames in POSIX (see https://changelog.complete.org/archives/10063-the-fundamental-problem-in-python-3 and https://changelog.complete.org/archives/9938-the-python-unicode-mess ), there is more that makes me shy away. 2/
@JonYoder It is astonishing to me that #Python still has a Global Interpreter Lock in 2022. https://wiki.python.org/moin/GlobalInterpreterLock Multithreading in Python is mostly a fiction. There are kludges like https://docs.python.org/3/library/multiprocessing.html which use fork, pipes, pickling, and message passing to simulate threads. But there are so many dragons down that path -- performance and platform-specific ones (different things can be pickled on Windows vs. Linux) that it is a poor substitute. 3/
@JonYoder When I started using #Python more than 20 years ago now, it was an attractive alternative to Perl: like Perl, you don't have to worry about memory management as with C, but Python code was more maintainable. By now, though, even writing a Unix-style cat command in Python is extraordinarily complicated https://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ . All the "foo-like objects" are an interesting abstraction until they break horribly, and the lack of strong types makes it hard to scale code size. 5/
@JonYoder The one place I still see #Python being used is situations where the #REPL is valuable. (Note, #Haskell also has this). #Jupyter is an example of this too. People use #Python for rapid testing of things and interactive prototyping. For a time, when I had date arithmetic problems, I'd open up the Python CLI and write stuff there. Nowadays it's simpler to just write a Rust program to do it for me, really. 7/
@JonYoder So that leaves me thinking: We're thinking about #Python wrong these days. Its greatest utility is as a shell, not a language to write large programs in. As a shell, it is decent, especially for scientific work. Like other shells, most of the serious work is farmed out to code not written in Python, but there is utility in having it as a shell anyhow. And like a shell, once your requirements get to a certain point, you reach for something more serious. end/
@jgoerzen Read your article. I can see why you avoid #Python, especially 3. In this instance, I think *both* Python and POSIX are stupid. By permitting basically everything, the standard makes it *much* harder for developers to do it without breaking on *something*. And Python 2 definitely had a much better thing going on for string type consistency.
@JonYoder I have more sympathy for the lack of a declared encoding in POSIX, since Unix predated Unicode by decades. And historically, mostly it was not possible to have a binary sequence that was somehow "invalid" in a given encoding as it is now with UTF-8 (basically, we used to just select how our terminals would render certain characters; it was more of a font selection than anything). So now with UTF-8, some binary sequences are invalid in UTF-8 but still valid in POSIX.
For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).