Rust Editors to Replace TextMate 2 – The Agony of Despair | Hacker News Reader

Rust Editors to Replace TextMate 2 – The Agony of Despair

fuzzyblog.io

54 pointsfuzzygroup90 comments

It's funny to see one arguing that Rust programs will be higher quality... in the GUI space. The AreWeGUIYet[0] website shows clearly that a GUI editor written in Rust won't cut. I'd rather argue that editors written in the platform-native language (e.g. ObjC/Swift on macOS) will result in higher quality editors.

If the author is viewing this comment, I'd recommend BBEdit[1], a solid & classic option. Other options might include Chime[2], a Go/Ruby-focused native IDE, or Nova[3], a VSCode-alike native-focused editor. I'm not sure if Chime or Nova would be as stable as TextMate though.

[0]: https://www.areweguiyet.com

[1]: https://www.barebones.com/products/bbedit/

[2]: https://www.chimehq.com

[3]: https://nova.app

The state of GUIs in Rust is atrocious right now. Tbh my biggest hope is that Qt works well with Rust, I can really see a bright future there.

Is there a modern and impressive desktop Qt application?

The entirety of KDE apps (Krita, Kate, Dolphin, Okular, ...).

QGIS is pretty impressive.

They work and they're cross platform. That's impressive and modern.

Almost the entirety of offline computer graphics tooling is written with Qt. Maya, Katana, Nuke etc...

Chances are, if you've seen a movie with any CGI, or played any 3D game, in the last decade, Qt was a major component in making it happen.

Qt also powers the Tesla screens, and most KDE apps and Krita.

I have been working on a qt latex editor: TeXstudio

Although that is years old and perhaps not impressive

Krita, SailfishOS, Calibre, Audacious, AsteroidOS, OBS, VLC, KDE (though I prefer a tiling WM, I have to admit Okular is superb). Qt is cross-platform too, and its FOSS and proprietary friendly.

> FOSS and proprietary friendly.

Aren't they strongly walking back on the first part?

Egui is amazing, Tauri is a better Electron. Both of those things are infinitely better than Qt

Thanks for mentioning egui.

> immediate mode may actually be more performant compared to retained mode. Go to any web page and resize the browser window, and you'll notice that the browser is very slow to do the layout and eats a lot of CPU doing it. Resize a window in egui by contrast, and you'll get smooth 60 FPS at no extra CPU cost.

> you'll get smooth 60 FPS at no extra CPU cost.

The key part there is no EXTRA cost. Most immediate mode GUI libraries redraw 60 frames everytime, so there is a constant somewhat high cost, especially compared with a retained mode program.

Yeah this is something a lot of people overlook, in addition to accessibility.

Immediate UIs, without some partial retained backing, are going to redraw all the time. Especially on mobile devices, this can be a huge power suck

To clarify, egui has a mode where it only redraws while you're interacting with the app (e.g hovering, clicking). It doesn't do anything while idle (e.g. In between keystrokes)

I disagree that ObjC or Swift would result in a better experience by themselves, however I assume you meant to say Cocoa/AppKit and SwiftUI, in which case I would agree.

Note that while SwiftUI benefits greatly from being written in Swift, you could write Cocoa/AppKit quite easily in many languages since it's fairly easy to bind ObjC. There's even Rust bindings https://docs.rs/cacao/latest/cacao/

For SwiftUI, I'm sure someone has written an adapter in other languages but there's so much under the hood magic that SwiftUI does that's tied into the language runtimes, that I think it would be truly herculean to do something in another language.

Druid works quite well, and is likely enough for many GUI projects. I'm not sure what your reasoning is that implementing it in a platform-native language will work better. Are you referring to using their platform native UI to get the keybindings + inbuilt widget integration?

Hi. The author is viewing the comment (finally). What I can tell you is just what I have observed -- compiled artifacts written in Rust, at least initially, seem to be higher quality than things written in C. Rust is a pretty high bar to achieve technical competence in and that seems to result in better quality particularly given that Rust is designed to eliminate a class of errors that plague GUI apps (namely memory leaks). Both of my daily drivers - TextMate 2 and iTerm - are both mature, well developed apps and yet leak memory like sieves and crash pretty regularly.

I will look into Chime and Nova and BBEdit. Go has some level of interesting approaches to development also although they don't go anywhere near as far as Rust.

I don't think I've ever had a memory leak or crash with iTerm in the many years I've been using it, so I'm surprised to hear of your experience.

Does it matter in which language is a text editor written in?

I mean, that's not a feature of the editor, is it? There may be consequences derived from that, but that's part of the features (e.g. uses a lot of memory, or it is slow, or it is hard to build from source, or whatever).

Unless the OP wants to hack that editor, and then it may make sense if they know the language.

in the case of emacs, yes. Basically because emacs has damn near 40 years of hacking that’s been done on it that isn’t separable from elisp, and it’s an editor en passant, as a kind of side effect of being itself.

otherwise, not really.

Yep, emacs isn’t really an editor, it’s a lisp development ecosystem that happens to have “editor” as its primary function.

>Does it matter in which language is a text editor written in?

It does from a marketing perspective. A text editor written in Rust would instantly get upvote and some traction / following. It also signals a much higher quality technical foundation as viewed by most on HN / internet.

Note: I dont endorse Rust nor any of the above as being my views.

Maybe the language itself supports a better technical foundation. I am skeptical about the Rust library ecosystem.

That depends on what kind of libraries you need.

If you are writing a CLI, or TUI, the library ecosystem is pretty good. If you are writing a web server, the ecosystem is ok, but still has some rough edges. If you are writing a GUI... good luck.

Not with the current state of the UI frameworks, not really.

It does if you want your article about it to be on the front page of Hacker News. I could see it mattering if you want to be a part of the community supporting an editor in Rust, because you think it offers great potential to be more stable than an editor in another language — but the author makes it clear that they want an editor which is stable right now.

I'd love to think that I'm smart enough to get something onto Hacker News deliberately -- I'm not. I've gotten one other article I wrote hear in the past decade plus I've been a daily reader.

I'm just someone who keeps getting kicked out of a flow state by software quality. (As a general observation software quality is horrid and if you care about software deeply, it is like a gut punch).

And part of this is me -- I will run 50 plus editor windows, of which maybe 7 or 8 are tabs on active source bases. Still on a machine with N cores and 64 gigs of RAM, I don't think that is asking too much as the aggregate data size is maybe 500K of text ... I mean how big is source code really? Still the way I work seems to cripple things. I just like to maintain all my context at all times (consultant so I'm always juggling stuff).

I think it started to matter when electron based apps became popular due to dismal performance.

Beyond that IMO it’s just a confidence boost to a language the more production quality products written in it.

Well, it can be a signal of other effects. For example, if it is written in python (or ruby), it probably isn't very fast. If it written in JavaScript (especially with electron), it will probably be a memory hog. If it is written in c or c++, there is a bigger risk of segfaults. If it is written in rust, it probably doesn't have a good gui (at least right now). None of those are garantees though.

And the design of the language can influence the design of applications in more subtle ways, for example projects written in languages that are more difficult to learn, like rust or haskell will attract different developers than projects written in more accessible languages like python and JavaScript. Not that either is unilaterally better.

And if course, if you are going to contribute to an open source project, such as editor, that you use, then the language absolutely matters.

My experience with Rust codebases has been different from the Author's. I think his or her points about why Rust should encourage high quality programs makes sense. In practice, most of the Rust OSS I find is poor quality, ie the article's lament of "today's software quality crisis – crashes, bloat and more." I'm suspicious my observations are because I'm viewing select slice of Rust code; perhaps the higher quality code examples aren't OSS, so I haven't seen them.

Examples:

- Rust is well-suited to Embedded. There are a handful of high-quality tools (eg probe-run, defmt, SVD2Rust etc). Most of the higher level libraries, and the chat on Rust embedded communication channels are a mess. Dependency hell, poor APIs, hardware support that's been designed to make trivial examples and never tested on practical firmware etc.

- Backend web dev - Several Flask analogs, but nothing that makes sense to use for a web page. Internally, dependency hell, and filled with generics and Async.

- Graphics programming - Churn, and low-quality results compared to C libraries eg for Vulkan. Fine if you use the libraries that are thin wrappers on the C APIs, but ones that try to apply a Safe or Rusty API are lower quality.

I don't mean this as a disagreement to the article - Rust gives developers tools to make high quality software! The Rust project itself is superb. I'm surprised that his predictions don't match with what we have. (yet)

In both cases I think the problem is that you and the author are slinging around judgements without any actual references to specific code. It's easy to make broad statements.

In your case, you tend to imply that these are due to Rust itself. But is it just due to manpower? C APIs have had so many man hours behind them I can't imagine Rust even being within orders of magnitude.

Without diving into the details these broad statements are just pointless.

I don't think the poor quality code is due to Rust itself. I think manpower is a big part of it. Rust doesn't inherently lead to good quality code, which the article implies.

Re code examples - Here's the Rust Awesome Embedded List - a collection of tools (especially hardware support drivesr) - https://github.com/rust-embedded/awesome-embedded-rust

Most of them aren't suitable for use in practical projects; they're missing important features like non-blocking operation, low-power modes, DMA etc - these are all things that will come up in embedded projects, but aren't needed for the "hello world" examples they include. Part of this is from attempting to conform to embedded-HAL traits, which support only the broadest feature sets.

I’ve been dealing with an example of just what you described: Unicode normalization and collation. There’s a good normalization library in Rust—in terms of the quality of the code, standards conformance, how comfortable I am depending on it, etc.—but it’s a full order of magnitude slower than icu4c.[0] Which shouldn’t come as a surprise! Some of these things take decades.

[0]: https://github.com/unicode-org/icu4x/issues/93#issuecomment-...

Recently, I looked at some string functions in the Rust stdlib and noticed it is full of unsafe code. With comments like "this writes ascii only, so we do not utf-8 validation"

hat validation is slowing down everything

Don't things just take forever. I watched how long Ruby took to deal with Unicode. Sigh. But at least its happening.

Hi, just for context - this was a comparison of `unicode-normalizer` crate to ICU4C.

Since then @hsivonen from Mozilla wrote a new normalizer that recently got merged into ICU4X - https://github.com/unicode-org/icu4x/tree/main/components/no...

I don't have perf numbers yet but I suspect it to be perf comparable to ICU4C at least.

Noted. And you are right about not giving examples. That was a mistake and bear in mind I wrote a rant which I didn't expect to get exposure. A buddy thought it was good enough to submit and that's how I'm here. No is more surprised than I that this showed up here.

In terms of specific examples, I'm now running:

* Starship.rs -- prompt management for my terminal. This is something I've always had issues with and Starship does a great job, better than I've ever had before. * NuShell which I run experimentally on my alternate box and I think I'm finally ready to use in production. * Warp.dev which I'm currently shutting down iTerm2 windows to shift over. * Zed -- which I just got late today and I'm going *try* and use this week. I have less time with this but looks quite good.

I just started looking at `vulkano` this week and have found it pleasant to work with so far. Do you have examples of high level graphics libraries that you consider poor quality?

I liked Vulkano! WGPU by contrast has a mess of an API.

Yeah I could see that. It seems nice and simple at a glance, but I remember some of the lifetime requirements being incredibly strict and hard to work with

At the high level, wgpu API follows WebGPU, which is designed by W3C.

In your criticism, are you referring to the lifetime requirements on resources used in a render pass, or something else?

Yep! And the Pods, Pins, Cows etc.

Interesting. That actually doesn't surprise me. I'm pretty new to the ecosystem and still at the fanboy stage. Learning anything new is hard. Learning something new that is KNOWN TO BE HARD is likely going to be harder. And since the way you make software is by building stuff, and we now do that in the open, we are likely to see some crap (think digital poop droppings littering an ecosystem).

Interesting thoughts on the backend web dev front. Not surprising at all because a compiled language is a poor match for the problem space (web dev is basically string manipulation -- which I don't really think fits Rust).

The rust project itself really is superb. Steve K is doing great work.

Thanks for the compliment but I left the Rust Project back in January.

> I don't think I'm incorrect in saying that when a piece of software written in Rust exists, it is going to be higher quality than something written in C / Swift / C++ / Java.

I have no words.

Thank you for this

Chuckle. Yeah I over reached there. My bad.

https://github.com/lite-xl/lite-xl

https://github.com/lapce/lapce

Are the most promising open alternatives to VSCode, Sublime that I've found.

Terminal editors tend to be non-starters for a serious development editor for me because I want more control over how I format my text. I want to mix fonts. I want to edit markdown with a preview. Emacs has been graphical mode forever.

Amused by the non-starter part because I only write in emacs and almost always in a terminal (via ssh)

And Lite is written in Lua. That's fascinating.

Lapce is really interesting. Nice people too.

> Editing Style - Vim or Emacs

I'd like to see more editors adopt kakoune's[1] editing model.

In some ways it's more intuitive as you define the text object/selection first and you get visual feedback for selections. Coupled with multiple selections, it lets you do stuff that's rather tedious in vim (macros and a lot of manual moving around) more efficiently.

There's Dance[2] for vscode if you want to try it without actually switching to kak.

[1] https://kakoune.org/why-kakoune/why-kakoune.html#_why_kakoun...

[2] https://marketplace.visualstudio.com/items?itemName=gregoire...

Helix (in the article) is also based on Kakoune.

https://helix-editor.com/

There’s some Emacs modes for that

Reading this and warp.dev's site [0], here's some stuff about Bash (and maybe other shells like ksh) people might find useful:

It has a "vi command mode" you can activate with `set -o vi`. It works exactly like you'd dream.

You can search your history with Ctrl-r. It's not "fuzzy" search, but it is "anywhere in the command" search

Vim's (and Neovim's) terminal let you manage the it like any other readonly buffer. You leave insert mode and you can jump around, copy, etc. as much as you like.

I bounced around for literally years between terminals, multiplexers, window managers, etc. Now I have `set -o vi` in my .bashrc and MacVim is my terminal (a close second is Vim in Kitty if you're on a Mac). I've had zero bugs with this setup, and make all my money this way. I'm also super productive, which is fortunate as I (clearly) spend way too much time on HN haha.

[0]: https://www.warp.dev/

The best time to learn Emacs was ten years ago. The second best time is now.

Huh, I thought I was the last person using TextMate. It's still the only editor I've found that's powerful enough for my needs and small enough to fit into my head, that feels like a Mac app, but is extensible using all the power of Unix under the hood. I've been using TextMate since 1.0 when it was the darling editor of the Ruby on Rails community, though I've never been a Rails developer and I hardly ever edit Ruby files that aren't Chef or Homebrew or Cocoapods DSL files. I navigate through a lot of languages and file types throughout my day. Over the course of a week, it's not unusual for me to work on: Python, Javascript, Makefiles, YAML, C, Objective-C, C++, Groovy, Java, shell scripts, Markdown, and plain text files, with nearly 100% of those files in git repos.

Next to TextMate I always have one or more iTerm2 panes open in the same directory as the project I'm working on. I am fluent at switching between the terminal and TextMate during my editing sessions, often using various Unix tools (sed, awk, sort, grep, tr, git, etc) either in iTerm2 or directly via TextMate's ability to pipe text into a process and replace it in the buffer with the output.

I heart TextMate. I've tried others:

- emacs - its working set is bigger than my brain. I used to use it as my primary editor, but I just don't really grok lisp so extending and configuring it was always painful. I'd forget how to use some functionality I knew emacs was capable of and the discovery process for finding it is/was too time consuming. It just felt like emacs demanded too much attention to itself.

- vi - I often use vi as an adjunct editor, but I want a proper Mac app and GUI most of the time.

- Sublime - too un-Mac like.

- VS Code - too bloated and un-Mac like.

- Eclipse - even more bloated and un-Mac like.

- JetBrains various IDEs - haven't really given it a fair shake yet. But I want one editor I can use across all the languages I develop in. I don't want a separate IDE for each language. I'm not sure I want an IDE at all.

- BBEdit - I just find something about it very klunky and its extensibility and integration with the command-line too limited. Its performance is great though and I sometimes use it for reading log files.

Anyway, I've only ever had TextMate crap out like OP describes when I paste a file into it with very long lines AND with syntax highlighting enabled. I suspect one of the syntax highlighting grammars he's using has one or more regex patterns that's backtracking itself to death.

> JetBrains various IDEs - haven't really given it a fair shake yet. But I want one editor I can use across all the languages I develop in. I don't want a separate IDE for each language. I'm not sure I want an IDE at all.

I always have a MacVim window open as a general text editor.

I found that JetBrains IDEs are great for me for programming work because I can group them into these 2 types:

* When I want an IDE — example for iOS work, I use AppCode. The navigation and refactoring capabilities are great. Swift code can be very hard to navigate in an editor that is not an IDE due to type inference.

* When I don't absolutely need an IDE — example for Ruby work, I use RubyMine. I still run commands like `bundle` and `rails` in the terminal. I only use RubyMine for editing code. I use a fairly high end machine so the resources used by RubyMine doesn't bother me (and every other JetBrains IDE is crazy fast compared to AppCode…)

But JetBrains have a decent vim plugin so I still get to use vi across all my work, programming or not, and since their IDEs are all based on the same framework, they work very similarly. So there's familiarity with this combination.

> Python, Makefiles, YAML, C, Objective-C, C++, Groovy, Java, shell scripts, Markdown, and plain text files

> - JetBrains various IDEs - haven't really given it a fair shake yet. But I want one editor I can use across all the languages I develop in. I don't want a separate IDE for each language. I'm not sure I want an IDE at all.

For this language list, you just need two JetBrains IDEs:

* IntelliJ IDEA - for Java, Groovy, and Python

* AppCode - for Objective-C, C, and C++

And then the remaining languages can be handled by either one with plugins.

Oh wow. There's another person who uses TextMate! Hi. I'm not alone ;-)

I've been in TextMate about as long. And I love the product to death. I just want it to stop eating itself. And I really, really wish Allan would treat it seriously. He built a beautiful thing and then seemingly gave up. Right now the publicly checked in code on Github can't be compiled (errors in Rave).

Given that I use Ruby and MarkDown only (maybe some yaml), I can't see the syntax highlighting being the issue since TextMate internally is so much Ruby.

VI is also my adjunct.

I try Sublime every few years and it never feels right.

VS Code - Oy. JavaScript is NOT a proper way to write an editor.

Not an IDE fan.

Eclipse. Not Mac like.

BBEdit -- interesting; I'll add it to the list.

Took a look at ST again. I forgot that it doesn’t let you move the sidebar to the right. This may seem trivial but it’s a blocker for me:

https://github.com/sublimehq/sublime_text/issues/303

Also took at look at Nova. AFAICT it doesn’t let you open more than one window for a single project. So if I want two files from the same project side-by-side I have to make the project window double-width, split it to two panes, then open the files I want in each pane. I hate programs that try to take over from the window manager. With TextMate, I just double click the tab and it pops open into its own window that I can move wherever I want. TextMate also lets me open the same file in two windows, useful when I need to consult one part of the file while editing another. I see no way to do that in Nova. This is basic stuff that Emacs has had for decades.

Fun article and interesting analysis.

That said, why limit yourself to Rust specifically? There are plenty of other languages with "fast enough" implementations/runtimes, which also promote "higher quality software by default" but also don't require manual memory management.

Maybe the limiting factor is availability of good GUI toolkits? Or do text editors need particularly low level control over memory in order to avoid performance issues?

Unless we are talking about embedded, "availability of GUI toolkits" is not something that speaks in Rust's favor, as evidenced by only one of these editors being graphical. Maybe in 2-3 years when the current toolkits had time to mature.

I fundamentally believe that:

* The language you use defines how you attack the problem. If you use Snobol then you can only think of the world as strings. If you use an APL derived language then you think in terms of arrays. * If the language's core attributes really suit the problem then you get something fundamentally different. We see this with Erlang which achieves safety but (finally) acknowledging that stuff crashes so build support for recovery into the language.

As someone who used to commercially sell a text editor derived product, memory management is just plain hard.

VSCode does all of the requirements that blog author wants, and much much more. I don't understand the effort really. This looks like nothing more then hype following blog post.

I guess author would prefer Sublime Text more since it is not eating RAM as much.

Vscode takes more RAM than Chrome nowadays so not a good option for low powered Laptops.

100-200MB of RAM is a lot for all those features?

I've used VS Code and for __my__ use case which is a lot of stuff open concurrently, I've never found it to be performant. It always feels laggy. I'm a consulting and I make side projects so I always have a huge amount of context open at once.

One of my requirements is remote development and vscode has that nailed better than any solution I've ever used. Remote host, container, container on a remote host, cross platform... it 'just works.'

The author doesn't even mention this use case, so I guess we're in very different worlds.

Neovide[1] if it has to be Rust. SublimeText[2] otherwise.

[1]: https://neovide.dev

[2]: https://www.sublimetext.com

I’ve been using zed for a week or two and it’s pretty good. Not ready to replace vscode in my day to day work, but it’s close. Soon I hope.

After TextMate 1.x stopped being updated in 2010-ish, I moved to Sublime Text which felt very TextMate-y, but was a much better piece of software.

Then, in 2020 as the pandemic began, I decided to give Visual Studio Code a try. For this experiment, I chose to use it exclusively for one full week doing real work, and finding solutions for the things that bugged me.

I think it’s been more than a week at this point because I’m still using it full-time. It has a full development team (instead of 1–2 developers who go back-and-forth and how active they are in maintaining the project), and the community who builds things for it is gigantic.

Yes, technically it’s slower than either TextMate or Sublime Text. When I run Linux virtual machines or other lower-performance systems, I use Sublime Text. But after Ogden failed to update TextMate for 4–5 years, I decided it was time to move on. I haven’t used it in over a decade.

Most of the features listed seemed fairly standard for any programming editor.

But what surprised me was this requirement:

> Autosave on focus lost

I'm not sure why any software would initiate a save that was not requested by the user. This seems to be protection for software that has a habit of crashing.

Is this really a good feature?

Seems a strange requirement indeed. What happens if you didn't want to save the changes? Rather what is good to have is saving the state so can be recovered but not committing changes to file. Protection against losing progress isn't only related to the software itself but also the environment. E.g. window manager crashing, operating system crashing, power outage, etc. All the times I had to recover file changes wasn't because the editor crashed but due to something else.

autosave makes programming feel more interactive like a video game.

It’s convenient if you also have something that automatically builds your code when it changes, and then refreshes the browser (that latter part isn’t necessary). That way, you don’t have to think about saving before switching to the browser. Or you can switch to the terminal to run your thing in one keystroke instead of two. It doesn’t make all workflows easier, but it doesn’t hurt too often — if I decide I don’t want to make a change, I just use the editor’s undo feature, or revert all changes to the file using git.

We all have our opinion. I view auto save as essential but it can always be configurable.

“Self selects the programmers willing to learn rust down to an elite handful.”

One could say the same of Aum Shinrikyo.

I wonder if there are more or less Elisp/Lisp programmers in the world than Rust programmers nowadays.

Bwahahha. Kudos.

All - Thank you for your feedback; I'm still digesting. I just got access to the Zed editor and it looks awesome. Here are just the comparison tables: https://gist.github.com/fuzzygroup/8a5ad188e368df0796180d150...

interesting article and one i resonate with personally.

But one things sticks out: the author complains about his text editor taking enormous sums of memory. I sympathise, truly, but obviously this text editor is doing something more than just displaying text that necessitates the ram consumption.

Maybe things are leaking like crazy, but the author isn't using the built-in MacOS text editor, so I wonder what internal costs we attribute to useful tools.

I usually get more bent out of shape about software that I'm forced to run, like Teams, Slack and the progressively heavy Web. (with chrome as a de-facto requirement).

For text editing, there's trade-offs but at least they're yours to make. You can go very far with nvim (and neovide) with almost no memory consumption, but you wont get the nice UI elements.

> I sympathise, truly, but obviously this text editor is doing something more than just displaying text that necessitates the ram consumption.

All I do is edit text. My editor isn't an IDE. It doesn't run tests, etc. It is just an editor. I have no idea why it does what it does but it does it.

And I get what you are saying about nvim / neovide but it feels reasonable to me that __45__ years into the WIMP interface (assuming 1977 as a point when Xerox Parc had things running well) that we should be able to:

* Have a nice UI * That edits text without crashing

I completely agree on tools you are forced to use. Truth.

I’m learning a little bit of rust just using JetBrains Clion.

> Self selects the programmers willing to learn rust down to an elite handful.

How true is that?

Wow this person is almost more unlikeable than me #rare

Why hello ...

emotion prevents you from making proper choice

look for an EDITOR, segregation is not needed

Reply on news.ycombinator.com