Gopher Protocol

I’ve been using vi since my mentor at an internship sat me down with a copy of “Unix in a Nutshell” and told me to learn it. This was before I discovered Vim, so I think I was using nvi which had very limited in-editor help. It was a struggle, especially compared to the resources available today.

Around the same time, circa 1999, Tom Christiansen (of Perl fame) wrote an essay called “Zenclavier: Extreme Keyboarding” which still speaks to me, and is worth the read.

In brief, I’ve never been able to “zen out” in a typical non-model text editor, at least not the way I can with [neo]vi[m]. It’s hard for me to overstate how great it is to not have to reach for the mouse - or even outside the home row of the keyboard. Christiansen calls this the “penalty zone” - any time you need to move your fingers away from home row, you’re breaking flow. And when programming, it’s something we have to do all the time!

There are other editors that support this kind of thing, like Emacs. Even VS Code and Visual Studio can be navigated entirely with the keyboard if you’re willing to memorize their keybindings. But they generally rely on “chorded” keystrokes, which put your fingers into sometimes tortured positions (the old unix editor holy war joke is that Emacs stands for “Escape Meta Alt Ctrl Shift”). And often you still have to reach for keys in the “penalty zone”, like PgUp/PgDn/Home/End.

I’m biased, having used vim keybindings in basically every editor I’ve programmed in for the last 25 years. It would be impossible for me to go back now. There are other modal editors, like Helix and Kakoune. They’re basically like vi, but they reverse the order of the keybinds - which has some really nice features, and I might even suggest you try those before getting sucked into vim-land like me. But I do think modal editing, in general, is where it’s at for pure text. Especially programming, but I use it all the time for other tasks like formatting textual data files interactively.

Anyway. Maybe it’s a cop-out, but I think it’s something you have to experience to really appreciate.

Right, if there was a way to mark them as pure (const fn?) that would solve it, mostly - as long as upstream crates started annotating their proc macros as such.

Inko doesn’t rely on garbage collection to manage memory.

Hmm…

Inko allows multiple borrows (both mutable and immutable borrows), and allows moving of the borrowed values while borrows exist

???!!!

To ensure correctness, Inko maintains a reference count at runtime. This count tracks the amount of ref and mut references that exist for an owned value. If the owned value is dropped but references to it still exist, a panic is produced and the program is aborted, protecting you against use-after-free errors.

Oh. It’s a bit cheeky to do runtime ref counting under the hood and then go and say you don’t rely on garbage collection. It’s not a full tracing garbage collector - it’s worse, it lets you create dangling references and then panics at runtime.

Inko looks interesting, for sure, as a Rust-lite that makes some kinds of code easier to write at the cost of more potential panics (safer, maybe…but desirable?). I’m not sure it’s for me though.

Rust is heavily based on Ruby’s design

I would not say “heavily based”. Literally only the closure/lambda syntax, which is cosmetic. Rust is mainly inspired by ML-family languages and C++.

I think Ruby is a reasonable choice for small scripts which someone might otherwise use Python for. But Rust is very well suited to more complicated or long-lasting command-line tools, especially if performance is at all a concern. Clap alone is super nice, but there are a lot of awesome libraries for making rich CLI tools easily.

• colored or owo-colors for adding terminal colors super easily
• crossterm for cross-platform terminal feature support
• rustyline for all your fancy readline needs
• cursive for TUIs
• comfy-table for command-line tables

And like…a hundred more I could mention. Idk, for anything that’s not completely trivial, which will be used and maintained by humans and not thrown away, Rust is really nice.

I suppose I shouldn’t be surprised at the negative response here, but personally this seems like the perfect application of LLMs. Yeah, it’ll need to be verified by humans, but so would human-translated code. Using an appropriately trained LLM to do the first pass translation has the potential to eliminate a lot of toil.