It seems it was originally a Go-only editor when it came out five years ago (looking through their blog posts). Ruby was only added earlier this year, and now this supports more languages. So yes, weird to describe it as a Go Editor still, but it would have been accurate before May.

I did ponder whether to not mention Go in the title, but I had noticed that it's unclear what the devs mean by "support for 23 languages". Go is known to have been their main focus. In general, there is no documentation whatsoever, although the editor is interesting.

For me, the lack of those features is itself a feature.

I don't have any interest in using the subpar terminals/"execute this thing" buttons included in many editors. I'd rather use a terminal that I actually like -- the one I use for everything else.

I also don't want any "magic" to happen under the hood to run a thing (looking at you, Java IDEs). I want anyone to be able to download the thing I'm working on and run it without being tied to a particular editor/IDE, and the best way to do that is to put your build/run stuff into something portable (shell script, Makefile, task file, whatever) instead of relying on a button in a GUI somewhere.

I like having my terminal attached to my editor, but I don't like it integrated with the editor. Some of the integration features are cool, like clicking to view a file in the editor straight from an error message, but I always get frustrated with the integrated terminal's small size, and it's not convenient to resize it. Or it can slow down the editor when a lot of output is happening (VS Code). Sometimes it's a third-party solution that isn't well maintained (Atom, Sublime Text).

Ideally, I'd love a way to glue sets of windows together and move them around as one piece, without being a tiling window manager.

> The lack of integrated terminal or method of running a go program makes me question what use this is to someone.

I'm quite happy with my current editor and probably wouldn't use this, but I have also never used either of those features. I run my code using a separate terminal in a separate window, and can't really understand why anyone likes squashing their terminal into the same space as their code (although I recognise that they do, and I'm glad that they can if that's what they want) - seems like it would be distracting and reduce the amount of code you can get on screen at once.

Honestly, dropping v11 for 2.0 was a really tough call. Adopting ExtensionKit, and getting that out the door right when v13 shipped was difficult, but that was the goal we set out for. Supporting v11 made a number of things more difficult, and SwiftUI was some of it. It was not strictly technically necessary, but it made it easier.

As a paying customer of both, I can tell you that at this time and for the time being, it's not better, and it's, indeed, worse, and feels slower regardless of being a native app!

I'm truly sorry to hear that you are disappointed. And I really do get it! The full story is long, but I can sum it up with: our number one request, by far, is support for more languages. Even since this release, we've still gotten requests for yet more not yet available.

The hope is that an open source extension system will make it much easier to add new languages and improve support for existing ones.

But, I also want to be really clear: if you aren't happy, contact us and we'll try to make it right. If you are willing, I'd also love to hear from you about problems and/or missing features. We prioritize requests from license holders over all others.

I'm sorry it's working so poorly for you. 2.0 has some performance issues that do make it seem more like slow-open in a number of situations. We're working on it.

out of curiosity: still using atom or vscode or switched to something else?

You did not. Aside from Rust and Swift, all the added languages are preliminary. A minimal extension is required to, for example, connect Chime up to an LSP server to get semantic features going like completions and diagnostics. We do not have a 1st-party extension built for C# yet.