Comment by zachlloyd | Hacker News Reader

Comment by zachlloyd | Hacker News Reader

Thanks Peter for posting about us.

Hi HN,

I’m Zach, the author of the post and founder at Warp—a blazingly fast Rust-based terminal.

TLDR; The terminal isn’t built for how modern software engineers work. Software development moved to reusability, composability and collaboration years ago. Terminals are still inherently single-user, linear, and ephemeral because the terminal-shell interface was built during a time people were using physical teletype terminals. This makes it hard for teams to effectively collaborate on production issues, track what actions people are taking, and recall prior events. The terminal-shell interface, which hasn’t changed since the 80s, needs to be rethought if we want to bring the terminal into the modern age.

At Warp, we’re holistically rethinking how the terminal should work to bring it into the modern age. To start, we’ve built shell integrations into Bash, ZSH, and Fish as an additional interface between the terminal and the shell. This interface allows us to group commands and their outputs together, allowing users to take actions on “blocks” i.e. copy/paste, scrolling, sharing. We currently have integrations for bash, zsh, and fish.

We’ve also: * Replaced the prompt with a full-fledged editor * Added Visual menus for history & tab completions * Built a Command Palette to discover and access all shortcuts See a demo here: https://www.youtube.com/watch?v=X0LzWAVlOC0

Speed is our top priority and so we chose to use Rust and GPU rendering. See our engineering post for how we built Warp, including how we co-built our own UI framework for Rust: https://blog.warp.dev/how-warp-works/

Our terminal model code is based on Alacritty’s model code; we’re grateful that a few of the collaborators reviewed our early design docs. Huge thanks to our collaborators: Atom co-founder Nathan Sobo [1], Nushell co-founder Andres Robalino [2], and Fish shell lead developer Peter Ammon [3]! We hope to open source the client soon.

Ask me anything!

[1] https://github.com/nathansobo [2] https://github.com/andrasio [3] https://github.com/ridiculousfish

Your assumptions as presented in the article are somewhere between wrong and irrelevant. The rest of the article and what you are trying to build is somewhere between interesting and awesome. Maybe the introduction is something to revise, so it doesn't trip bs detectors?

> Developers work in teams, but terminals don’t support collaboration

Developers do not work in teams for the work they do in terminals.

> Developers rely on sharing knowledge, but all my terminal work disappears every time I close a session

It does not disappear, for every common configuration I'm aware of. The history persists.

> Developers work across machines, but my terminal environment is tethered to my computer

You use your terminal to connect to other machines. This is completely irrelevant and misleading for something you actually do on one machine.

> Developers are becoming accustomed to nice interfaces, but the terminal inflicts pain and makes me feel like an idiot when I try to do moderately complicated things

Are you trying to talk about shells here? The most complicated thing I do with terminals is to type text, which is the point and does nothing of the kind. Maybe there is a little truth in this when talking about copy/paste usually not working with CTRL+C/CTRL+V, but that's trivial.

This sounds awfully negative, sorry about that. But it's really the text that provokes that. The remainder of the article is better, included graphical auto-completion could be nice for discoverability (if it's better than what pressing tab already offers because of the descriptions). Chat in the terminal I would never want, but well, then I'm not the target.

Spot-on. The "problem statement" the author makes is woefully out of touch. I don't think it's too negative to take issue with the tone and inaccuracy of OP's article.

I'd love to be interested in a new type of terminal, but not if the author has to trash existing terminals with demonstrably false statements.

Note: Prefacing this by saying Warp may not be a panacea, but terminals definitely need to be revamped.

> Developers do not work in teams for the work they do in terminals.

A lot of HNers might be lone wolves, but mentoring juniors and working with cross-functional team members definitely requires sharing terminal sessions.

> It does not disappear, for every common configuration I'm aware of. The history persists.

Commands history persists, within your machine, not necessarily across machines or environments usually (unless you’ve setup elaborate config for that).

But more importantly, I often find my self hoping that output history for each command could be saved too - so I know what happened, what went wrong/right last time, etc etc.

> This is completely irrelevant and misleading for something you actually do on one machine.

Again, it’s not easy to carry over configuration and tooling across machines. Very often, machines I ssh into are missing a lot of my custom config and it’s a pain to re-adapt in the thick of it.

> The most complicated thing I do with terminals is to type text.

IME it super painful to build a shell config that works across Mac/Win/Linux that reliably does word selection, jumping, home/end, etc. I sorely miss all these shortcuts that I easily get in my text editor or IDE.

> pressing tab already offers because of the descriptions

Exactly that though. Autocomplete hovering and providing context is way easier than typing part of the command and pressing tab again and again to see if the completer finds anything.

At least you might be way more their target group than me :) I'm not a lone wolf developer (currently), but sharing terminal sessions really never happens. Collaboration is done via chat/video and if something is shared on the screen, it's the IDE. Ah, and with git of course. Maybe that changes with a more dev ops oriented role, which is definitely not mine.

> Very often, machines I ssh into are missing a lot of my custom config and it’s a pain to re-adapt in the thick of it.

I - and I get the impression that's true for many developers - learned early to minimize the custom config. It's bash, maybe with tmux (or likely just screen) and some sensible defaults, and that's it.

> IME it super painful to build a shell config that works across Mac/Win/Linux that reliably does word selection, jumping, home/end, etc.

But why would one need that? Is your environment that random?

Not OP, but a fan of Warp.

> I - and I get the impression that's true for many developers - learned early to minimize the custom config.

I get the exact opposite impression. My understanding is that as developers become more experienced, they tune their setup more, and have more and more persisted customizations. I consider sshrc[1] a critical part of my workflow for this reason.

> But why would one need that? Is your environment that random?

Most shells by default will occasionally spew out "garbage" text into the terminal like ^[[A. If you know why this happens it's possible to fix, but it's definitely a pain. Personally I consider it very important that all the places that I input text work consistently (e.g. move cursor by word, move cursor to end of line) and Warp providing that is a huge selling point to me.

[1] https://github.com/danrabinowitz/sshrc

> The terminal isn’t built for how modern software engineers work

Have you done user research to confirm this assumption? I love the terminal. And I'm not some ancient dev who's been around since the terminal was invented - I'm in my twenties. But I'm curious if software engineers at large agree with you (judging from these HN comments it seems like they don't).

Hi Zach, this is a worthy effort.

Have you been looking at Wezterm? It is written in Rust and is faster than Altacritty. Altacritty is fast at displaying a wall of text, but all I care about is the interactivity when typing and running commands.

BTW, you are getting a lot of flac here but it seems to be mostly about your marketing angle. Don't take it personal and remember that it is easy enough to fix the marketing angle.

> The terminal-shell interface, which hasn’t changed since the 80s, needs to be rethought if we want to bring the terminal into the modern age.

What does it really mean to bring something to the "modern age"? It seems the objective is to turn the terminal into a multi-collaborative IDE. And if so, just create one, but do not call it a terminal, call it something else.

> Replaced the prompt with a full-fledged editor

Is this better than running a shell interactively in Emacs?

Looks interesting and may be something here. Please do not underestimate inertia of habits.

I have yet to switch (probably never will) to zsh; it breaks enough things from bash that I've never bother learning. I expect my terminal to behave the same everywhere. Unless you can find a place where there is no alternative (e.g. Windows CMD), I will not touch anything that doesn't behave like a good old pty.

Reply on news.ycombinator.com