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/
@tfb @JonYoder I remember reading the Perl Camel Book with actual excitement - "wow, this is so much easier than C!" And similar writing a GUI in Tcl/Tk nearly 30 years ago now. Today I wouldn't touch either of them. I moved from both of them to Python in the early 2000s, and then from Python to Haskell, OCaml, Rust, etc. after experiencing some issues with scaling Python even in the v2 era. (Now, people are, eg, rewriting #Matrix #Synapse server in non-Python languages for performance)
@tfb @JonYoder One of the things that hit me starting with #Haskell and continuing through #Rust is that rapid prototyping is overrated, and there is a lot to be said for "if it compiles, it is (more) likely to work." I think this has significantly raised my expectations for code quality and reordered how I think about productivity (invest a bit more upfront and spend less time debugging later) C, C++, Java, etc. didn't have that property really.
@jgoerzen I think Test Driven Development provides that assurance, but for real instead of kinda if you squint.
@mike TDD definitely helps, but I guess my experience is that tests don't catch all bugs, compilers don't catch all bugs, and the more bug-catching tools you can have in your toolbox the better.
@jgoerzen There’s also lint available for most interpreted languages and sophisticated configuration environments
@jgoerzen @tfb @JonYoder I felt the same way; I think in both of these cases it's that the languages do some small (but important) things well, but then lack bottom. Tk is still the nicest toolkit I've ever used in some ways (lack of modern widgets notwithstanding), but it's freaking hard to use it for large programs because Tcl's data types suck. Ditto for perl and text slicing.
For people who care about, support, or build Free, Libre, and Open Source Software (FLOSS).