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/
What an alien thing to say. All you have to do is open up github.com or any job listing website to be proven wrong.
I write this using Qutebrowser on Qtile started from a Xonsh shell - Python is not fit for writing large programs! /s
@Wraptile @JonYoder 1/ I have several responses to that. First of all, popularity does not equal suitability. I would say that, today, C isn't really suitable for writing large programs in. I am perfectly aware that many large programs are written in C; I have worked on them personally and professionally. But factors other than suitability come into play (eg, the high cost of rewriting an existing code base in a new language, institutional inertia, dev team skillset, etc.)
@Wraptile @JonYoder 3/ "Not fit for" != "never used for". Returning to the #C example, I think C is not fit for modern development, now that we have #Rust. That doesn't mean it's impossible to use C, or that nobody does; just that, from a purely technical view, having to manage memory manually and deal with all the other numerous pitfalls of C isn't worth it TODAY. Nobody's going to rewrite Apache in Rust tomorrow, but if somebody were starting a new web server tomorrow, C shouldn't be chosen.
@Wraptile @JonYoder 4/ And so it is here. I don't begrudge people the choices they made in the days before Haskell, Go, and Rust were ready. I made similar choices. I also pointed out some cases where Python was helpful (REPL and interactive prototyping, shell-like uses). I said the GIL was a huge problem in modern computing. Your reply confirmed what I said on both counts, so I'm at a loss as to where the substantive disagreement is. /end
For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).