Mentioning that it’s Mac only, and that it’s not free software, would help keep plenty of people from wasting their time.

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.

How about compatibility with VS code extensions?

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.

HN is a circle jerk.

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.

Thank you, I didn’t feel like bothering.

I don't mind that I have to pay for it. I do mind that it's not free software.

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.

Thank you - not sure about others, but I'd probably waste some time if not for your comment.

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 :(

Thanks for the warning!

It's 2022 and still shipping [insert platform here]-only binaries?

If you want performance, then yes. Shoo! Go back to Electron!

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

Why so cynical?

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.

What's the correct way to ship cross platform native software that doesn't require me to write it in C or C++?

Depends on how much compromise you want.

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.

There are Go and Python bindings for Qt. Also Rust has now an early support for it

On my laptop, in a VM even, VSCode is fast, hasn't been an issue. I'm surprised "everyone" complains

(But VSCode's search functionality is annoying! Here Zas looks lovely ... But, Mac, so, no)

Electron isn't the only cross platform solution. It is just the most expensive one.

Is this a serious comment?

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.

Ever heard of Qt, Xamarin, WxWidgets or FLTK?

Electron isn't the only game in the house.

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)

Are you planning to add support for other languages in future, or are those two your main focus?

This made it very clear to me that I shouldn’t get too enthusiastic yet ;) so I was spared the inevitable dissapointment. Thanks for that update!

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:

https://github.com/onivim/libvim

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?

Thanks for the hint. You can follow us on Twitter @ZasEditor for update announcements.

Seconding that VIM bindings are a requirement for me for what looks like an otherwise amazing editor.

the curse of vim.

Once you've learn vim keybinds and combinations, nothing comes close for productivity.

Once you've learned vim why do you care if any other editor has vim bindings? What can you do with vim-mode ZasEditor that you couldn't do in vim?

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.

* pairing/mobing with people who are more familiar with their IDE

* Believe it or not, there are things no vim plugin can do, for example rendering mardown, which Viscose has lots of plugins for that work well

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.

For the rope, are you using xi-rope, ropey, or did you roll your own? Any thoughts on how you made that decision?

Glad to see stuff like this, it brings back memories.

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

What do you think of the "no such thing as native GUI" section of the xi retrospective [1], particularly the surprisingly bad performance?

[1]: https://raphlinus.github.io/xi/2020/06/27/xi-retrospective.h...

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.

Hi! This looks really cool, great work! It seems to be Mac-only for now, is Linux support on your roadmap at all?

As it is written in Swift, I highly doubt linux support is in their roadmap.

The more complex half is written in Rust. But you’re right, making it available for Linux isn’t something we plan to do soon

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.

If the plan is to make a native UI for each platform, good approach.

If it is to stay macOS only, also a possible decision not everything needs to be cross platform, why bring Rust into the picture?

Why would they not?

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.

Depends on the purpose, as I mention.

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.

Why would support for Rust be a problem here?

Two language development stack, with the complexity it entails, when the product is mac only.

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.

But you're making the exact opposite mistake, it was already written in Rust, you're asking them to Rewrite in Swift.

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.

No problem, hence why I wanted to know why. Maybe I should have read the post better.

Elsewhere in the thread[0], the author claims that Zas Editor started out as a fork of Xi Editor, which was written in Rust.

[0] https://news.ycombinator.com/item?id=30953143

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.

To compete with VS Code and GoLand/CLion this is essential.

Can't you add some sort of impressum to the website where you give some information about you?

Added my info on the contact page

Could you also include a privacy policy and more information about telemetry or data collection?

Working on it.

Thank you. Didn't try out yet (need vim) but it looks very nicely done, bravo!

One typo: "dependancies" -> "dependencies"

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.

And after purchasing, there is no invoice.

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

How do I extend it etc and what’s the extension language?

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.

Any changes it will support more languages? I would love to use this for Kotlin.

+1 For Kotlin, Swift would be nice too.

Really cool project!

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.

Hi, the image in “Simplicity of Command Line + Expressivity of Graphical UIs.” section is not cropped leading to horizontal scroll on mobile.

It's great to see more Go editors out there. All the best! A little feedback: it's spelled GoLand, not Goland.

How do you create a new file from Zas? seems like you can only open existing files

"Right click -> New file" in the sidebar

> since we wanted to create a native macOS experience.

Can you say more about this choice?

Do you mean why we chose to make it native instead of making it cross-platform?

Yes.

I really like that it’s a one time price. Thanks for your work!

What editor were you using in the past? emacs, vim, vs?

How long did it take you to build it?

"Why should I use Zas Editor instead of free XXXX?". I don't know, I have no Mac.

Super cool product!!

looks wonderful!