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.
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).
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.
Beyond that IMO it’s just a confidence boost to a language the more production quality products written in it.
otherwise, not really.
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.
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 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.
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.
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.
[0]: https://github.com/unicode-org/icu4x/issues/93#issuecomment-...
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.
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/
[3]: https://nova.app
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.
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.
The author doesn't even mention this use case, so I guess we're in very different worlds.
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.
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.
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.
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.
> - 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.
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?
I have no words.
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.
Lapce is really interesting. Nice people too.
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...
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?
* 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.
One could say the same of Aum Shinrikyo.
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.
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.
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.
[1]: https://neovide.dev
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.
How true is that?
look for an EDITOR, segregation is not needed
