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.
In one of those Harvard blitz scale talks a guy was saying you need to be at least 10x on a dimension people care about to enter an already established market.
I guess this would be possible for the VS Code market if you could get the same features in something like Tauri where you can dramatically improve the performance and binary size. But VS Code just has so many fantastic features and extensions now, and is still improving so much every month that I don't know if this will ever happen, would take an enormous talented team to catch up, and how do you do such a thing competing against a product that's completely free.
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.
My comment is not an objection to the existence of software that you have to pay for, nor to this piece of software in particular. But for me, and, clearly, many here, either the Mac-only fact, or the non-free fact, mean that we’re simply not interested, and we’re only informed of these facts after many pages. (The beer facet of free software is the least important part.)
The average income here is several sigmas right of what most people make. Mostly from writing software that isn't being given away for free. It isn't like this is some hippie commune. The vast majority of people here are in software to make money. Hopefully a lot of money.
It isn't the kind of place where acting entitled because you didn't get your free lunch makes you look good. I think it would be a bit more dignified to be thankful when something is free (as in beer or otherwise), but respect that some things aren't. For exactly the same reasons most of us are here: to make a living.
> The average income here is several sigmas right of what most people make.
That's exactly the kinds of elitist bullshit that stinks up the HN comments so often. You have no information at all on the average income here; nor any idea on who all reads/writes on HN. The major difference with reddit is the entitled attitude, not skills/income/intelligence as so many assume.
You act like it is some grave faux pas when developers show us software they are charging money for without labeling it with warnings that it isn't free. I'm sorry, but that's terribly bad form when you are on a forum that largely consists of people making a living writing software.
By labeling people as "elitist" when they point out that this leaves you somewhat wanting in the professional courtesy department you only make my point for me.
Try not to feel so entitled to other people's work.
You completely missed the point the person you're replying to was making (for the second time?)
> But for me, and, clearly, many here, either the Mac-only fact, or the non-free fact, mean that we’re simply not interested, and we’re only informed of these facts after many pages.
I'm really not sure what caused you to 'wax poetic' on the value of good software which I don't think anyone is disputing. But it's totally out of place and honestly quite patronizing.
He simply said that if your product is not free software (ie gpl) or if it's OS-specific, you might as well mention it very soon, and not at the end of a 1000-yard page aka don't be an inconsiderate ass wasting people's time. I don't know what you are going off about.
Problem is, people mostly don't pay for free software. Even if they know how hard it is to make it. The free software we have, we got thanks to corporate charity.
I don't agree. Most of the free software on my desktop was made by individuals who in their spare time. That doesn't mean they don't get paid way too little, so your points still stands, but i object to the "corporate charity" angle. Most corporations take way more than they give back.
Well, there are degrees. All the software I've written within recent memory (last 5-6 years or so) has software that was written by some commercial entity in its dependency graph. Usually as a direct dependency. Of course it varies how expensive it would be for me to replace that software. In some cases I'm sure I could find free alternatives, but it may not be as high quality, performant, correct or convenient to use. Which is another way of saying: it'd cost me more effort.
I can tell myself that I run my software on a free OS, but I know full well that much (if not most) of the heavy lifting on Linux was paid for by companies. Even in cases where the company isn't explicitly credited (as has been the case in several companies I've worked for that had people getting paid to contribute to the Linux kernel).
I'm sure I have written more trivial things in the past 5-6 years that has no external dependencies paid for by companies. Of course, if you ignore that the compiler, standard library, most of the toolchain and the IDE I use to write that software is all being developed by companies.
I bet that if you really were to look at what's between the pixels on your screen and the CPU, you'd probably find that most of the software you think of as written by individuals for free, results in code paths that spend a lot of time in code that was developed on some company's dime.
I'm also interested in what you mean by "most corporations take way more than they give back". Do you mean that monetizing free software is taking something away from free software?
As a thought experiment: imagine that no for-profit company were to use open source software at all. Do you see where I'm going? You do understand that there is a symbiotic relationship here, right?
What OS do you run? I'd like that, but the only thing of this sort that has potential to be as usable as a Linux system is BSD, which doesn't run on my machines.
I hope SerenityOS takes off. It's looking good so far.
It's still possible to ship cross-platform native software. People just pretend like it doesn't exist because it's too hard, and so I respond by pretending like their software doesn't exist.
If it's hard, people are not going to spend their attention on it unless deemed worthy. Like it or not, there is a class of IT-professionals who settled on the idea that macOS won the desktop-game, reasoning that Windows is and will remain trash, and that Linux can't deliver a comparable quality in UX. Someone who wants to focus on building a product can't dedicate the same amount of energy opting for cross-platform, and that's fair. You don't have to pretend their software doesn't exist - if you're not a mac-user, it literally doesn't exist for you, and that's okay.
Its funny that gaming industry has settled on the idea that Windows won the desktop-game, reasoning that Linux is and will remain trash, and that macOS can't deliver comparable performance.
This is not meant to show that some opinion is better just highlight that people have narrow tunnel vision on what is in front of them and tend to ignore other options without consideration.
> and that macOS can't deliver comparable performance
That's not the case at all. The problem is that, much like shipping native apps, supporting a second graphics API for Mac/Linux is a pain in the ass, so nobody does it. On MacOS, OpenGL is too slow for most modern titles and Metal is too high-level and doesn't have good language bindings. Same goes for why games run better on Linux than they do on MacOS; translating DirectX to Metal is simply too slow, even for the highest-end GPUs that Apple ships. An M1 Max will struggle to get 1050Ti-tier performance when running games through MoltenVK, and doing the same thing through OpenGL certainly doesn't improve the situation.
You just agreed with them. The M1 machines are plenty powerful, we all know that, but the OS doesn't give enough support for decent performance that even Linux can achieve.
You're making the assumption that everyone _wants_ to target as many platforms as possible, have the resources to do so, and are just too lazy to do so.
In other words, you're assuming that people don't build for your platform because they're "bad."
It’s a weird attitude. The desktop app community in particular has always had a pretty strong sub-community within it that’s coalesced around the idea of “we’re just going to focus on making the best Mac apps possible”. Which, even if you’re a staunch Windows user, seems fine? If you’re a developer who likes a platform and wants to build software for that platform, to you I’d say: go nuts. There are plenty of alternatives, and that’s particularly true in this space.
I can understand disappointment around great apps that don’t ever cross the platform threshold, totally, but I’ve never thought of that as terrible, or that the developers themselves are bad. This attitude of “you don’t like what I like so you’re just wasting my time” is super strange.
I totally understand your perspective, but I'm the opposite. I prefer native apps that utilize the great libraries provided by the OS and function in harmony with the OS (In my case, things like Scrivener, Kaleidoscope, Bear, Things, Alfred, etc.). I only fall back to using cross-platform apps if a native app isn't available, or if the cross-platform app is done really well (e.g., Logseq, VS Code, etc.).
I think it's a good thing that there are people who want to work to satisfy the desires of your niche as well as mine, so we can both be happy and productive.
For minimal compromise, you'd write it in Rust/C/C++ with a GUI toolkit that leverages the native stylesheet to render everything out. It'll be fast, it will run cross-platform, and it will take forever to build. However, this is the """right""" way to do it, and the one that people will complain least about. There's a number of tools that are distributed this way, but again, it's a pain.
For medium compromise, you'd probably end up with a runtime like Java or dotnet. These runtimes have well-established, long-running GUI projects that seek to tackle this exact issue, and for most people they balance ease of development, speed and "good enough" UI. It's not perfect, but a lot of one-man dev teams will end up choosing this when they want to get on every platform with a native-enough UI.
For maximum compromise, you can ship Electron with JS bindings to a native UI. This sucks. Please don't do this. It's an option though, and I'd be remiss if I didn't mention it. It's barely better than just putting a website in a desktop runtime, and if you aren't careful you can end up making it a whole lot worse.
It's definitely possible to do, though. If you want to charge money for your application, I should hope you're building a minimal-compromise program.
I don't think there is a single "correct" way. There are several non-C/C++ ways like Java, Electron, BeeWare, etc., but all of them tend to stand out when compared to native apps, regardless of what operating system you're using.
Shipping native platform binaries is the only reliable way to ship high quality software. Specially in 2022 with all the garbage floating around in virtual machines and "electron" bloatware.
Maybe I misunderstood the comment I was replying to.
I was replying about the "binaries" part. Binaries are always paltform specific.
The "only" part of "platform-only" - I can sympathize with. There are some tools I would like to try but I can't because they are windows only.
That said, it doesn't to me like any of the librarires/tools mentioned are good enough.
Qt is in C++ but from what I've heard its performance is abysmal - at least it's not good enough to justify writing something in Qt instead of html/js/css.
Xamarin I had to use one time and as far as I'm concerned, the DX is bad and the end result is also bad. Again, not good enough to justify using it instead of html/js/css.
Honestly curious, but of all the things I've heard people say about QT it could never be about poor performance, it's generally consistently regarded as the fastest complete GUI toolkit out. Even more so because the Linux desktop environment KDE is built in it and is consistently shown to be both the fastest and lowest memory of near all Linux desktop environments (and certainly among all the big ones), including ones designed to be fast and low memory. Where did this poor performance thing come from and am I missing something lately?
This is the first time I hear this compliment about KDE: being high performance and low memory usage. It's the exact opposite in my experience. The worst performance and most resource hungry desktop environment.
Though to be honest it's been more than 5 years since I tried, so things might have changed since then ... but I really doubt it.
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.
And it'd be nice to get notified if: It starts working on Linux, and it becomes open source or source-available. (Having to pay for it is fine :-) of course)
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?
One has a choice between learning enough about Vim to replicate arbitrary workflows/functionality in it, or using other softwares that do those things out of the box and clicking the "Vim mode" check box in the settings.
Both are perfectly valid, but they are going to appeal to different kinds of people, with different priorities.
I think there is a difference between features of the editor and editing method. Following your logic - if there is already Notepad, why create TextPad, Atom, Word, VSCode etc...
I'm a heavy user of JetBrains IDEs for most of my development work and use it with the excellent IdeaVIM plugin because modal editing is my preferred input method.
I have all the goodies and features of the full IDE with the keybindings and modal editing muscle memory I've built up over the last 15 years.
Technically I can get Vim to do most of what JetBrains does but that's a very very big hill to climb.
vim is not an IDE. You can make it IDE-like with plugins and integrating third-party tools (e.g. for completion, refactoring, debugging), but it is still not one. You may not care, but come on, it's not that hard to understand.
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
From a purely macOS perspective, the major issue (apart from JSON being slow in Swift) was that there's no good native editor control for source code. There's NSTextView but it doesn't scale to large, syntax highlighted documents and lacks the required facilities that a source code editor needs. Hence, all proper third party text editors for macOS write their own source code control. I, personally, would contest that a native GUI is very much possible, but only for the chrome of the editor (e.g. searching, menus). This is also where native GUIS can shine. I'd wager that a proper source code control is such a domain specific requirement that each cross platform editor has to implement them whether they use native UI or not (maybe Qt has a fantastic one, I don't know)
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.
Thought experiment: Rust half gets open-sourced and semi-stable-API-ified... and then out of several dozen community attempts to build a Linux UI, one of them eventually wins after 5 years :) (and a couple of stragglers build up small followings besides).
Realistically speaking, Linux (and Rust) UI is sufficiently incoherent at this point (heh shakes head "year of the desktop" for 3 decades at this point huh) I honestly don't think anything except "here's the code" would work because of the huge amount of keeping-up (unfortunately :/) necessary at this point.
look at xi editor, it doesn't "really" work out even if it's not a technical one but a human one. It's just too much work to maintain 3-4 GUI applications which have to be in sync with a server api.
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.
If the target is to be platform specific, then reducing the amount of compiler toolchains, IDE/editor plugins, and language knowledge required across team members is a good thing.
If the purpose is to go cross platform, then it is another matter.
Then again this is a matter of opinion, feel free to disagree, I am not here to change your mind.
They mentioned elsewhere it started off as a fork of the Xi editor which is written in Rust. Xi separates the text-editor idea into backend and frontend, and Xi itself is primarily the Rust-based backend which concerns itself with making editing operations very fast, and then you can write a front-end client for whatever language/platform you want.
In this case, they can use a fast Rust backend for multiple platforms (or just one) and then use Swift to make a nice, native front-end for MacOS and other native UI languages for other platforms if they wish.
Which is why I made the point on my comment about what the cross platform goals were, but the RIR folks are too quick to jump the gun in any kind of critic and only read half of it.
Cross platform future aside, they want to use all the good libs Rust has for ropes and the like. The code is based on another editor earlier work, and that's in Rust.
They also know Rust so if they want to use Rust, what's the problem in using it? They don't seem to have any problem with building a UI on top, it's built and looks/works fine.
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?
There’s no email or anywhere to fill it in the first place during/after purchase, just a screen with the license code. An invoice or purchase confirmation mail would have been nice… I do hope there’s a way to retrieve the license for clumsy people like me. :)
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.
By contrast, I thought it's really well presented. It is a permanent license, only the patches are stopping after a year. I was even hoping by myself they have the good sense to offer optional auto-renewal.
The larger picture is, selling software somehow is always awkward. Given that, these folks have hit a near optimum, imo. And it's better to pay for a good tool than to find a good tool only to see the vendor go out of business. And that has happened plenty of times.
The adobe suite is bloated, slow, overly complex... There is a very strong niche for a suite or single tools that have better design, performance, integration and UX.
Jetbrains dev tools are highly praised just on their own and they have a strong plugin ecosystem (see: Cursive for Clojure).
Also these kind of developer tools have to indirectly compete with highly extensible and well established open source alternatives such as Vim, Emacs, VSCode who all have their unique strengths and support tons of languages.
Yeah good point, but I wonder if their products have a larger market and the price point is about double what this is going for. I also noticed they have an add-ons store, not sure if they take a cut there too?
> 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.
> my rust/LSP experience with Emacs doesn't hold 5 seconds in front of what I've just seen on the Zas website
My preferred way of working after 20+ years in the industry, is finding the "best tool" for the job.
Vim is my "goto" editor for everything that doesn't have a better tool, but any perceived performance gain from being familiar with an editor needs to be compared to the performance gains of using the specialized tool.
I.e. Writing Azure Functions, VS Code / Visual Studio makes this dead simple with integrated local Azure Storage emulation and more. It can be done in other editors, but i'd spend a lot of time on tooling instead of just writing code.
I guess i've just gotten more pragmatic with time :)
My 35+ years experience (ah ah!) tells me that emacs is the best :-)
Just kidding... I code small stuff nowadays, so emacs is just fine. But if I had to get into something big, I'd certainly use a tool with powerful and fast code navigation, and something that works out of the box. LSP mode on emacs is not easy to set up. I mean, you can get it 90% working in 15 minutes, sure, but then come the little things such as: you're waiting for your LSP server to start, pop up windows actually don't pop up, the LSP hints don't update themselves unless you save your file, sometimes they take 3+ seconds for update (an eternity when you type code), I still don't know how to jump from a stack trace to the code, etc. So yep, refactoring is there, navigation is there, much is there but it's not super tightly packaged...
But for other things, emacs is just cool. Small python scripts, R code, org mode, git stuff,...
Org mode was my main "excuse" for keeping Emacs around, but these days i've more or less given up using it due to lack of decent mobile clients.
Instead i've more or less settled on Obsidian for my notes, which does 99% of what i used org-mode for, and i use other tools for the last 1%. The only thing i'm missing is a good (integrated) solution for task and time tracking/reporting.
I'm aware that PlainOrg (https://plainorg.com/) exists, but i've already moved my notetaking workflow to Obsidian, and i'm deeply entrenched in modules with that, so moving now would probably not accomplish much.
I think it depends on the language server - metals for Scala, jdtls for Java, pyright for python,jstls for Javascript/Typescript and omnisharp-roslyn for c# are all pretty good. Cold startup time for lsp servers in bigger languages (scala/java/c#) are akin to IntelliJ/Rider import times.
I don't have all the same refactorings as intellij, but then I don't have to pay a license to edit c# code, either. Most people that I watch use IntelliJ don't use it to its fullest extent. I will open it to pair with other IntelliJ users. But I'm faster in emacs. I've also used it professionally for almost twenty years. To get me to switch an ide would have to be as extensible, keyboard centric, cheap (both free and in terms of memory usage), and portable (across platforms and languages) as emacs has been.
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.
For any software that has anything resembling DRM, which is a vast majority of software, once the company goes out of business, there’s no way to activate it. (Unless they address the conundrum before taking down the activation servers, of course.)
This isn’t really a downside of the licensing scheme itself, though. If it was DRM free and on the honor system, it would not have this drawback.
Of course, it’s currently unclear if a software development tool can remain relevant for many years after it is effectively unmaintained, so maybe this isn’t that interesting of a question.
On the other hand, no DRM is immune to being cracked.
> Of course, it’s currently unclear if a software development tool can remain relevant for many years after it is effectively unmaintained, so maybe this isn’t that interesting of a question.
I wonder if there has ever been a company that pledged to release the source code of their software in the case of bankruptcy, e.g. as part of the purchase/license agreement so that if the company is bought in a bankruptcy auction, the new owners can't change their minds.
Although I guess in that case, the incentive to pirate the software goes up lol
Best case scenario, all users get a license to the current version. Worst case scenario, they get a license to whatever version was released a year prior.
I recommend companies add a clause to their licenses that if they go out of business or get acquired with the consequence that the product line gets discontinued, the product becomes open source automatically.
That also takes out a lot of risk for bigger companies doing business with startups.
The end user doesn't have the copyright to the source therefore they are unable to relicense it. The only person that can make it open source is the acquiring company. The acquiring company might not have signed the EULA, or they could just negotiate an amendment with their new acquiree that removes the clause.
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.
The editor looks really nice! And the price tag is absolutely fine for what it promises.
But, with 30 years experience in software development, I won't even look into primary development tools that are not cross platform. I am mainly on Linux, often on Windows (usually because clients force me) and sometimes on Mac (for iOS development and cross platform testing). I want the same toolset no matter the hardware or OS.
> I am mainly on Linux, often on Windows (usually because clients force me) and sometimes on Mac (for iOS development and cross platform testing). I want the same toolset no matter the hardware or OS.
Just came to the comments to say exactly the same. If I can't use a tool I'm supposed to use daily, on the three main platforms me (and others) are stuck with, then I can't justify to use it at all, unless it's forced on me (hello xcode et al).
Comparison is missing editors that would compete with this. VS Code is huge and slow, but somehow people use it and love the extensibility and broad support. Goland is just a beast that does so much more it's not even in the same league.
What would make sense in the comparison chart is something like ST3.
VSCode opens within about 2 seconds on my machine which for me is fast. For some users they want it to open even faster than that so something like vim makes sense.
Visual studio 2019 on the other hand takes about a minute to a large project and with resharper even longer.
When I think about a fast editor I think about opening a 2GB log file and looking for some text, or editing a multi-megabyte Markdown file with syntax highlighting on without any slowdown (something my NeoVim currently struggles with).
I just opened a 4GB JSON file in VScode, it took a few seconds to load, but it is fast enough for me. Syntax highlighting disabled itself, but searching text works.
What you say just underlines my point from above. People who are happy with performance of VS Code are not looking at performance graphs in a new editor. And those who seek performance are probably not using VS Code anyway.
PS:
> macbook pro m1
People were able to run IDEs and code editors 20 years ago. My 5 year old MB Pro is struggling with VS code. Not anything smart either, just UI, syntax highlighting, ... So while "good enough for me" is absolutely valid position, VS Code is objectively slow.
Hey. I'm an Editor/IDE aficionado.
This could be the start of a really nice macOS native editor.
Panics Nova is nice but it is lacking good Go support.
However there are many things to get right.
These things are needed in order to get competitive imho:
- Plugin API
- Plugin Marketplace
- Proper LSP (you seem to have that already)
- DAP Support (you stated you are working on it. Good!)
- Out of the box support for go-templates, css, js and html.
You already have a very good foundation from what I see! Keep it up. I'll buy I license just to see where this is going :)
On the plugin API, meh. I've spent a lot of time making Vim work for me over the years, adding all sort of plugins etc. Would that time have been better spent using something that was complete & worked already?
The answer is technically no, because I've used more than two languages in that time, more like 25 different dev environments I needed my editor to cater to. If you're only using one language, this is great. Everyone has better things to do than the meta-work of making a dev environment. For most people the dev environment is noise that gets them no closer to actually achieving something. Not having a plugin API means it's impossible to waste your time on that.
If this is a yearly subscription, and you can request features / improvements, then you should think of it as "I've got a guy (girl/etc) in Canada who handles my dev environment for me".
Praise to all IDEs (or any app really) that manages to bring a good offering across platforms, instead of just tailoring to macOS (or Windows for that matter). But I'll sit here and take my downvotes now :-)
There has been a resurgence of native editors these days (Helix, Nova, …).
Every time I rush to check if there are vim keybindings. It's a dealbreaker otherwise!
It's especially interesting because thanks to Neovim, implementing vim mode should be more or less trivial -- Neovim has a server mode where you send it keystrokes and it sends you back buffer edits and/or UI to display. And since it's real vim you get to keep all your vim config, plugins etc in your IDE. I'm surprised I haven't seen it really take off yet.
If the VSCode Neovim extension is anything to go by, this does result in a considerably improved UX versus the usual Vim-key approximation. In addition to your Vim config, it plays surprisingly nicely with all other VSCode editor features, so you can basically work both ways at once.
I believe Nova added support for vim keybindings recently. We're going to add vim keybindings soon. In fact, we're starting to regret not implementing the functionality for this release!
Helix - or rather Kakoune† - has better-than-Vim keybindings though, in my view. It's what Vim keybindings would be if they were built from the ground up, without decades of cruft and bolted on bits, and instead had a coherent design to them that was easy to make sense of and intuit. Vim has that with its command grammar, a neat way of combining smaller comands into larger ones, but not with the individual command keybindings themselves.
† I'm still not sure what the difference between the two is, except that the Kakoune dev had to take a year-long break because of having a newborn child, and Helix development continued in that time.
I've tried Helix few days ago and was more than impressed – almost everything you want from code editor is there out of the box, and transition from neovim was super fast. The only thing the holds me from switching completely is lack of Copilot.
But yes, there seem to be a momentum of rethinking editors and frustration with popularity of a slow and heavy editors.
I am an Apple MacBook user. However, personally I try to use only software that is available for Windows, macOS and Linux. This allows me to switch operating systems more quickly, should I choose to do so. Don't want to make myself dependent on one manufacturer.
As a counterpoint, I only exclusively work on macOS and vastly prefer native interfaces over Electron apps, which is what the majority of cross platform applications use.
Valid point. I know it's easier for the developers to support only one or two platforms, but I see full support of all major platforms as a sign of maturity.
If it doesn't, it's a sign of issues either with used libraries, programming language or tools.
Looks great. One thing I recommend is defining a smaller width for the content on the landing page so it doesn't take up the whole screen. Otherwise, it takes a lot of effort to read left-to-right.
This looks pretty great, but I'm through paying for commercial programming tools that aren't portable to everything I might be developing on. Right now I'm developing on a Mac for work, but in a year that might be different, and the time and money I put into this editor will be wasted.
The time isn’t wasted if you got good code out of it, and it’s $25. That’s like two trips to McDonalds these days. I paid more than that for the concessions at the movie I saw tonight.
Congrats on launching, the screenshots look great.
Lately I've seen a few MacOS specific apps here on HN (another one was the terminal app ) and they all look really good UI wise: the general UI, popup/search dialogs, dropdown menus for command palette, file trees etc.
I would love to write apps that look and feel like this on other platforms (mainly Linux for me personally) but the toolkits don't seem to have that level of polish or even lack most of these controls/components. Gtk, Qt and Java Swing all have pretty simple controls and require a lot of customization or reinventing the same custom controls.
The closest I have gotten is with JavaFX but that does not seem officially supported/maintained anymore. Are there any other toolkits that aim to have this level of polish?
As a an aside: I wonder if we are hitting a local maximum in terms of programming languages/ecosystems. These days if you want to experiment with some truly novel programming concept (see for instance Unison, Dark, Luna), you have to compete with truly excellent IDEs, Git, excellent code hosting like GitHub, large open source package ecosystems, high quality linters and auto formatters, and other niceties.
So if your language/ecosystem can't take advantage of those things (for instance not being traditionally text based), you have a huge cost before you can meaningfully demonstrate any superiority. To do that you probably need dozens of people working for several years, and I don't think the economics are there for it.
Looks promising. Price is very reasonable. Now trying it out. Unless I find a major issue I'm very likely to buy it.
Is there any chance of supporting other languages? I'm asking because I'm one of the (probably few?) people who would be happy if Odin was added to the list of supported languages. (It should be easy to parse, even has library support for parsing and extracting docs).
What great turn of events, thank you for reconsidering! You have my money. :)
——-
Old post (now incorrect):
> Can I use one license on two computers?
> No. It sucks, but that is the only way to prevent abuse.
The editor looks great, but this sucks to the extent that this won't work for me at all, unfortunately. Parallels' old-school licensing theme meant I'm dropping them as well. This is not about the value of the product or the price itself, $25 seems more than fair if this meets my needs, regardless of open-source alternatives.
I, and I suspect many others, develop on multiple computers, sometimes on a single day. If you worry about "enterprise abuse", perhaps consider a commercial license. Or add a higher priced tier that is per user, not per device. I think (i.e I don't actually know) there's a reason editors such as Sublime Text have per-user licenses (to be fair its price tag is also four times that of Zas Editor).
Are people actually abusing per-user, "honor" licenses that much nowadays? And here I'm thinking about difficult-to-verify customers who are willing to pay in the first place.
I think it would be better if they add an edit to the beginning of the comment. The transparency of your reply and admission of a mistake is actually a very good signal to many of us. I trust people who own their mistakes.
This just shows how important first impression is, and how difficult it is to rebuild trust after that. Asking people to delete their comments/reviews is not a good approach.
You can't expect everyone to have perfect judgement on the first go. They admitted a mistake openly, and they're simply asking for that to be reflected in a top comment. Otherwise what's the point of admitting a mistake if few people notice it's been amended?
I’m not saying not to admit a mistake. I’m saying that such a trivial mistake should not have happened in the first place. Who’d have known that people might have several Macs and would want to use a code editor on several of them?
Looks slick and well built. I would really like to try.
However, there is no info about the team, company, etc. Even social accounts are brand new. To install a closed source binary with no provenance info is a bit harsh, the only way I could test would be on an offline spare Mac.
Is any data collected?
Given that it started out as a fork of xi-editor, I think you should consider switching to an open source + subscription business model: You may get a much larger userbase (as again you seem to have built a great product), you'd gain trust even if you prefer to remain anons, and you can bundle additional services (e.g. sync the configuration between multiple devices through iCloud can be a paid subscription-only service, additional themes, binding of Apple latest kits etc.).
With tiny bits of added value, many would be able to pay $20/y for convenience and you may end up with more revenue. Also, you may use the App Store to charge for the subscription, it is easier for many of us with payment info already in.
No data is collected other than the serial number of your Mac for making sure you can only use your license on one computer, which we realized was a bad idea, and made changes.
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. We were expecting few downloads and more technical feedback.
>With tiny bits of added value, many would be able to pay $20/y for convenience and you may end up with more revenue.
If you look at the landscape of editors, it's pretty much split between FOSS or Paid and closed source. I wouldn't recommend this route; OP would simple end up supporting a bunch of people who would never pay for this app. Going FOSS for a code editor only makes sense if you are already working for a huge tech company.
Hi, in the current and only version, your Mac’s serial number is collected, which used to be used to ensure one license can be used on only one computer (this is not the case anymore).
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. We were expecting few downloads and more technical feedback.
> Zas Editor reparses your code on every keystroke without compromising performance. Having a maintained AST at all times brings many intelligent features to the editor.
How does this work in the presence of syntax errors? 95% of the time you're writing code, your code is syntactically invalid, because you've started some new construct but not finished it yet, so you need syntax highlighting, code completion, etc to work sensibly in that situation. Getting that wrong is what killed RLS, IIRC.
I just tried the editor for Rust and it is great.
I love the way errors and warnings are displayed.
The navigation mode is also a brilliant idea.
For larger files however, the screen real estate used by the navigation on the right hand side is not quite big enough for me. You still have to scroll a lot and hunt for what you want to find.
It would be great to somehow display more things to navigate, possibly using more of the screen (especially if you're using a big external monitor), possibly with some visual of the dependencies between them (so that you're not trying to find things in a long linear list). Especially when you're browsing new code the dependencies would be very helpful to get a quicker understanding of the structure of the code, and for your own code they might also suggest ways to refactor/reorder code in the file.
I'll definitely try out this editor for the next couple of days, and maybe switch from VS code. I find the comments of the people saying that they won't pay for an editor quite strange. I would gladly pay $24.99 per year for a 1% productivity improvement.
This is simply bad user experience. A person who uses Windows may be confused but they can only be sure after reaching the bottom of the page. Not to mention it is not rare that a multi-platform application use Mac screenshots, including (surprisingly) VSCode, from time to time
I'm pretty sure there is a huge group of jetbrains customers who like tight, fast executables and would switch to this editor if it had a working auto import and type checking/autocomplete feature for Python. At least an attempt at autocomplete for js would be a bonus.
Looks very nice, and the price point looks perfect. Of course I only use open source software, so I take this as a challenge to reimplement these features in emacs.
From the domain name I confused this with the Zed editor[0] for a second. Despite both being editors written in Rust with zed* domain names, they are different. Really interested in both projects though.
Automatic renaming is amazing. Such slight reductions in friction make a big difference. I can already tell I would be much more likely to refactor often with such a feature.
Unfortunately, I don't have a Mac at the moment. Are there any other editors with such a feature, or is it unique to Zas?
With web development being as prevalent as it is nowadays, is there any plan to support HTML, CSS, JS/TS? Go and Rust are often used for web backends, so it would make sense to support frontend languages as well. Especially since Rust can be compiled to WASM.
I really like what I see there. There is certainly a lot room above VS Code and Jetbrains IDEs.
- Both VS Code and Jetbrains IDEs have issues handling large files
- Both have only good not great usability. Jetbrains IDEs are actually very good but the huge feature set is becoming a problem even if you don't use all the stuff
- Both have their problems with with code intelligence. Jetbrains IDEs are mostly flawless but esp. Webstorm lags heavily regarding the support of some JS frameworks, e.g. Svelte, Vue 3 SFC and Tailwind CSS. The support is also going downhill with Jetbrains.
The price of 25$ is a no brainer. Totally fine for a good product.
Mac only is very unfortunately a dealbreaker for me as Linux user.
A lot of this is possible in Xcode, but kudos to the team for packaging everything so nicely in this editor, and there are a few standout features I haven’t seen in other editors/IDEs:
- multifind
- find in all enums (declaration/structure-specific search)
- the “minimap”
Like another poster said, just the few niche functions alone would be a cool acquisition target for Apple. I’d love to see the best/unique parts of this make it into Xcode without having to maintain the rest of the wheels that have been reinvented here.
I guess you kinda have to reinvent all those wheels as a foundation upon which to build new unique features for a text editor though…
This looks really nice, especially the smart refactoring features and built in documentation search... but a Mac-only app disqualifies it for me. I need an editor that I can rely on no matter what OS I'm on. That's a bigger deal today than it was a decade ago. Having to switch my tools when I need to use a different OS is a massive productivity drain.
This is clearly a very niche product, being Mac-only and targeted at Rust/Go devs. I wish you luck with it though, because the world definitely needs more people making and innovating code editors (even if they're not all for me).
As a side note, I really like the design of this landing page. Instead of a "hero unit" with a salesy blob text in marketeese, there's a useful description of what the product is, what it does, and what value it adds to the end user, in a way that the user immediately understands.
Each feature description is accompanied by a picture/animation to demonstrate it.
I wish more product marketing pages followed this format, instead of the crappy soulless format of "hero unit" with marketing blob followed by three text boxes in a row with more marketing bullshit.
Website looks sketchy, zero information on who is actually behind this project or what kinds of data are collected. Also, without proper plugin support (LSP!) I can’t see this going anywhere.
Looks similar to Code Edit [1], an open source editor for macOS that’s currently in development.
Won't it, though? People use JetBrains IDEs all the time as opposed to things with tons of plugins. It sounds like that's the style they're going for, just a little lest slow and bloated, based on their website.
Congratulations. Zas looks very cool, I will definitely try it out and see if it can fill the (large) gap between Visual Studio Code and a full-featured IDE like Goland or CLion for me.
Can you please give an outlook in which direction you plan to go with Zas Editor in the future? Is the plan to target only a few specific programming languages, like currently Golang and Rust, or do you want to become a generic code editor like Visual Studio Code or Sublime Text and support a large number of languages and formats?
I don't see myself switching from VSCode any time soon. The plug in system is just too amazing, too vast. I understand how hard it would be to create something competitive.
Yeah, I've used it for a decade or more to run snippets. But I don't consider it an editor - more of a scratchpad, nor that it has any particular Python support to write home about.
Sorry to hear that. At the moment only Go and Rust are supported. We are currently working on plugins. What did you think about the Rust & Go support? Would you use it for Python if we add support?
I would almost certainly buy it if it had Python support. I code in SublimeText all day, and sometimes want another project open in something I can command+tab to, so I've got several secondary editors, none of which I particularly like. I despise VSCode because it feels like Windows XP, Nova has some quirks that I just can't get past, TextMate is currently my preferred secondary, but it's so far behind everything else. I really like the look of the minimap on Zas, very clever.
We are using LSP under the hood, but you can't add more language servers yourself. AS for DAP, a debugger would be a huge feature to implement, we wanted to get it right before releasing it.
Interesting! Do you have any plans to open support for LSPs? I do see the appeal to having a totally curated list of LSPs you don't have to worry about, but if someone buys into this editor, it might be nice to be able to extend it with new language support in the future so you don't have to switch editors for different languages.
This looks great. Please consider adding support for Ruby. I know some of the smart features will not be possible/difficult in Ruby but if you can add some smarts around Rails support, you might attract a decent chunk of developers. Also almost all Rails development happens on Mac.
Edit:
The trial should ideally be 1 month. It takes a while to put the editor through its paces.
Also support for running a command outside the editor (for example auto-formatting / linting) is essential
Better yet, the trial should only count down when the app is being used. It will be long expired before the features we are waiting for before purchasing get implemented.
Looks like a good start. I need VIM-mode to be able to use it as a daily driver.
The ordering of files and directories is a bit chaotic compared to VSCode. I get a "Go is not installed" popup every time I click a .go file which is weird since it's installed and available for the terminal opened in the editor. I would love more language support as well, Elixir would've been awesome.
This looks amazing. I'm definitely the target market for this - I shelled out for Nova, and I'm always on the lookout for fast and well made macOS editors. The Rust/Go-only thing is an unfortunate dealbreaker, as much as I like Rust, I don't use it enough to justify paying a separate fee for it. But if this got more languages I'm all up.
"Zas Editor has search and navigation features VSCode does not have"
Im sure vscode has more options than Zas. Personally i need: move last open tab to left, vi-mode and sequence keybindings with context. Other than that i need my settings/extensions to be synced across devices. Does Zas have these?
I'd check it myself, but it's mac only and im on Linux. There is no info if this will change or not. FAQ should give more info.
Other than that, i dont like editors that are language specific. I dont want to use a different editor for each language. It says it supports go & rust. But what if you are making a http server that serves some basic HTML files? It would be kinda annoying if it didnt support html/css/js indenting or syntax errors.
I would agree that vscode is kinda slow. Although it's fast enough for me. It seems faster than a couple of years ago. Still, i dont like my apps being written in electron. It's a waste of memory, CPU and electricity. So that's a win for Zas if they dont use electron.. What are they using? Would be nice to know.
I like the bussiness model. But it just cannot compete with vscode. I think could have. And it would have been the smart choice.
>Native. Fast. Lightweight. Zas Editor was specifically developed for macOS. That enables it to be more performant, have a significantly lower memory usage, and have faster startup times than non-native apps.
- Showing type of the variable when you hover. Goland does it perfectly.
- Being able to add mouse actions to shortcuts. A use case would be cmd+mousewheel to increase/decrease font size
- Importing themes from GoLand.
Really liking this editor! It's incredibly performant on Apple silicon for Go development. I'm not sure it is mature and feature-complete enough to take on Goland, but for a v1 release it looks promising.
I see only a download for mac, I am on Linux.
My current setup is actually ok, use vim and sometimes vscode.
24 usd isn't that expensive but what would I get that vim doesn't do?
Wow that sounds like a really interesting editor for Golang! Only missing thing I absolutely need is the debugger+a test runner. Once those are here I think I'll buy a license!
Does this have Vim key bindings? Can't find it anywhere on the landing page. I am very reluctant to give up my Neovim + Kitty setup. Most editors I have used consume a lot of RAM and end up becoming slow on big projects (especially when used in conjunction with LSPs). Operations aren't as smooth as I would like them to be. I have used Vim bindings with VSCode and even though it is manageable it still has a lot of quirks and performance issues that put me off. Eventually moved to Neovim and have never looked back. But if I get a better experience with Zas Editor (no compromise on performance though) I would definitely switch.
Curious, what is your rationale behind having a 7 day trial? The time a customers invests to dive into and get attached to your product seems like best predictor for a future sale.
Hit and a miss. Looked good till goto osx only. Never-ending those who have osx sure it be a potentially good solution. Back to vscode or sublime-text for me
Not that I am against paid software, but the added value is bound to a single platform. It must provide a lot of 'functionality' and specifics to make it worthy. Especially is it is just an editor with the idea to become an IDE, which will likely impact performance over time. I am merely guessing here. But since performance is a major selling point, I wonder how this will be in the future. Note: I am NOT a mac user anymore. Still use sublime for time to time, but fully moved to VScode. If I look for speed or search functionality, I would use vi again. At the moment I care more about the presentation, refactoring and navigation. The extensions of vscode make this experience for me more powerful; remote ssh, marked mindmap, markdown rendering, etc plus it can run on a remote host and be accessible from a browser. Accessibility and the same experience across platforms are key to me.
Success with the editor. It does look promising! but not for me.
@dang our post was marked as [dup]. The title is too ambiguous. Can we update it to 'Zas Editor: Capable, Fast and Native CodeEditor Designed for Reading and Writing'.
Looks like two submissions were merged, if you want to reach the mods email them, though, summoning dang is not reliable. On the other hand the current simple title is a lot better than the old florid one that reads too much like an ad so you're probably fine as is.
I have the same licensing model in Lunar (https://lunar.fyi/)
You buy the app as is now, and you get to keep this version of the app forever. Just like you would buy any other good.
On top of that, you also get 1 year of free updates, and you get to keep using those new versions forever as well.
How is this a subscription?
Why should the developer work forever for you on a meager $25 payment?
Software is not a "good". If you bought "go ide" a year+ ago and your updates ran out, you can throw it away now.
> On top of that, you also get 1 year of free updates
They are not free, you subscribed to them by paying the subscription. What is free is the copy of the software after your subscription ends.
> How is this a subscription?
It's a subscription because the product you buy is supported for one year.
> Why should the developer work forever for you on a meager $25 payment?
This is irrelevant to the topic at hand.
FWIW, I think it's a good model, for both user and the developer, but I would not try to pretend it's not a subscription with a big bold text. Just avoid the word and all is good.
I'm well aware of that. But I'm also aware that human time is expensive, and paying $25 shouldn't entitle you to someone's time indefinitely. This model is just one of the ways of ensuring that the developer has a constant flow of money so they can keep working on the tool.
Even with this model, I'm already looking for jobs, because I don't get enough money for the 14-hour days I have to put in to keep up with hardware changes.
An editor is far easier to keep using after the 1-year period has ended, especially if it has support for plugins which should update for free.
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.