[barbazoo]

Somehow it feels odd that an implementation detail like the programming language it's implemented in is so prominent in the project's description. I have no idea what bash is written in and frankly I don't care much about it. It's a tool that enables me do be more productive. Could it be faster? Probably, but does anyone even notice that in the context of all the other things that we do _with_ it?

Are there any benefits I'm missing that come from it being implemented in Rust?

[GordonS]

If it's a language your proficient in, as an HN user it can be interesting to see the language in the title.

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.

[sezna]

Rust is an active and growing community, and there are a lot of software engineers here who are interested in how the sausage is made. I can think of two solid reasons I like to know when something is written in Rust:

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.

[stouset]

I have dug into the bash source on two separate occasions. Once in response to the absolutely crushing CVE-2014-6271[1] and once to add what should have been a trivial logging feature.

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.

[1]: https://nvd.nist.gov/vuln/detail/CVE-2014-6271

[zachlloyd]

We mention Rust primarily because it produces a really high-performance app and to make clear that it's not built using Electron or web tech.

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:

https://blog.warp.dev/how-warp-works/

[vidarh]

But who would expect Electron or web tech for a terminal?

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.

[wffurr]

I guess you missed the HN posts about another buzzy terminal app that is in fact written with Electron and boasts about extensible web tech as a feature: https://hyper.is/

[vidarh]

I might have suppressed it, as the very idea is the stuff of nightmares.

That said, I'll note that unlike Warp it will actually run on Linux...

[timw4mail]

They exist. Hyper is the most notable one using Electron.

[drran]

DomTerm and xterm.js are terminals for web.

[barbazoo]

I was just looking at that! It seems that I'm also conflating "terminal" and "shell" here possibly. Is Warp both in this case?

[charlespierce]

Warp is a terminal, we still rely on the underlying shell to do the interpretation / execution of the commands. At the moment, we support using bash, zsh, or fish as the shell.

[samatman]

...huh.

Writing a tty which has to support specific shells isn't confidence inducing.

How did you paint yourself into that specific corner exactly?

[vidarh]

I'm guessing the auto-complete handling means they need to understand the line editing of the shell. If they've done it well, it'd hopefully be possible to quickly handle others and/or make it configurable.

[samatman]

Ah, that.. almost makes sense? fish at least has its own autocomplete.

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".

[roydivision]

This. Also the mention of ‘collaboration’ and ‘cloud’ put me off. “Do one thing and do it well”.

[ducktective]

>...I have no idea what bash is written...

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...

[barbazoo]

Yeah I realize I conflated "terminal" and "shell".

[rhacker]

Well just a total guess but since it has a tiny bit more OO than C (traits) it could be argued it has a slightly better (aka more clearly obvious) ability to have plugins which is definitely possible in C, but it means you can pass a thing around that can do certain things for you, whereas in C there's a lot of crufty stuff to do that.

[akira2501]

> whereas in C there's a lot of crufty stuff to do that.

Which is true.. but owing mostly to the fact that C actually has a stable ABI.

[optymizer]

I see comments about open source, safety guarantees, speed, etc, but let's be honest. The real reason why Rust was mentioned in the title is because Rust is popular now and mentioning it attracts attention.

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).

[lp0_on_fire]

there's been a lot of the "[blank] (but in rust)!" posts here lately, much like not too long ago node.js was the new best thing.

[ducktective]

Do you remember what was the cool thing before that? LISP? I'm interested in the history of hype in HN

[lp0_on_fire]

golang, maybe?

[sedatk]

I can see how "written in safe-only Rust" can be a plus, as that comes with certain security and safety assurances, but Rust itself doesn't warrant anything. You can write unsafe code with Rust too.

[Thaxll]

I can guaranty you that stuff using GPU ect ... are using unsafe anyway. They don't even advertise safety on their page.

[ericol]

Rust seems to be all the rages these days (Specially here in HN). Besides that, most of the post on Rust also have the word fast in it (Or a similar word related to the speed of the software).