Hi everyone! I'm the lead developer of Zas Editor. I wanted to share some details about the editor you might be interested in.
The text-storage data structure, syntax highlighting and search features are written in Rust, and the UI is written in Swift since we wanted to create a native macOS experience. The Swift and Rust code talk to each other using C FFI, and no, that doesn’t take away the safety features of both languages.
We’re using the Rope data structure for text representation, and the tree-sitter parser for syntax highlighting and some smart features like file outline, local renaming and symbol search. All other language features are powered by LSP servers (rust-analzyer and gopls).
I’d be happy to answer any questions under this comment or anywhere else in this thread.
This wouldn't keep me from checking it out IF it ran on Linux (they say it likely will eventually) and IF it was significantly better than the competition (vscode+rust-analyzer or intellij+rust plugin). The challenge proprietary software has at this point in certain categories like editors/IDEs is that the free stuff is quite good, so it will have to be MUCH better to succeed. Possible, but hard.
I think it is okay to assume that people who frequent a forum mostly inhabited by people who create software for a living would be okay with software that you would have to pay for.
You might want to put supported languages more front and center and not buried on a hard-to-find faq page. Might also want to allow folks to sign up to be alerted when their favorite language is supported, which will also let you gather data about where there's the most interest.
Thank you for the feedback. We made a change to the landing page, it should be more clear what languages are supported now. The first sentence now is "A new, capable, and fast code editor for Go and Rust, focused on both reading and writing code". A signup is missing, but you can follow us on Twitter @ZasEditor in the meanwhile.
You mentioned elsewhere that VIM bindings are upcoming. I think this product will be an insta-buy for me once there're (reasonably proper) vim bindings. Is there a newsletter or something to know once this feature has landed?
Also as a hint, before you try to re-implement 30 years of VIM bindings and end up with something where everybody misses something, there's a great C library that could be of help:
As I understand the documentation, libvim would manage and manipulate the buffer, i.e. basically "own" the text. However, Zas (and most other editors) already handle that, and probably would want to keep it that way. Does this still work together with libvim then, that libvim operates on a shared custom data structure, whatever the editor (Zas) provides to represent the buffer?
Hi Raph. It amazing to see you here and thank you for all the xi crates.
> Any thoughts on how you made that decision?
The reason behind that is Zas Editor started out as a fork of Xi Editor! We're also using a fork of xi-rope, though we haven't made many changes to it.
If you would like to discuss this more, DM me at twitter @ZasEditor
Congratulations on the launch. There is a demand for a native, fast IDE. I gave Zas a quick spin in our fairly large Go codebase:
Pros:
- really fast
- clean, fresh, minimal UI
Cons:
- Maybe I did something wrong, but one thing I do almost every day is rename something. Right-click a function name (or press F2), pick a better name, done. Zas seems to only rename the occurrences in the current file vs. the declaration.
- The "Open file" suggestions are not great. If I search for a file `moo.go`, one of the first suggestions is `some/folder/moo/some/more/other.go` and then further down the list somewhere it shows `moo.go`
- CMD + click on a symbol should jump to the declaration (or usages)
EDIT: we use GoLand today. Functionality-wise it is great (also builtin TypeScript/JS support is a real plus) but it is slow and hungry.
Integrating object code into Objective C or Swift is easy, commonplace, people do it all the time.
Rust can generate object code all day, you can insist on the C ABI anywhere you need to, and then you can bring in anything from cargo you want. CocoaPods is... not cargo.
Looks really nice, and I wish you a lot of success with it - if you offer most of the features of VSCode and GoLand in a faster and more elegant way, you may be able to carve out a niche for your product, even if it's not cross platform like all the other major editors/IDEs - but since I'm not a macOS user, I'm not in the market for it.
Rust-analyzer destroys my Vscode experience in larger codebases (language features, formatting, version control becomes incredibly slow). I don’t know if there’s anything you can do about it but I hope it will be solved at some point.
This looks like a great start! There's one thing I couldn't find from this page, which I'm sure many developers would ask about: is there a Vim plugin, or Vim mode? And if not, are you planning to add one?
Hi, thanks for the tip, I will add that to the FAQ. There is no VIM key binding at the moment. We are planning to add one; we know how many developers (including us) would want that.
There's quite a few actually. In the hero image, "Documentation Exlporer"; "variable" needs to be pluralized in the "Automatic renaming" section; conversely "documentations" should be singular in the "Dependancies" (sic) bit you pointed out - this is probably non-native English usage as that pattern appears throughout; "different matches" not "difference matches" under multi find; I'm seeing some stretched images in Safari under the Minimap section; and finally when you download it the .dmg is called "Zzas editor"!
Saying all this to be helpful, not snarky or nitty. It's early days and some missing polish is to be expected on the marketing side. I absolutely love that I this exists and that there's another native choice alongside Sublime (which is decently ok for Rust), I'm super excited to see it grow and once I figure out how to upgrade my Mac Pro to OSX 11 then I'll be trying it out.
Congrats to the developer and I wish the team long success.
This looks really great, do you have any plans to support either arbitrary LSP servers, or integrate any more in a "blessed" way? I'd love to use this with Ruby & Solargraph for example.
In the preferences, the code analysis icon is missing.
And auto-updater tells me that I have version 1.0 and there is a new version 1.0.0 . And if I try to update, there is an update error.
It is also a bit confusing if you buy it, because you go to download and can then decide to download for trial or purchase. If you purchase, you just get a screen with the key. But no download. It is not nessasary clear, that the trial is also the main download.
When you say there's no invoice, do you mean there's no email at all with license key/etc. to confirm your purchase, or are you specifically referring to an invoice email?
You may want to make it more obvious this is a native Mac app, not cross-platform. I ignored the window decorations and shortcuts (like I usually do), as those are commonly shown under the assumption of the developer's preferred OS; there's no definitive statement that this is a Mac-only app until the very bottom.
The payment process is a little tricky - it doesn't ask you for an email address and displays the license on the resulting page. If I don't record the license key manually I will need to get in touch with you to try and recover it.
It would be better to get it emailed or get some prompt to record it etc.
Did you consider using ANTLR instead of tree-sitter parser? Don't know too much about tree-sitter but is seems to be a batteries included approach to building parsers?
Any plans to support other languages, specifically Zig? It would be nice if it even just supported wiring in any LSP like Sublime Text LSP and Neovim LSP do.
Zas Editor developer here. I think it’s important to address a problem a few people have mentioned so far: no data is collected other than your Mac’s serial number, which used to be used for finding how many computers a license is used on (we no longer do that)
We’re going to add a privacy policy in the website. We haven’t already done that because we didn’t really expect this much attention within hours of releasing. Honestly, we were expecting few downloads and more technical feedback.
Thank you for not releasing this software on a subscription / rent-a-software business model, and for reasonably pricing it. Most SaaS applications make me feel like a hostage to them, and just not worth the expense and hassle of it.
At least from the website this looks really nice and brings with it some fresh ideas -- kudos on the ship!
Tangential: Are you the only developer on this? How long did it take from first line of code to current state? This sees like a monumental effort, so curious.
I’m not the only developer, but I’ve %90 of the work. Hopefully, we can get more support and expand
> How long did it take from first line of code to current state?
It started out as a part-time side project and after a while I started working full time on it. So, I’m not sure I can give an accurate answer to your question. The first commit was made in August 2020
I wonder if it really still make sense to develop an editor as a commercial product. This is probably a massive effort, and the revenue is maybe not so large.
There is IntelliJ and Visual Studio. IntelliJ is successful, yes, but they have a long history, and the editor is really good. Visual Studio is maybe also successful but I'm not sure how profitable it really was or is.
But otherwise? Sublime Text and others were maybe successful at some point but not sure how profitable they really were. If you count the amount of development which went into it vs the revenue.
For me as a user, I'm extremely hesitant to use any non-open source editor. An editor is a long-term investment. I would not touch this Zas editor unless maybe in 5 to 10 years when it is widely used by many people or when it has become open source but otherwise not. Yes, it looks nice from a first glance but that is by far not enough.
My personal only exception is IntelliJ because it is so good. PyCharm specifically, although I have used other IntelliJ products in the past, starting with the original Java editor, 15 years ago or so, which was heavily praised by some friends.
But otherwise, I want to be able to extend the editor easily, also its core itself. I want to be able to support it when the original developer stopped working on it. Or port it to other systems the developer does not care about. Or do some changes the developer disagrees with. Etc. I want to be sure that it is in principle possible to run this in the next 10-20 years. Or not only me. The nice thing with open source is that many people think likewise, and then there will also be others doing such effort, like supporting it on recent systems, adding features, fixing bugs, etc. So then it is a community effort.
Yeah, people in this thread are praising the one time purchase but I'm almost seeing it as a red flag - how do we know a niche product like this will stick around without recurring revenue? I don't know if that's paid major upgrades or similar.
Edit: As a sibling comment pointed out it does actually do paid upgrades after a year so ignore my comment.
Permanent license with one year of upgrades is - for serious users - a yearly subscription. With a price tag of $25 that sounds quite reasonable and also viable.
> Sublime Text and others were maybe successful at some point but not sure how profitable they really were.
Still profitable enough to be larger than it's ever been, enough to fund new products like Sublime Merge and continue releasing updates. I'd argue any small business that provides a lively hood for at least one person is fairly successful.
I have a paid license for Sublime but I still feel like I’m looking for the “right” editor for me, and if I find anything that looks like it might be it I will happily pay (after a small free trial to see if, like Nova, it’s not for my use cases).
My gut tells me there are a lot of people in this situation.
[Edit: since Go is my main language and I want to learn Rust, I will definitely be giving this a try!]
I mean you are obviously conflicted but you basically already provided the conclusion: Yes, it makes sense – if it's good enough.
Most of the world's coders have probably not been born yet. Code tooling is still getting more valuable per hour spend on developing it. If IntelliJ was worth it in the past, so is potentially every tool from here on out.
Of course with web IDEs and AI coding, the whole space might still end up somewhere else entirely, requiring very different things, but alas, that's always a potential outcome.
But I long ago realized that a text editor was a massive long-term investment and after two editor companies abandoned me, I switched (back) to Vim and doubled down. Had I stuck with Vim in 1992, I could have saved a lot of time.
That said, today it’s Neovim, with IntelliJ kept around for its power and the fact that I often have to open client projects. And VSC for specific plugins that save time (e.g. inspecting SSL cert details b instantly.
Started with Vim, planned on eventually learning Emacs (still do), and then to whatever editor was "flavor of the month", including TextMate and Sublime Text.
Sublime Text was great in it's day, and i still hold a license for the latest version, but it is caught in a death spiral it seems. Whenever i check if it "does X", it turns out it maybe does, but VS Code has a much better plugin than ST ever did.
And so, after a couple of decades, i appear to have come full circle, and now mostly use Vim again, unless a task requires "specific tools", i.e. writing Azure Functions, which is much easier to handle in Visual Studio or VS Code.
I currently settle on Emacs (again) after three years of NeoVim. LSP is so much better integrated and works for my needs out of the box. I currently don't miss treesitter, expect for semantic selections at point.
But I realized I could get rid of a massive and ever changing NeoVim configuration mess. Using Emacs 29 though.
I've also gotten so used to vim keybinding support in almost everything I use (e.g. IntelliJ, VSCode, Obsidian) that I doubt I'd invest in anything without that.
It sounds like that's on the cards for Zas in future though, so looking forward to giving it another try then.
Very good point, actually - Vim keybindings are absolutely the thing to learn, we will forever discuss which editor/guitar is great, but as long as the muscle memory stays the same, you can compare...
This looks really good. I was a major fan of Coda, but I’ve been disappointed with Nova, so I’m looking for something else.
The fact that this isn’t saddled with subscription pricing is a huge plus. I don’t even consider software I can’t own; $24.99 as a one-time payment with a year of updates is more than fair.
This is one of the reasons I like JetBrains subscription service. Even if you stop paying, you get a fallback license that updates every year (I believe); so you have perpetual access to their product, even if slightly out of date.
Telemetry can be very easily turned off. It would take less time for you to Google "how to turn off VSCode telemetry" and finish it than writing this comment. This is ridiculous.
That's assuming you know that your editor is collecting your data and sending it to someone else. And since VS Code is a Microsoft product, they'll probably turn the telemetry back on after an update, only allow you to disable a subset of data collection, or simply ignore your preferences and send it anyways.
There's an interesting potential future here where Apple acquire/acqui-hire the team behind this.
As much as I'm keen to see software like this, making an editor work as a business is hard, and Zas has a long road ahead of it.
However Apple could really use something like this. Xcode is big and bloated, with a ton of support for features that are no longer the future of Apple's platforms (Storyboards, Objective-C, SVN integration...). A clean start with a modern codebase designed for languages fairly similar to Swift, plus the shift towards Swift Package Manager for managing builds (rather than xcodebuild), could be great improvement.
Readit News
The text-storage data structure, syntax highlighting and search features are written in Rust, and the UI is written in Swift since we wanted to create a native macOS experience. The Swift and Rust code talk to each other using C FFI, and no, that doesn’t take away the safety features of both languages.
We’re using the Rope data structure for text representation, and the tree-sitter parser for syntax highlighting and some smart features like file outline, local renaming and symbol search. All other language features are powered by LSP servers (rust-analzyer and gopls).
I’d be happy to answer any questions under this comment or anywhere else in this thread.
I would like to say a bit more, but basically anything of value I could add to the discussion would start a flame war, so I'll have to abstain :(
Also as a hint, before you try to re-implement 30 years of VIM bindings and end up with something where everybody misses something, there's a great C library that could be of help:
https://github.com/onivim/libvim
Glad to see stuff like this, it brings back memories.
> Any thoughts on how you made that decision?
The reason behind that is Zas Editor started out as a fork of Xi Editor! We're also using a fork of xi-rope, though we haven't made many changes to it.
If you would like to discuss this more, DM me at twitter @ZasEditor
Pros:
- really fast
- clean, fresh, minimal UI
Cons:
- Maybe I did something wrong, but one thing I do almost every day is rename something. Right-click a function name (or press F2), pick a better name, done. Zas seems to only rename the occurrences in the current file vs. the declaration.
- The "Open file" suggestions are not great. If I search for a file `moo.go`, one of the first suggestions is `some/folder/moo/some/more/other.go` and then further down the list somewhere it shows `moo.go`
- CMD + click on a symbol should jump to the declaration (or usages)
EDIT: we use GoLand today. Functionality-wise it is great (also builtin TypeScript/JS support is a real plus) but it is slow and hungry.
If it is to stay macOS only, also a possible decision not everything needs to be cross platform, why bring Rust into the picture?
Integrating object code into Objective C or Swift is easy, commonplace, people do it all the time.
Rust can generate object code all day, you can insist on the C ABI anywhere you need to, and then you can bring in anything from cargo you want. CocoaPods is... not cargo.
[0] https://news.ycombinator.com/item?id=30953143
Deleted Comment
Saying all this to be helpful, not snarky or nitty. It's early days and some missing polish is to be expected on the marketing side. I absolutely love that I this exists and that there's another native choice alongside Sublime (which is decently ok for Rust), I'm super excited to see it grow and once I figure out how to upgrade my Mac Pro to OSX 11 then I'll be trying it out.
Congrats to the developer and I wish the team long success.
And auto-updater tells me that I have version 1.0 and there is a new version 1.0.0 . And if I try to update, there is an update error.
It is also a bit confusing if you buy it, because you go to download and can then decide to download for trial or purchase. If you purchase, you just get a screen with the key. But no download. It is not nessasary clear, that the trial is also the main download.
And after purchasing, there is no invoice.
It would be better to get it emailed or get some prompt to record it etc.
Did you consider using ANTLR instead of tree-sitter parser? Don't know too much about tree-sitter but is seems to be a batteries included approach to building parsers?
Can you say more about this choice?
We’re going to add a privacy policy in the website. We haven’t already done that because we didn’t really expect this much attention within hours of releasing. Honestly, we were expecting few downloads and more technical feedback.
https://ec.europa.eu/info/law/law-topic/data-protection/refo...
Deleted Comment
Tangential: Are you the only developer on this? How long did it take from first line of code to current state? This sees like a monumental effort, so curious.
> How long did it take from first line of code to current state?
It started out as a part-time side project and after a while I started working full time on it. So, I’m not sure I can give an accurate answer to your question. The first commit was made in August 2020
There is IntelliJ and Visual Studio. IntelliJ is successful, yes, but they have a long history, and the editor is really good. Visual Studio is maybe also successful but I'm not sure how profitable it really was or is.
But otherwise? Sublime Text and others were maybe successful at some point but not sure how profitable they really were. If you count the amount of development which went into it vs the revenue.
For me as a user, I'm extremely hesitant to use any non-open source editor. An editor is a long-term investment. I would not touch this Zas editor unless maybe in 5 to 10 years when it is widely used by many people or when it has become open source but otherwise not. Yes, it looks nice from a first glance but that is by far not enough.
My personal only exception is IntelliJ because it is so good. PyCharm specifically, although I have used other IntelliJ products in the past, starting with the original Java editor, 15 years ago or so, which was heavily praised by some friends.
But otherwise, I want to be able to extend the editor easily, also its core itself. I want to be able to support it when the original developer stopped working on it. Or port it to other systems the developer does not care about. Or do some changes the developer disagrees with. Etc. I want to be sure that it is in principle possible to run this in the next 10-20 years. Or not only me. The nice thing with open source is that many people think likewise, and then there will also be others doing such effort, like supporting it on recent systems, adding features, fixing bugs, etc. So then it is a community effort.
Edit: As a sibling comment pointed out it does actually do paid upgrades after a year so ignore my comment.
Still profitable enough to be larger than it's ever been, enough to fund new products like Sublime Merge and continue releasing updates. I'd argue any small business that provides a lively hood for at least one person is fairly successful.
My gut tells me there are a lot of people in this situation.
[Edit: since Go is my main language and I want to learn Rust, I will definitely be giving this a try!]
Most of the world's coders have probably not been born yet. Code tooling is still getting more valuable per hour spend on developing it. If IntelliJ was worth it in the past, so is potentially every tool from here on out.
Of course with web IDEs and AI coding, the whole space might still end up somewhere else entirely, requiring very different things, but alas, that's always a potential outcome.
As a regular person you can use Community for free within some limitations. (I think now that there is feature parity between Community an Pro)
If you work for a big company you need Pro or Enterprise sold as subscriptions for rather a lot of $$$. esp the Enterprise version.
The Enterprise version does have some great features that most devs. never get to use
But I long ago realized that a text editor was a massive long-term investment and after two editor companies abandoned me, I switched (back) to Vim and doubled down. Had I stuck with Vim in 1992, I could have saved a lot of time.
That said, today it’s Neovim, with IntelliJ kept around for its power and the fact that I often have to open client projects. And VSC for specific plugins that save time (e.g. inspecting SSL cert details b instantly.
Started with Vim, planned on eventually learning Emacs (still do), and then to whatever editor was "flavor of the month", including TextMate and Sublime Text.
Sublime Text was great in it's day, and i still hold a license for the latest version, but it is caught in a death spiral it seems. Whenever i check if it "does X", it turns out it maybe does, but VS Code has a much better plugin than ST ever did.
And so, after a couple of decades, i appear to have come full circle, and now mostly use Vim again, unless a task requires "specific tools", i.e. writing Azure Functions, which is much easier to handle in Visual Studio or VS Code.
But I realized I could get rid of a massive and ever changing NeoVim configuration mess. Using Emacs 29 though.
I've also gotten so used to vim keybinding support in almost everything I use (e.g. IntelliJ, VSCode, Obsidian) that I doubt I'd invest in anything without that.
It sounds like that's on the cards for Zas in future though, so looking forward to giving it another try then.
"It's paid!"
"It's not multi-platform!"
"It doesn't support my language!"
Dear Zas Editor creator:
Good on you for creating something that solves your problems and challenges you intellectually.
Good on you for putting yourself out there by making it public.
Good on you and for making your efforts sustainable by charging real money for it.
Good on you for taking the first step, and shipping before it's "perfect".
Good on you for taking feedback graciously.
The fact that this isn’t saddled with subscription pricing is a huge plus. I don’t even consider software I can’t own; $24.99 as a one-time payment with a year of updates is more than fair.
Deleted Comment
Considering not even terminals are safe from phoning home telemetry.
You guys are charging for this, how much telemetry is the app sending home?
Wish you guys all the luck.
However, would really love something native as I run so many windows of different projects at once in a regular day.
As much as I'm keen to see software like this, making an editor work as a business is hard, and Zas has a long road ahead of it.
However Apple could really use something like this. Xcode is big and bloated, with a ton of support for features that are no longer the future of Apple's platforms (Storyboards, Objective-C, SVN integration...). A clean start with a modern codebase designed for languages fairly similar to Swift, plus the shift towards Swift Package Manager for managing builds (rather than xcodebuild), could be great improvement.