2022/04/09
After several attempts at blogspamming their way onto Hacker News (occasionally successfully), the fine inves^H^H^H^H^Hdevelopers at Warp have finally made the front page with a product!
I’m Zach, founder and CEO of Warp, and am excited to show you Warp, a fast Rust-based terminal that’s easy to use and built for teams. As of today, Warp is in public beta and any Mac user can download it. It works with bash, zsh, and fish.
The terminal’s teletype-like interface has made it hard for the CLI to thrive. After 20 years of programming, I still find it hard to copy a command’s output; I always forget how to use
tar; and I always have to relearn how to move my cursor. To fix fundamental accessibility issues, I believe we need to start innovating on the terminal, and keep pushing further into the world of shells, ultimately ending up with a better integrated experience.At Warp we are building a Rust-based terminal that keeps what’s best about the CLI while modernizing the experience.
Whoa, sounds great! After 20 years of programming, I, too, find it
hard to | xclip command output or type man tar
or learn about readline and terminal multiplexer scrolling.
Despite being successfully used for 40+ years, the terminal is ripe for
venture capi^W^Winnovation! What’s not to like, honestly?
Wanted to give it a shot but got disappointed when I launched it and the following happened:
Outgoing request to googleapis.com
Outgoing request to segment.io
Outgoing request to sentry.io
Requires sign up (only via Github, mind you)
Oh.
I definitely understand the concerns. For our public beta, we do send telemetry and associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong. But we only track metadata, never console output. For an exhaustive list of events that we track, see here: https://docs.warp.dev/getting-started/privacy#exhaustive-telemetry-table. Once we hit general availability, our plan is to make telemetry completely opt-in and anonymous.
Oh…
Warp engineer here. I understand your concern.
We will remove telemetry when we enter general availability. It will be opt-in and anonymous.
We really want to improve the product quickly during this beta phase. Collecting data makes it much easier to reach out and get feedback when something goes wrong. But we only track metadata, never console output. For an exhaustive list of events that we track, see here: https://docs.warp.dev/getting-started/privacy#exhaustive-telemetry-table
We are going to open source parts and potentially all of the terminal. We want to allow folks to audit our code and tweak Warp. (emphasis mine)
Oh……
I’ll start with perhaps the most glaring issue: the damn thing phones home more than an anxious middle schooler at summer camp. Terminals should not, must not phone home to anyone at any time.
First, it’s just plain unnecessary. A terminal is the textual interface to the system. As a local program that just runs on your computer (a rarity nowadays, I know), it doesn’t need a network connection to do its job. Its job is to handle input and output between you and the system, which should not functionally depend on a network connection. I know this is possible because plenty of other terminal emulators manage just fine without opening a TCP socket, so it’s definitely not NP-complete or anything.
Second, the potential for abuse is legion. Terminals handle incredibly sensitive data: passwords, private keys, API keys, etc. I don’t care if the only telemetry is “uh oh, this thing crashed”, that’s still too much of a risk to take that something sensitive will get leaked. People, understandably, lost their shit five years ago when it was discovered that iTerm2 was inadvertently leaking information by making DNS requests when mousing over things that might be links, the idea being that iTerm2 could more easily highlight clickable links by just firing off a DNS request first to see if it’s valid.
According to the app’s official website, iTerm2 3.0.0 was released on July 4, 2016, indicating that scores of users leaked sensitive content to DNS servers without their knowledge for more than a year.
Oops. And this was a well-intentioned feature designed to make your life easier in a free and open source terminal. How many passwords and SSH keys is Warp accidentally leaking because they need asstons of telemetry so they can know that you’ve… opened the theme chooser? And how would you even know since it’s closed source? I mean, I suppose getting pwned would tip you off, but it’s a bit late by that point.
Their privacy policy (archive) doesn’t engender confidence either, considering it’s full of lies:
Our general philosophy is complete transparency and control of any data leaving your machine. This means that in general any data sharing is opt-in and under the control of the user, and you should be able to remove or export that data from our servers at any time.
Oh, in general. In general, data sharing is opt-in. Except, you know, right now, when it is, specifically, not opt-in. But it’s fine, because you can totally remove or export the data from their servers, guys. It’s cool. Send an SSL cert by mistake? Just log into your terminal account on the Warp website and click “Please delete sensitive data”, and then trust that they totally did it. This is so much easier than just not sending it in the first place.
Terminal sessions obviously contain a bunch of potentially sensitive information and we want the absolute minimum sent to our servers necessary in order to provide you with the best possible experience.
Obviously. Obviously. The absolute minimum sent to your servers would be, well, zero, and right now, it is decidedly greater than zero.
None of your command input, output, and keystrokes is sent to our servers by default.
Oh good. This thing isn’t a keylogger by default. It could, however, optionally be a keylogger, but don’t worry, that’s turned off. Forever. Or until we really need funding.
Our plan is to eventually open-source the Rust client code and some related projects (e.g. UI framework), however we are not ready to do so just yet. The server portion of Warp will remain closed-source for now.
This is a complicated way of saying: “our product is not open source, and don’t expect it to be”. Startups break promises all the time, especially when there’s no force of law compelling them to do otherwise. I stopped believing the empty promises of my alcoholic father, and you should stop believing the empty promises of Silicon Valley grifters. If you want an open source terminal, go use an open source terminal. There are a million of them, and some of them are even good. As an added bonus, they aren’t trying to justify accepting $23 million from Daddy Techbucks by selling companion software to a web service that doesn’t even exist yet.
I know, I know, don’t bite the hand that jerks you off, but any time you have investors, your product is not really for your users, it’s for your investors. This should be obvious, but some people, especially “modern” software developers employed by startups, seem to forget this. A VC-backed product is for users insofar as it makes money (or has the potential to make money (or at least the potential for a fat exit courtesy of a FAANG)). You can take home the gold in mental gymnastics, but at the end of the day, when the investors say “jump”, you say, “how deep, Sir?”
That’s not a value judgement, either. Regardless of whether or not taking investor money is good, when you take investor money, it obviously has strings attached. This shouldn’t be surprising at all, that’s kind of the whole point of venture capital! But there seems to be this weird sort of amnesia in Startup Land, where companies take VC money, and then people are surprised when those companies act in the interest of their investors first. Well, duh! surprised_pikachu.png That’s like complaining that ExxonMobil funds climate misinformation. What else do you expect? Incentives are incentives, and you’re not on Warp’s board.
It behooves us, then, to ask whom this terminal product is really for, whose needs it really serves. Does it serve you and your needs? Ask yourself:
Now, replace “me” with “Warp” or “Warp’s investors” and answer those questions again. Similarly, ask yourself:
Most of Warp’s features are gimmicks (half of which rely on a network
connection anyway), or unnecessary, or ersatz versions of existing
features. For example, striking C-r will bring up the
history search menu, instead of running a reverse-i-search like you
might expect. Instead of writing a shell script or creating a shell
alias, you create a “workflow”, which involves shlepping through a
graphical menu. Of course, unlike a shell script, workflows only work
with Warp. Instead of using apropos, you can ship a command
to OpenAI so their Mechanical Turk can tell you that
write "documentation" in ascii art is best accomplished by
typing echo "documentation" | figlet. (This was impossible
to figure out how to do before OpenAI existed.) Presumably, Warp is
eating this cost for now, but they’ll have to charge for it at some
point or else quickly go bankrupt forwarding people’s “GET request
JavaScript” queries to OpenAI’s ridiculously expensive API.
People who are effective with existing terminals don’t need a terminal like this to be effective, and people who are not effective with existing terminals will probably not be helped by Warp. That is to say, it’s not the terminal that’s the problem, it’s the developer’s skill level. Any improvements in terminal capability are marginal, by this point, and that’s assuming these features are actually improvements at all.
One need only look at existing software to realize that good developers don’t need terminal gimmicks to be productive. Does FreeBSD suffer because its developers can’t share “blocks”? Is Varnish significantly hampered because its developers can’t “log in” to their terminal? Is the JVM hobbled because its developers’ terminals don’t support “collaboration”? One might respond: “but maybe those developers get work done despite their terminals, and not because of them”. Perhaps, but then why has there been no significant adoption of “fancier” terminals in those communities? (I.e. software projects where people get actual work done, instead of Slack-style “we wrapped ffmpeg in Electron and got a $23 million series A” projects.) I suppose there’s Alactritty, but even its features are relatively austere. Maybe because existing terminals actually do work just fine, and any improvements are being done slowly and methodically.
If you read the now-gigantic Hacker News thread, every time someone mentions that a bunch of these features are possible with existing terminals, someone else chimes in with some stupid gotcha, or responds with the now-so-dead-archaeologists-are-studying-it retort “THIS IS JUST LIKE THAT DROPBOX COMMENT”.
I don’t have anything against Rust. I think it’s a neat language with a lot of great ideas, with incredibly smart people working on it. The Hacker News Rust community, though, is obnoxious to the core. There’s a reason why n-gate pokes so much fun at the Rust Evangelism Strike Force. It’s no secret that a great way to get karma on the Orange Website is to write something in Rust.
Except Warp isn’t even open source (yet! It will be, real soon now. Promise.), so who cares what language it’s written in? They’re distributing a binary; it could be compiled from Delphi for all I care (and I really don’t care). Hopefully, because it’s in Rust, it’ll be less likely to encounter the memory safety issues that can bedevil C programs, but since the source code isn’t even available, announcing that you’ve written the thing in Rust just seems like a sad attempt at pandering. “Hey, it has a few shiny features, and is missing a lot of important ones that people expect, oh, and it’s spyware, but we totally wrote it in Rust!”
Perhaps they hoped that Rust would help with performance (as would native graphics libraries (on macOS only (for now))). Well, HN user monkeytaco did some benchmarking:
I just ran a quick test using Casey Muratori’s termbench (https://github.com/cmuratori/termbench) you are an order of magnitude slower than Alacritty, and also significantly slower than iTerm. Warp also locks up pretty severely and only shows a new frame once every few seconds during most of the run.
Alacritty
CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
VT support: no
ManyLine: 1.5670s (0.0399gb/s)
LongLine: 1.1261s (0.0555gb/s)
FGPerChar: 0.3293s (0.0551gb/s)
FGBGPerChar: 0.6598s (0.0534gb/s)
TermMarkV2 Small: 3.6822s (0.0484gb/s)iTerm
CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
VT support: no
ManyLine: 13.2968s (0.0047gb/s)
LongLine: 3.6535s (0.0171gb/s)
FGPerChar: 1.8944s (0.0096gb/s)
FGBGPerChar: 2.8304s (0.0125gb/s)
TermMarkV2 Small: 21.6750s (0.0082gb/s)Warp
CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
VT support: no
ManyLine: 9.6199s (0.0065gb/s)
LongLine: 8.3727s (0.0075gb/s)
FGPerChar: 8.1124s (0.0022gb/s)
FGBGPerChar: 6.0873s (0.0058gb/s)
TermMarkV2 Small: 32.1924s (0.0055gb/s)
What does one of the Warpers have to say about speed?
…we should generally be at, or near, the performance of Alacritty.
I guess it’s true, in the sense that the moon is “near” the Earth, if you compare it to Pluto.
I can’t believe I have to explain why having to use a Github account to log into your terminal is a terrible idea, but it’s a terrible idea.
Straight from the horse’s tty:
it’s a good question [where’s the devops platform?]. today warp is a terminal as you say. the hope is that we can build a platform around the command-line, but we decided by trying to start with the terminal’s fundamental UX to see if we could improve it. in order to make a platform we believe first we need a great product that folks want to use.
Warp engineer here: Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features.
Come for the terminal, stay for the… handwavey team SaaS? Which doesn’t exist? So, not only does Warp have to build the actual product, they still have to build a terminal for Windows and Linux too. “We want to build a platform for the command line [whatever that means], but instead of actually building that platform, we decided to re-implement the fundamentals of text rendering first. But people will totally pay us for our platform!” The developer and the founder aren’t even in agreement: the developer claims the platform is the product, and the founder claims the terminal is the product. This is a really bad solution in search of an entirely non-existent problem.
If it weren’t already blindingly obvious from the software itself that you shouldn’t trust Xterm But With Spyware, LLC, the utter contempt that the developers and CEO seem to have for the tech community should be more than enough proof. I cite all previous and upcoming quotes from Warpers as sources.
This is part of a broader trend in the startup world: the
infantilization of developer tools, and the commercialization of
everything. Why is the bar so low for developers now? Why don’t we
expect them to be able to do basic things, like pipe output into paste
buffers or type man <command>? If developers struggle
with basic things, I have bad news for the rest of their careers. Decent
developers don’t struggle because their terminal doesn’t support
“blocks” or “sharing”.
Silicon Valley is dominated by dilettantes who have no idea how computers actually work. So, when a slick startup comes along promising them GPT-3 search from within their terminal (in Rust), complete with spyware, they don’t realize why it’s terrible and unnecessary. They see a bunch of blog posts talking about how terminals are antiquated 1, and because they’re used to migrating JavaScript frameworks every six months, they nod along in agreement. “Whoa, 30 years is an eternity!”, they say, having not even been alive for 30 years yet. There’s nobody standing over their shoulder telling them that perhaps there’s a reason why some of these things haven’t changed for 30 years. Some of the reasons aren’t necessarily good, but a lot of them are, like “it’s not broken, why fix it?” or “unnecessary change can cause bugs and instability in working software”. There are reasons why your kernel doesn’t, typically, randomly die in stupid and mysterious ways, and why your four-star Github NodeJS webshit does. One reason is that the people who make changes to the former are extremely thoughtful, careful, and methodical, and the people who make changes to the latter aren’t.
Here’s what you should do instead: if you’re on Linux, pick one of the many free and open source terminal emulators, written by proper experts, that won’t send every keystroke to a thought leader in New York City. rxvt-unicode works great. iTerm2 is the workhorse on macOS, and I highly recommend donating, especially if you at all use iTerm2 regularly. Then forget about Warp and refuse to use ridiculous spyware for something as fundamental as a terminal. (General advice: never get software from .dev domains. It’s like buying drugs from the guy behind the library, except it’s worse, because at least drug dealers are open about not caring about you.)
In the meantime, learn how your computer works. Learn how your
terminal works. Yes, it’s a bit arcane, but it’s important. Learn how
your shell works: how it handles input, how it runs programs, how it
displays output. Learn how your kernel works: how it handles
input, how it runs programs, how it manages memory. Learn C,
then write a lot of it. Struggle to debug a thousand segfaults until you
understand what’s actually happening in the software you write. Install
gdb and use it to debug your code. Write a web server. Open
sockets and receive data from the internet. Soon, you’ll realize that
all of the shinola from companies like Warp is just a really
thinly-veiled attempt at extracting every last red cent from unwitting
developers who can’t
even read the on-screen documentation to quit a text editor.
I give Warp 12-18 months before investors cut their losses and run, and the developers are off “innovating” something else. Maybe we can slap a GPU-accelerated UI (in Rust) on top of GCC and get $23 million for that. (Venture capitalists, pls fund me.) Oh, I’m sorry, GCC is 35 years old; it’s too antiquated. I’m sure we can find something, though.
↩︎The reason you don’t see a feature like blocks (with the exception of Upterm) in most other terminals is because the terminal has no concept of what program is running, or really of anything that’s happening within the shell. At a high level, a terminal reads and writes bytes from a pseudoterminal to interact with the shell. This technology is very antiquated–the shell essentially thinks it is interacting with a physical teletype terminal even though they haven’t been used in practice in over 30 years!