Month: May 2014

“Until then, just assume that in the absence of new information, everything is going along perfectly. I thank you in advance for agreeing to this comfortable delusion.” — John Scalzi

Hahahaha.

The GopherCon organizers recently invited me to their new channel on Slack.  (I’m not sure if it’s supposed to be public, or I’d link to it.)  (Edit: It went public shortly thereafter, here.)

Slack.com has a tiny one-line text field to talk about yourself.  That seems insufficient.  So I thought I’d ramble for a bit about my background, both Go-related and in general.

I started program in 1983 when I was 15.  My learning path was, broadly speaking, BASIC, Turbo Pascal, Turbo C, Lisp, Perl, C++, Java.  I’ve programmed professionally mostly in C, Java, and rather a lot of Perl.  The vast majority of my experience has been on the back end, with servers and whatnot.  For several years I’ve been the Linux team lead for Wedo North America (nee Connectiv Solutions), where we process 1-2 billion call detail records (CDRs) a day.

After Go 1.0 was released, a friend “mentioned” me on Facebook with a link to golang.org.  I took the tour and liked it (Go) a lot.  I found Ivo Balbaert’s The Way To Go and read all of it.  I’ve dabbled in it since then, but only recently started working on a project of any size.

Basically, it started to seem really dumb to me that I still interact with my Linux systems using a tty that hasn’t changed all that much since 1970.  It seems to me that the usual Linux shell conflates “model” with “view”.  Just for example: I should be able to get a list of files in a directory, and my shell should be able to sort them by name, size, or whatever, without having to go back and run “ls” again.  And I should be able to say “show all the executable files in green” using just a little CSS.

Ah, but I’ve tipped my hand, so here it is: I’m working on what you might call a browser-based shell.  HTML & Javascript (using AngularJS) on the front end talk to a Go server on the back end.

What is a shell, after all, at its core?  You give it commands and it parses them and runs them.  The root of it is basically “split on spaces, and fork and exec”.  Gosh, Go can do that.  Oh, and “show me the output”.  Browsers kind of excel at that.

Shells also have a programming language.  Which can be very complete, but I’d still rather use Go.  Failing that, I’d rather use Javascript.  Which isn’t perfect, but it’s more of a language than bash, or even zsh.  (I use the latter, if I can.)  Every so often I’m writing something on the command line and I think “Right about here is where a closure would be handy”, and I can’t do it.

Also, I did some statistics on my shell history, and the vast majority of commands I run are some version of “ls” or “cd”.  So my shell should have a built-in file browser.

It also seems strange and annoying that Linux programs talk to each other all to often via poorly formatted text.  “tail -f foo | grep bar”.  It seems like output should be via typed streams.  Or even, channels.  And you should be able to edit a pipeline on the fly, so that “tail -f foo” becomes “tail -f foo | grep bar” becomes “tail -f foo | grep bar > baz”, without having to run three separate commands.

My dream is to have a comparatively seamless interface where I can run commands, and format & manipulate their output, in Javascript, Go, and CSS, more or less on the same command line.  I don’t have a syntax worked out yet, but something vaguely like

js{ run(“ls”).asJson().sort(“name”).style(“+x”).color(“green”) }

where “ls” is actually a Go program that emits “stat” records on a channel down a websocket.

Or something like that.  🙂

I’ve probably rambled enough.  Thanks for reading.