9 ms·

Rust Editors to Replace TextMate 2 – The Agony of Despair

54 points by fuzzygroup 4y ago

fuzzygroup 4y ago
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/8a5ad188e368df0796180d150eb41f67 https://gist.github.com/fuzzygroup/8a5ad188e368df0796180d150...
jmartin2683 4y ago
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.
skyzyx 4y ago
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.
nerdponx 4y ago
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?
- fuzzygroup 4y ago
  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.
- wongarsu 4y ago
  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.
reidrac 4y ago
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.
- superkuh 4y ago
- hprotagonist 4y ago
  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.
  - School-Cotton 4y ago
    Yep, emacs isn’t really an editor, it’s a lisp development ecosystem that happens to have “editor” as its primary function.
- ksec 4y ago
  >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.
  - Filligree 4y ago
    Not with the current state of the UI frameworks, not really.
  - klodolph 4y ago
    Maybe the language itself supports a better technical foundation. I am skeptical about the Rust library ecosystem.
philliphaydon 4y ago
I’m learning a little bit of rust just using JetBrains Clion.
pinewurst 4y ago
“Self selects the programmers willing to learn rust down to an elite handful.” One could say the same of Aum Shinrikyo.
- fuzzygroup 4y ago
  Bwahahha. Kudos.
- Sakos 4y ago
  I wonder if there are more or less Elisp/Lisp programmers in the world than Rust programmers nowadays.
pcr910303 4y ago
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 https://www.areweguiyet.com [1]: https://www.barebones.com/products/bbedit/ https://www.barebones.com/products/bbedit/ [2]: https://www.chimehq.com https://www.chimehq.com [3]: https://nova.app https://nova.app
- MinusGix 4y ago
  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?
- fuzzygroup 4y ago
  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.
  - drcongo 4y ago
    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.
dijit 4y ago
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.
- fuzzygroup 4y ago
  > 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.
Shadonototra 4y ago
emotion prevents you from making proper choice look for an EDITOR, segregation is not needed
jussij 4y ago
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?
- fuzzygroup 4y ago
  We all have our opinion. I view auto save as essential but it can always be configurable.
- forgotpwd16 4y ago
  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.
  - ParetoOptimal 4y ago
    autosave makes programming feel more interactive like a video game.
- Kwpolska 4y ago
  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.
majkinetor 4y ago
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.
- ghishadow 4y ago
  Vscode takes more RAM than Chrome nowadays so not a good option for low powered Laptops.
  - majkinetor 4y ago
    100-200MB of RAM is a lot for all those features?
- fuzzygroup 4y ago
  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.
- topspin 4y ago
  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.
- timeon 4y ago
  I guess author would prefer Sublime Text more since it is not eating RAM as much.
geenat 4y ago
https://github.com/lite-xl/lite-xl https://github.com/lite-xl/lite-xl https://github.com/lapce/lapce 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.
- fuzzygroup 4y ago
  And Lite is written in Lua. That's fascinating. Lapce is really interesting. Nice people too.
- JonChesterfield 4y ago
  Amused by the non-starter part because I only write in emacs and almost always in a terminal (via ssh)
BaculumMeumEst 4y ago
> 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.
- fuzzygroup 4y ago
  Chuckle. Yeah I over reached there. My bad.
- anewpersonality 4y ago
  Thank you for this
js2 4y ago
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.
- fuzzygroup 4y ago
  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.
rayiner 4y ago
The best time to learn Emacs was ten years ago. The second best time is now.
camgunz 4y ago
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/ https://www.warp.dev/
redrobein 4y ago
> 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_kakoune https://kakoune.org/why-kakoune/why-kakoune.html#_why_kakoun... [2] https://marketplace.visualstudio.com/items?itemName=gregoire.dance https://marketplace.visualstudio.com/items?itemName=gregoire...
- petepete 4y ago
  Helix (in the article) is also based on Kakoune. https://helix-editor.com/ https://helix-editor.com/
- fmakunbound 4y ago
  There’s some Emacs modes for that
wly_cdgr 4y ago
Wow this person is almost more unlikeable than me #rare
- fuzzygroup 4y ago
  Why hello ...
- dungjr 4y ago
the__alchemist 4y ago
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)
- fuzzygroup 4y ago
  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.
  - steveklabnik 4y ago
    Thanks for the compliment but I left the Rust Project back in January.
fmakunbound 4y ago
> Self selects the programmers willing to learn rust down to an elite handful. How true is that?
ElectronBadger 4y ago
Neovide[1] if it has to be Rust. SublimeText[2] otherwise. [1]: https://neovide.dev https://neovide.dev [2]: https://www.sublimetext.com https://www.sublimetext.com

54 points by fuzzygroup 4y ago

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/8a5ad188e368df0796180d150eb41f67 https://gist.github.com/fuzzygroup/8a5ad188e368df0796180d150...

jmartin2683 4y ago

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.

skyzyx 4y ago

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.

nerdponx 4y ago

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?

fuzzygroup 4y ago
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.
wongarsu 4y ago
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.

reidrac 4y ago

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.

superkuh 4y ago
hprotagonist 4y ago
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.
- School-Cotton 4y ago
  Yep, emacs isn’t really an editor, it’s a lisp development ecosystem that happens to have “editor” as its primary function.
ksec 4y ago
>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.
- Filligree 4y ago
  Not with the current state of the UI frameworks, not really.
- klodolph 4y ago
  Maybe the language itself supports a better technical foundation. I am skeptical about the Rust library ecosystem.

philliphaydon 4y ago

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

pinewurst 4y ago

“Self selects the programmers willing to learn rust down to an elite handful.” One could say the same of Aum Shinrikyo.

fuzzygroup 4y ago
Bwahahha. Kudos.
Sakos 4y ago
I wonder if there are more or less Elisp/Lisp programmers in the world than Rust programmers nowadays.

pcr910303 4y ago

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 https://www.areweguiyet.com [1]: https://www.barebones.com/products/bbedit/ https://www.barebones.com/products/bbedit/ [2]: https://www.chimehq.com https://www.chimehq.com [3]: https://nova.app https://nova.app

MinusGix 4y ago
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?
fuzzygroup 4y ago
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.
- drcongo 4y ago
  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.

dijit 4y ago

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.

fuzzygroup 4y ago
> 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.

Shadonototra 4y ago

emotion prevents you from making proper choice look for an EDITOR, segregation is not needed

jussij 4y ago

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?

fuzzygroup 4y ago
We all have our opinion. I view auto save as essential but it can always be configurable.
forgotpwd16 4y ago
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.
- ParetoOptimal 4y ago
  autosave makes programming feel more interactive like a video game.
Kwpolska 4y ago
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.

majkinetor 4y ago

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.

ghishadow 4y ago
Vscode takes more RAM than Chrome nowadays so not a good option for low powered Laptops.
- majkinetor 4y ago
  100-200MB of RAM is a lot for all those features?
fuzzygroup 4y ago
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.
topspin 4y ago
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.
timeon 4y ago
I guess author would prefer Sublime Text more since it is not eating RAM as much.

geenat 4y ago

https://github.com/lite-xl/lite-xl https://github.com/lite-xl/lite-xl https://github.com/lapce/lapce 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.

fuzzygroup 4y ago
And Lite is written in Lua. That's fascinating. Lapce is really interesting. Nice people too.
JonChesterfield 4y ago
Amused by the non-starter part because I only write in emacs and almost always in a terminal (via ssh)

BaculumMeumEst 4y ago

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

fuzzygroup 4y ago
Chuckle. Yeah I over reached there. My bad.
anewpersonality 4y ago
Thank you for this

js2 4y ago

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.

fuzzygroup 4y ago
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.

rayiner 4y ago

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

camgunz 4y ago

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/ https://www.warp.dev/

redrobein 4y ago

> 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_kakoune https://kakoune.org/why-kakoune/why-kakoune.html#_why_kakoun... [2] https://marketplace.visualstudio.com/items?itemName=gregoire.dance https://marketplace.visualstudio.com/items?itemName=gregoire...

petepete 4y ago
Helix (in the article) is also based on Kakoune. https://helix-editor.com/ https://helix-editor.com/
fmakunbound 4y ago
There’s some Emacs modes for that

wly_cdgr 4y ago

Wow this person is almost more unlikeable than me #rare

fuzzygroup 4y ago
Why hello ...
dungjr 4y ago

the__alchemist 4y ago

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)

fuzzygroup 4y ago
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.
- steveklabnik 4y ago
  Thanks for the compliment but I left the Rust Project back in January.

fmakunbound 4y ago

> Self selects the programmers willing to learn rust down to an elite handful. How true is that?

ElectronBadger 4y ago

Neovide[1] if it has to be Rust. SublimeText[2] otherwise. [1]: https://neovide.dev https://neovide.dev [2]: https://www.sublimetext.com https://www.sublimetext.com