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.

@jgoerzen What kinds of problems have you run into with Python 3?

@JonYoder I wrote a series of articles on this subject culminating in changelog.complete.org/archive . In short, I was so burned by my effort to port to 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 changelog.complete.org/archive and changelog.complete.org/archive . The upshot of it is, as far as I can tell, it is impossible to write cross-platform code that handles filenames correctly on both POSIX and Windows. gets this right, and Python's attempt to assume the whole world has used since the beginning of time is a real pain.

@JonYoder You got me thinking in more detail why I reflexively avoid now, despite the fact that I wrote two large programs ( and ) in it, and published a book about it. 1/

@JonYoder It is astonishing to me that still has a Global Interpreter Lock in 2022. wiki.python.org/moin/GlobalInt Multithreading in Python is mostly a fiction. There are kludges like docs.python.org/3/library/mult 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 Sure, people use for things like work. In this case, Python is merely a shell; the real multithreaded code is in a different language (often C). The way to get performant multithreading out of Python is to not use Python at all. 4/

@JonYoder When I started using 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 lucumr.pocoo.org/2014/5/12/eve . 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 These days, we have credible alternatives to : , , and (among many others). All three of these are performant, avoid all the manual legwork of or the boilerplate of , and provide easy ways to do simple things. 6/

@JonYoder The one place I still see being used is situations where the is valuable. (Note, also has this). is an example of this too. People use 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 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 @JonYoder > We're thinking about #Python wrong these days. Its greatest utility is as a shell, not a language to write large programs in.

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 2/ So I looked into Qutebrowser - thinking "could it really be possible to write a performant browser in ?" The answer is, of course not. Qutebrowser falls into exactly the sort of thing I described: serious work is done in a different language (QtWebEngine).


@Wraptile @JonYoder 3/ "Not fit for" != "never used for". Returning to the example, I think C is not fit for modern development, now that we have . 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

Sign in to participate in the conversation

For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).