Are there any benefits I'm missing that come from it being implemented in Rust?
Are there any benefits I'm missing that come from it being implemented in Rust?
That said, it's particularly bizarre for a closed source product, where the language is completely irrelevant ¯\_(ツ)_/¯
Also, I like how simple HN is, but sometimes I wish for "tags", at least for project languages - that would keep the title "cleaner", while still including the language for anyone interested. Would be cool to search HN posts by language too.
1) This is a new codebase that we can study and contribute to. Knowing it is in Rust is relevant, so us Rust people know if we are able to dig into it.
2) Rust makes some guarantees about the properties of programs written in it. These guarantees are of interest to some, to the point where many have adopted Rust versions of common utilities (ls/exa, grep/ripgrep, etc.).
edit: just saw it is closed source. Bit of a bummer, and nullifies my points to a certain extent. But I will leave them up since I think they apply to other projects that are more open.
What this experience (and others like it) have taught me is that far more people should care, and that we as an industry should be investing dramatically more effort into completely rewriting low-level C projects that were designed and developed thirty or more years ago. Little of the code I saw would pass modern code review for a variety of reasons.
Software engineering tools and practices have improved dramatically in those thirty years, but our foundations are built on frankly completely shoddy infrastructure that’s barely held together with duct tape and fishing line. Our industry profits almost exclusively off of building more and more on top of what’s already been built, but I’m convinced it’s becoming increasingly important to spend more of our collective effort on fixing, replacing, and repairing the stuff that lies below.
None of this is meant to malign the efforts of the developers of `bash` or any of the other venerable yet aging tools at the bottom of our stacks. There’s no blame to be had for building a tool with the knowledge and best practices of the time and for being hesitant to “fix what ain’t broke” in the thirty years since. But frankly, these things are a lot more broke and waiting to fail than most of us realize.
Further, none of this is to say that things are on the dire verge of collapse or that any one program is going to be the thing that dooms us all. Simply that our foundations are suspect and are increasing need of repair, particularly as we build ever-higher on them. Community efforts like those to improve OpenSSL in the wake of severe exploits have been invaluable and we need so much more of it. Preferably before exploits are discovered.
So I for one applaud efforts to rewrite and rethink these programs, and especially to develop them in modern languages with stronger protections, infinitely fewer footguns, and better testing infrastructure.
We wrote up a pretty detailed technical design if you're interested in checking out how we built and why we made the decisions we made:
Writing a tty which has to support specific shells isn't confidence inducing.
How did you paint yourself into that specific corner exactly?
I'd be more careful about the messaging then, something like "you can use any shell you want, we provide enhanced features for bash/zsh/fish and are looking to expand that in future".
Having written terminal code both in compiled and interpreted languages, and on machines about a thousand times slower than a typical modern machine, speed here is also much more down to algorithm choices - especially for rendering - than language.
I find the focus on FPS pretty odd as well, as really high update speeds for a terminal typically only comes into play if dumping huge amount of data to the terminal by accident, in which case typically handling scrolling properly is easily speeded up by skipping lines that need never be visible at all.
I do expect terminals I use to be low latency for normal operations, but that's a very different consideration.
Not objecting to your choice of Rust. Just like some others found it odd to highlight it near the top of your main page.
That said, I'll note that unlike Warp it will actually run on Linux...
This is a terminal emulator not a shell language so this should be compared to the likes of Xfce4-terminal, Konsole, Alacritty, Kitty, st, etc...
Which is true.. but owing mostly to the fact that C actually has a stable ABI.
It's the same deal with every popular language that was the new hotness at the time: "written in Python", "written in Ruby", "written in Go" from years ago, which I see less of now.
Nothing wrong with this, it's just a straightforward way of tailoring information to the target audience to maximize engagement with an ad, whether the authors did it consciously or unconsciously (maybe they like Rust a lot and mention it often).