I made some skits showing the program I've been learning Rust with. https://keturn.gitlab.io/execthis/casts.html
(thanks asciinema, you're pretty great.)
The call for Title of Conf proposals https://www.titleofconf.org/cfp asks for writers AND for performers; musical parodies, original music, & original short plays: "stories that capture the day-to-day experience of creating software." Apply by Jan 25, 2020.
Show: May 7, 2020 in Detroit.
re: rust (early impressions)
And my rust-produced executable is a lot bigger than I expected. That's also the sort of thing I only noticed because of this low-footprint goal; it's a concern that will vanish as you move into medium-size programs.
I'm enjoying this as a learning exercise, but practically speaking, is it a good fit for this case?
Maybe should have stuck with Python, assuming there's a shared instance of it already installed on the target. Which would be true of pretty much all Ubuntu-derived installations (it's in ubuntu-core), but maybe it's not as core to Debian as I thought, and it's unclear what runtimes will be available to future versions of OS X. 🤷
Making guesses about portability is hard!
(The initial impetus for this utility was something I couldn't figure out how to make readable in POSIX sh/sed/awk.)
rust (early impressions)
So far, I think this Rust language is probably fine for writing and maintaining programs in.
I'm writing a tiny little utility. It needs so little from a runtime, and it's so peripheral to the system's core concerns, I thought stay-small-and-load-quick would be good qualities.
Seemed like a good candidate for an experiment with Rust, given its ahead-of-time compilation and lack of overhead for memory management.
What I've got so far — which barely does more than parse its arguments — is faster than a minimal CPython program and takes less memory, but CPython doesn't do so badly in comparison.
(I expect they probably scale very differently once you move out of this teensy-scale program; Python imports can accumulate fast.)
Kotlin, path manipulation
Speaking of Kotlin, how does Kotlin standard library deal with paths?
`File("/var/www").resolve(File("/etc/passwd"))` ends up with /etc/passwd, but I am much happier with that named "resolve" than "join".
`File(File("/var/www"), "/etc/passwd"))` doesn't error, but gives /var/www/etc/passwd. You can totally construct /var/www/../../etc/passwd that way, though.
That's `File(File, String)` but there is no `File(File, File)`.
And I don't find any other `File.x(File)` where `x` is anything like `child` or `descendant`.
extending classes (Kotlin +)
This also reminds me that Kotlin's ability to extend classes is real nice.
I could define an extension to pathlib.Path that provides a `safejoin` method. Logically, it's the same as providing a function `safejoin(path1, path2)`, but allows the syntax of `path1.safejoin(path2)`. That makes it look consistent with the original methods, and I can use it by importing safejoin without having to make any Path instance I see into an instance of some SafePath proxy or subclass.
Of course, if I pass that Path instance out to any other library, it's likely to still do the unsafe operation, but can't do anything about that without breaking contracts.
Python 3 (-), Old Man Yells At Cloud
I was appreciating the fact that with Python 3, we finally get a Path type in the standard library.
Until I discovered that `Path('/var/www').joinpath('/etc/passwd')` doesn't throw `InsecurePath`.
Okay, I can imagine there are some use cases where you want to be able to represent `foo/../../assets` or something, but usually not, and resetting the root to `/` never.
which is why t.p.filepath has guarded against that sort of thing since its inception in 2003.
Come on, stdlib, where are my Batteries Included? PEP 428 even cites t.p.filepath as prior art, along with Unipath, which offers a method with similar protections.
I'm checking PEP 428's mailing list discussion, but I don't know how to find this amongst the fucktillion messages debating operator overloading. Maybe that's the answer: everyone who was tired of reading about operator overloading stopped thinking about this PEP.
numpy is extraordinarily useful! That's indisputable. But parts of its interface are vicious. For example: https://www.jessicayung.com/numpy-views-vs-copies-avoiding-costly-mistakes/
And people call nethack player-hostile!
Are there wrappers for numpy that place less priority on extreme conciseness and more on making mistakes hard?
Linux on the Desktop
These container-formats seem to be getting more popular as a way to distribute desktop applications.
A couple times a year I try to figure out what the deal is, but 😵.
Seems like one touted advantage is "sandboxing! Less risk to user?" but ... applications still need to be able to work with my files and input devices?
And Canonical has seemingly pigeonhole'd snaps as a Ubuntu-only thing, but Ubuntu already has a package manager?
and both snaps and flatpak still require root to install apps?
I do not grok. Explainers (oriented toward desktop use) or "don't worry about it; go with whatever the app's packaging maintainer likes" feedbacks solicited.
Today I learned that the Center for Disease Control and the World Health Organization don't believe there's a "black mold" that's unusually toxic.
It's still true that you generally don't want to breathe a ton of mold spores, some people have mold allergies, and you should minimize molds in environments for immunocompromised people, but there's not one color or species of mold that's a lot more dangerous than the others.