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.
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?
> 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.
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.
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 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).
> 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.
The terminal is only on life support if you aren't using it. Adding a command palette won't fix it, targeting Mac-first builds? Forget it, your project is already deader than the terminal it replaces.
> This post introduces Warp, a new Rust-based terminal
If one of the main selling points is the language used to implement it, then what do you really have? I propose that the preponderous of "x in y" indicates the death of innovation more than anything.
I found the title of the article a little annoying, but it has a point. It's ridiculous that we're using terminals that still emulate a physical TTY, with all the flaws that come with that.
The failings of terminal semantics have been well-documented (tools with frozen text UI formats because so many tools rely on parsing their output...), but the failings of the terminal UI are large too. Why does editing a multi-line command have to be a pain? Why do the Vim bindings have to suck? Why do I have to screw around adding random files to my ZSH autocomplete directory, or application developers need to add some completion installer for each type of shell? Why can't I tell the shell to color-code stderr vs stdout? Why can't a program open more than 2 IO channels to the terminal? Why is there still not a standard way to display images and video? Why can't the terminal fold long command output into a toggleable expando (like code-folding) instead of me needing to up-arrow to remember what I ran? Why can't I filter output after the fact instead of needing to remember to grep it or tee it into a file and grep that? Shells have fallen way, way behind what modern GUI editors (and TUI ones, more hackily) are able to do. It's easy to write off these kinds of improvements, but 30s re-running a command to grep output there and a minute checking man pages there interrupt your flow and add up to really be a huge waste of time.
There's no reason we should be emulating physical terminals in 2021.
A project like this will only solve maybe ~25% of the gripes you just mentioned, and it certainly won't improve the current interop between terminals. I share your frustration with how archaic it can seem sometimes, but terminals will persist until we stop using hardware that accommodates them. I'd rather see a terminal that embraces these esoteric design flaws, finally providing a reliable cross-platform terminal. Rust would have been the perfect language for that, but it seems like the current devs don't really consider compatibility a priority.
I agree that terminals have plenty of room for improvement, but this whole article feels like marketing fluff. My brain turned off in the middle of it.
I think you should have waited until you had a demo then did a show hn
This looks like a potentially cool project, but some of the marketing here is pretty off-putting. First of all the idea that the terminal is "on life support" is laughable, what tool is more universal? And
> Why doesn’t the terminal work like the rest of your apps? Developer tools have evolved towards reusability, composability, and collaboration.
Terminal workflows may be the single best tool in the first 2 of those 3 categories.
Yeah, I mean maybe I'm overreacting -- I'm all for a better terminal, and there's some genuinely cool stuff here -- it's just undermining its own case by overselling IMO.
I don't. If they did, they'd recognize the fact that the entire concept of "Apps", collaboration, etc..., are examples of ways human beings assemble tools to interact.
Terminals are one of the most direct ways to interact with hardware. If you need to share your hardware with someone else, then you share your screen or a recording. If you need to share your environment or she'll settings, you share scripts.
There's nothing to terminal use to be gained by trying to shoehorn in more net connections, and more uncertainty by merging in more sources of input. By cramming that in you are doing the opposite of caring about users. You're introducing extra elements that can break, decreasing the overall learnability of the system.
On the contrary, the terminal is experiencing something of a renewal with people suddenly caring enough to try ZSH to the point where MacOS is now pushing it, Fish getting traction, and there was a new BASH release in '19.
In case it wasn’t clear, this is a marketing piece by a startup producing this as a product. As far as I can tell, the main features are:
1. Terminal commands and outputs are divided into blocks
2. Input is handled as a text editor
3. Multiuser collaboration tools
Despite the over-the-top marketing hyperbole, I'm curious. I’d really have to see this in practice to know how practical some of these features are. The great thing about traditional terminals is that the bugs and quirks were generally ironed out years ago. I’m hesitant to introduce anything into my workflow where I might spend a lot of timing fighting the tool or chasing tweaks to get things to work right.
If you want to play with the idea of having command output divided into blocks, you can go try it in my terminal Extraterm (https://extraterm.org/) which has had it for years. Or just have a look at the gifs on the features page to get an idea of what is possible: https://extraterm.org/features.html (halfway down page)
The title and opening paragraphs of this article are so aggravating and misguided I almost didn't make it to the end to find out about the interesting technology they have to talk about. Now I can't remember it's name because of the stuff about "the terminal being on life support". Poor approach, hopefully it'll come up again later.
I like my terminal as it is and I don't feel the pain outlined in the problem statement. The pain I feel is performance — I need my prompt to be instant; for a while I had to wait ~300ms for each render, which in terminal land is basically a year. For collaboration there's tmux/tmate. The completion examples already exist in my relatively meagre oh-my-zsh setup. The other completion stuff is done with fzf. I generally don't like GUI stuff, and as for "developers work across machines", well, this old Steve Losh gem[0] comes to mind:
> I can count on my balls how many times I've sat down to program at someone else's computer in the last five years. It just never happens.
That said, I think Warp looks great, and there's definitely space in the world for more terminal options. This could be an excellent gateway drug to entice more developers over to using the CLI, which is an obvious positive. Way too many programmers are hampering themselves by not working with the terminal.
I agree, I am definitely happy with my terminal experience in general, and there is an equivalent for most of the features using a combination of TMux/ZShell/vi mode, etc etc...
It actually feels like I'm living less of my life in UIs these days, and more in the terminal than I did in the 90s/early 2ks.
I think most people aren’t comfortable building a strung together shell environment, full of third-party tools to enable things like completion, search, sessions, etc.
HN might have a lot of people who do, but I’d anecdotally wager that even that isn’t much.
Having a terminal that has everything out of the box, without breaking due to incompatibility between the various tools, is a MASSIVE improvement.
> I think most people aren’t comfortable building a strung together shell environment
So please don't take my comment here as a critique on Warp. I was responding to the sentiment "I like my terminal as it is and I don't feel the pain outlined in the problem statement."
As in I too feel this way. I recognize there are a lot of people who aren't me, and feel differently about things than I do.
I imagine the desire for configurability and customization is similar to the argument between Vim/Emacs and IDEs.
Some people love the customization, plugins, and building a tailored solution. Some people are going to love the out of the box feature set of something like Warp.
The core I was trying to respond to really, was "The pain I feel is performance," which I also strongly relate to, and I wanted to call attention to another excellent Rust based terminal, Alacritty, which really has excellent performance for those of us who like cobbling together our terminal environments.
For me, the ideal terminal is a modern GUI document, backed by a file, with cut-copy-paste, mouse editing, and an insertion point. Using the "terminal" shouldn't be a weird different mode of interaction.
BBEdit's Worksheet is the closest I've seen to this (and before that, MPW, but now I'm just showing my age). But BBEdit doesn't handle curses, which can be very limiting.
Anything beyond straight CLI commands which I can get from a man page is "power user" territory. You're working with a limited market by going after these people.
As I get older, I want less, not more. If I do decide for more, then it's going to be furthering my usage on what has already been available for decades, not the newest shiny thing. Further, I'm going to trust old tools which are still regularly updated over something I would place a significant chance on not being around in 5 years.
Developers make good or bad software regardless of the approach they have taken for the interface. There are CLI's which spark joy and GUI's which I won't waste time on. Will building a better terminal make a CLI better? I suppose it could, but terminal choice has usually been an after-thought for me (usually go straight to Tmux, which fancy terminal programs often screw up.)
Similar to the last point, building the sort of tools which are going to be central to my work is hard. I'm going to use whatever that happens to be regardless of what I feel is my ideal working environment.
I don't know if I care about collaboration or the division into blocks, but there is something to be said about how inputting text into a terminal is a completely different mode of operation. I'm alright at getting around in a text editor with system-level keyboard shortcuts, but as soon as I'm typing into a terminal input buffer I feel like I'm in a weird uncanny valley version of typing. Like how I can't do shift + left/right to highlight text and instead it throws in some hexidecimal number that I then have to delete.
+1, I can salvage some level of text editing functionality with a black-box incantation of bash settings, but it never feels perfect and half of the shortcuts still fail to work.
Basic stuff - like jumping/selecting words, going to the start/end of the line, anything really - needs configuration. Even worse, half of it breaks when I ssh into another machine.
I agree. That’s why I mostly use Eshell in Emacs, but if for some reason I’m in a stand-alone terminal emulator and need some advanced editing capabilities ^X ^E saves the day by firing up Emacs on the current input.
This actually looks pretty cool, but I can't help myself from some quick responses to their first bullets:
> Developers work in teams, but terminals don’t support collaboration
With SSH, tmux supports full terminal session sharing.
> Developers rely on sharing knowledge, but all my terminal work disappears every time I close a session
All shells I know of have configurable history settings. rlwrap will give you the ability to have history (and nice input) for anything shell-ish or interpeter-ish in the terminal.
> Developers work across machines, but my terminal environment is tethered to my computer
All configuration I care about within a terminal can move from machine to machine with typically a single rc file. Often, I don't even need to do this, thanks to remote file editing and being able to send commands via SSH without an interactive session.
> 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
This one is purely subjective and I simply disagree. It's difficult to engage.
A day with your shell's manual and you should be good. Any other applications will have learning curves, and I don't find CLI to be significantly better or worse than a GUI for discoverability.
I think the cool parts of Warp are outside of those bullets. I wouldn't suggest that the responses to the bullets are a replacement to what the product is doing.
I just don't think those bullets make a strong argument on their own. It was a quippy response to a weak intro and not a critique of the product.
In the world of real advancements in terminal development, Plan 9 had come up with Blit and drawterm in the 90's -- so why haven't we made it back to there yet? the answer mostly lies in the lack of simple drawing primitives in X, the TTY interfaces, etc. People like this warp.dev guy come along every few months and poo-poo everything because secretly they do not want to learn it (and neither do we, really!). But nobody really comes along and tries to fix the termcap-brained mindset we still have when considering terminal design. It seems like after everyone got 256-colour and 24-bit colour support we have just accepted the state of things.
54 comments
[ 1.7 ms ] story [ 64.1 ms ] threadHi 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
> 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.
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.
> 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.
> 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?
> 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
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.
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.
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).
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.
Is this better than running a shell interactively in Emacs?
If one of the main selling points is the language used to implement it, then what do you really have? I propose that the preponderous of "x in y" indicates the death of innovation more than anything.
The failings of terminal semantics have been well-documented (tools with frozen text UI formats because so many tools rely on parsing their output...), but the failings of the terminal UI are large too. Why does editing a multi-line command have to be a pain? Why do the Vim bindings have to suck? Why do I have to screw around adding random files to my ZSH autocomplete directory, or application developers need to add some completion installer for each type of shell? Why can't I tell the shell to color-code stderr vs stdout? Why can't a program open more than 2 IO channels to the terminal? Why is there still not a standard way to display images and video? Why can't the terminal fold long command output into a toggleable expando (like code-folding) instead of me needing to up-arrow to remember what I ran? Why can't I filter output after the fact instead of needing to remember to grep it or tee it into a file and grep that? Shells have fallen way, way behind what modern GUI editors (and TUI ones, more hackily) are able to do. It's easy to write off these kinds of improvements, but 30s re-running a command to grep output there and a minute checking man pages there interrupt your flow and add up to really be a huge waste of time.
There's no reason we should be emulating physical terminals in 2021.
I think you should have waited until you had a demo then did a show hn
> Why doesn’t the terminal work like the rest of your apps? Developer tools have evolved towards reusability, composability, and collaboration.
Terminal workflows may be the single best tool in the first 2 of those 3 categories.
No, you're reaction is perfectly reasonable for such nonsensical hyperbole.
Terminals are one of the most direct ways to interact with hardware. If you need to share your hardware with someone else, then you share your screen or a recording. If you need to share your environment or she'll settings, you share scripts.
There's nothing to terminal use to be gained by trying to shoehorn in more net connections, and more uncertainty by merging in more sources of input. By cramming that in you are doing the opposite of caring about users. You're introducing extra elements that can break, decreasing the overall learnability of the system.
IMO this is trying to fix something that isn't broken.
1. Terminal commands and outputs are divided into blocks
2. Input is handled as a text editor
3. Multiuser collaboration tools
Despite the over-the-top marketing hyperbole, I'm curious. I’d really have to see this in practice to know how practical some of these features are. The great thing about traditional terminals is that the bugs and quirks were generally ironed out years ago. I’m hesitant to introduce anything into my workflow where I might spend a lot of timing fighting the tool or chasing tweaks to get things to work right.
> I can count on my balls how many times I've sat down to program at someone else's computer in the last five years. It just never happens.
That said, I think Warp looks great, and there's definitely space in the world for more terminal options. This could be an excellent gateway drug to entice more developers over to using the CLI, which is an obvious positive. Way too many programmers are hampering themselves by not working with the terminal.
[0]: https://www.reddit.com/r/vim/comments/2c3cuu/a_quick_tour_of...
It actually feels like I'm living less of my life in UIs these days, and more in the terminal than I did in the 90s/early 2ks.
I've definitely felt some performance improvement using Alacritty: https://github.com/alacritty/alacritty
HN might have a lot of people who do, but I’d anecdotally wager that even that isn’t much.
Having a terminal that has everything out of the box, without breaking due to incompatibility between the various tools, is a MASSIVE improvement.
So please don't take my comment here as a critique on Warp. I was responding to the sentiment "I like my terminal as it is and I don't feel the pain outlined in the problem statement."
As in I too feel this way. I recognize there are a lot of people who aren't me, and feel differently about things than I do.
I imagine the desire for configurability and customization is similar to the argument between Vim/Emacs and IDEs.
Some people love the customization, plugins, and building a tailored solution. Some people are going to love the out of the box feature set of something like Warp.
The core I was trying to respond to really, was "The pain I feel is performance," which I also strongly relate to, and I wanted to call attention to another excellent Rust based terminal, Alacritty, which really has excellent performance for those of us who like cobbling together our terminal environments.
BBEdit's Worksheet is the closest I've seen to this (and before that, MPW, but now I'm just showing my age). But BBEdit doesn't handle curses, which can be very limiting.
As I get older, I want less, not more. If I do decide for more, then it's going to be furthering my usage on what has already been available for decades, not the newest shiny thing. Further, I'm going to trust old tools which are still regularly updated over something I would place a significant chance on not being around in 5 years.
Developers make good or bad software regardless of the approach they have taken for the interface. There are CLI's which spark joy and GUI's which I won't waste time on. Will building a better terminal make a CLI better? I suppose it could, but terminal choice has usually been an after-thought for me (usually go straight to Tmux, which fancy terminal programs often screw up.)
Similar to the last point, building the sort of tools which are going to be central to my work is hard. I'm going to use whatever that happens to be regardless of what I feel is my ideal working environment.
Basic stuff - like jumping/selecting words, going to the start/end of the line, anything really - needs configuration. Even worse, half of it breaks when I ssh into another machine.
> Developers work in teams, but terminals don’t support collaboration
With SSH, tmux supports full terminal session sharing.
> Developers rely on sharing knowledge, but all my terminal work disappears every time I close a session
All shells I know of have configurable history settings. rlwrap will give you the ability to have history (and nice input) for anything shell-ish or interpeter-ish in the terminal.
> Developers work across machines, but my terminal environment is tethered to my computer
All configuration I care about within a terminal can move from machine to machine with typically a single rc file. Often, I don't even need to do this, thanks to remote file editing and being able to send commands via SSH without an interactive session.
> 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
This one is purely subjective and I simply disagree. It's difficult to engage.
A day with your shell's manual and you should be good. Any other applications will have learning curves, and I don't find CLI to be significantly better or worse than a GUI for discoverability.
Of course you can do some of the stuff Warp does, but you need to have an extensive knowledge. Making them more accessible is always a win.
I just don't think those bullets make a strong argument on their own. It was a quippy response to a weak intro and not a critique of the product.