The Rust Programming Language (vs Go)

Reading about the Rust language and finding a bunch of design decisions I disagree with.

1. Named values are by default immutable. In every other language* ‘const’ is a keyword to set that, but in Rust it’s the default and you have to specifically say ‘mut’ when you want it. This is the wrong default. My code is full of variables and has a handful of constants.

2. “Safety” features make it hard to get things done. I don’t want a ‘safe’ language where it’s hard or (supposedly) impossible to do the wrong thing. This typically will also limit me and get in the way and make me inefficient when I write code that’s just fine. I want a language where it’s easy to do the right thing.

3. Excessive use of closures. It makes me worry about closure capture rules. It has exctra keywords (`move`) to deal with closure capture rules. This may be an idiomatic thing that I can actually avoid most of the time in my own code if I want to.

4. Rust fails to do safe type promotion. Compare i32 to i64. That’s safe, but Rust won’t do it. (Java gets this right. Go gets this wrong too.)

On the plus side, Rust has some basic inheritance! I can define a partially implemented interface (trait) and override the default implementation if I want to. (Go lacks this sadly.) Rust has generics too! Another nice tool for writing once and using a bunch of ways. (Another Go shortcoming.) And macros! Way better than CPP too.

I think in all Rust might be a better language than Go, but I can’t guess the ecosystem and community growth patterns right now. Rust is much newer, so I think Go is in the lead. Maybe over the next year we’ll get a clearer trend line on this stuff.

Dance/Physics

Newtonian Follow: stays at-rest/in-motion unless acted upon; has an equivalent and appropriate reaction for each action.

Quantum Follow: there is a probabilistic distribution of what they might do but you don’t know what they’re going to do until they do it. Sometimes new moves appear as if from nowhere, especially if there is a vacuum of moves.

Relativistic Follow: time is relative, for one of you the dance is over almost as soon as it starts, for the other it seems to drag on forever.

The world is not ending, it is still yet beginning

Life has been on Earth for perhaps the last 1/5th of the history of this rock, which has been around about 1/3rd of the age of the universe.
There has been life on Earth for a billion years and our most concerted efforts of nuclear war and climate change would not eliminate it and prevent another billion years of life on Earth.
Human civilization has been around only the tiniest blink of time in all that.
We may be hitting 'Peak Oil', but I think 'Peak Humanity' is a long time in the future.
We've done all this (look around you, there's this crazy big world of six billion people and sky scrapers and space ships and favelas and sweat shops and bullet trains and everything sacred and profane) in 20,000 years. And we're accelerating. Science fiction writers try to imagine what we might be like in 1000 years or 100 years or 10 years*. Look to the future! In our history of predicting our future we have fallen short in some areas ("where's my flying car? where's our moon base?") but done vastly better in unexpected areas (like that voice controlled supercomputer in your pocket that outstrips most gadgets in Star Trek).

Yeah, I'm an optimist. I think things are going to get better.

(* I think Asimov set a big chunk of his world perhaps 20,000 years in our future but I want to discount that. It was written in the 1950s, and I think newer scifi mostly reaches less far into the future. Also Asimov's world now seems insufficiently advanced compared to our own, or other proposed nearer futures. OR, there are fictional alien races with million year civilizations making the suggestion of what might happen to us that far out; and one story I like where we join them after we mature sufficiently over a similar time span.)

The Right Language For The Job

The right language for the job is ... all of them. All of them at once. I want a garbage collected, bounds checked language that lets me drop down to C-level memory fiddling, runs at over 90% of the speed of plain-old-C and interprets code I type into a prompt. I want a language that checks types at compile time, except when I'm just tossing off some small quick thing. I want a functional programming language ... for about 20% of what I write, object orientation for 30% of my code, and miscellaneous glue of no particular dogma for the rest. I want a language that is terse but explicit and unambiguous. And finally I want a large standard library that helps me get done most of the common tasks I do these days, with a vast community supported set of libraries that cover even more (and most of those libraries have no dependency bloat and depend on nothing more than the standard library).
Did I forget anything?

Developing Portably, For the Future

If I were to start a new project today, what language and environment would I write it in? (Assuming I'm not targetting an environment that makes the choice for me (Android, iOS, browser-side javascript).)
So, let's say I'm doing some data processing or some web serving. I'm writing a command line tool or daemon. I think I'd like it to be portable between my Mac and Linux machines that I own. I'd like to not regret my choice of environment if I'm still using this thing 1-5 years from now.
What's in?
C/C++, Python. I am almost ready to concede adding JavaScript to this list, but I don't actually like the language, though I'm fine with using it when I need to for getting things done in browser UIs. These languages I believe will be solidly supported into the future and remain free of deathspiralling suck. The Python 3 transition is going slowly, but I think it could yet turn out okay. I wish Python had static type checking. C++ has lots of stuff added in the last 10 years that I don't want to use.
What's out?
Java - Oracle seems to be killing it. Damn shame, a few years ago I called it my favorite language.
C# - Microsoft actually made a decent language, I've been using it at work lately, and they did some decent things about pushing it into an open-ish standard. But I don't see any compelling reason to use it and I haven't heard that I can rely on the Mono framework to be reliable now and into the future.
PHP, Ruby - I hear nothing but grief about using these. I dislike PHP as a language and an environment. It's amazing that things like mediawiki and drupal are built on it, but I'm disinclined to hack on them because of PHP.
perl. Been there done that. I use Python now.
Any functional language. They make hard what is easy in other languages.
What's left?
Go - Google has a cute little language there. It has my favorite features checked off like: compiled, bounds-checked, and garbage-collected. It's BSD licensed, so no one company can kill it the way Oracle is doing to Java, but I feel like it's not ready yet. Also it's a kinda weird little language and there are a few major language features that I feel if go had them I would be much more productive when using it. Another major language revision, and some growth in the community library support, and hopefully it'll be better a year from now.

Archive Random Read Performance in Python

I was curious about the performance of random read access of archive files in Python. I knew ZipFile was okay, and I was curious how it would perform compared to an sqlite3 database, and I threw in Tarfile (gzipped) for extra curiosity. The motivation for this was the pytz package and its nearly 600 small read-only data files. In one system in the past it was annoying to install and manage this menagerie, and in a fit of premature optimization I figure it ought to be better to read from one archive file anyhow, so I scratched this curiosity itch and found out some things.

In short:
Zip archives are pretty good.
Gzipped tar files are smaller than zip archives, but much slower to read (at least in the Python implementation). Sqlite3 databases are slightly faster to read than zip files, and a little bit faster still if you don't compress the data.
Sqlite3 databases are much faster to read the first record. Repeated reading from an already open zip archive or sqlite3 database are relatively close in performance.

Here's some data:

The test file generated 1000 files with names between 5 and 100 characters long and data between 50 and 5000 bytes long (uniform distributions, random filler data).
I cut off each test at 10 seconds, so the slower methods wound up with fewer reads done. The test data was made up of random data which was pretty uncompressable. So, everything was trying to compress the data, and decompress it on read, but the resulting archive file sizes were all pretty consistent. On real data (the pytz files) tar.gz can be half the size of zipfile or sqlite3 (which are similar though sqlite is slightly larger). The reopen=TRUE trials re-open the archive file for read before each random read. So the time reported is to open the file and read one random record. Otherwise the archive is opened once and read many times for all the random reads. This makes a huge difference in performance, but sqlite3 has the best archive startup time.

I have a mercurial archive of the sources I wrote to test all this here:
http://bolson.org/~bolson/sqlitearchive
There is also a utility to convert a directory of files into a sqlite3 database that maps paths to BLOBs for each file.

Git is backwards, sometimes

hg diff -r from -r to
svn diff -r from:to
git diff to..from
Let's say "from" is 1969 and "to" is 2010. I think normally I'd write the earlier thing on the left and the later thing on the right. It's a culture bias of our writing system that I assume.
If I run:
git diff 41af332c2c071d941a0aa90b963e4e499e6b16ed 730c38d1a5c7a35b23245c7f4acb03c292ea0c03
and 41… is earlier than 73… then pretty much what I expect happens. I get a forward diff.
But if I run:
git diff master mybranch
I get a reverse diff, which if applied would undo all the changes in mybranch. I have to run it backwards, `git diff mybranch master` in order to get a forward patch I could use to apply my changes. Why?
I can `svn diff ${repo}/trunk ${repo}/branches/mybranch` and get what I want.
I can `hg diff -r otherbranch -r mybranch` and get what I want.
git is backwards, but worse, it's backwards in this one seemingly random case. WTF.
I see git gaining popularity, and I see git sucking, and I hate that. I hate lousy technology winning. I hated that when it was Windows, or 386, or anything. Git sucks. Use Mercurial or Subversion.