Live data from Hacker News

Chime 2.0 – a Go Editor for macOS

chimehq.com

21–30 of 42 posts

Re: Chime 2.0 – a Go Editor for macOS

#21
post #3

The lack of integrated terminal or method of running a go program makes me question what use this is to someone. Until either of those is implemented, this is a no-go for me. Not even mentioning that it costs money to use without adding any value over free editors.

> 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 rec…

Only benefit i have found is if it is on a remote machine and you do not feel like ssh-ing twice.

Re: Chime 2.0 – a Go Editor for macOS

#24
post #9

Seemed interesting based on the amount of languages the editor supports on paper, but a quick trial showed that at least C# support is very, very barebones, even theoretical, as I couldn't get any kind of autocomplete to work, for example. After few minutes of usage Im unsure of what it provides aside from some syntax coloring. Maybe I did something wrong?

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.

Re: Chime 2.0 – a Go Editor for macOS

#25
post #3

The lack of integrated terminal or method of running a go program makes me question what use this is to someone. Until either of those is implemented, this is a no-go for me. Not even mentioning that it costs money to use without adding any value over free editors.

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…

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

For me as well. However language specific IDEs these days usually don't have much if anything on more popular editors.

Re: Chime 2.0 – a Go Editor for macOS

#26
post #3

The lack of integrated terminal or method of running a go program makes me question what use this is to someone. Until either of those is implemented, this is a no-go for me. Not even mentioning that it costs money to use without adding any value over free editors.

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…

With maybe a few exceptions that I'm unaware of, all integrated terminals are optional features that can be disabled. I agree that editor-specific run configurations are over the top and bad form, however an integrated terminal is a very useful feature that I use all the time, especially when working with Go.

Edit: And that said, if I'm paying money for a product it better have features that I'm going to need, and if I don't need them it better have a way to disable them.

Re: Chime 2.0 – a Go Editor for macOS

#27
post #11

Why does the title refer to this as a Go editor when the linked page is talking about having support for 23 different languages?

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.

We did start off with just Go. After doing a bunch of infrastructural work, we added another, Ruby. We've just finished generalizing this, in a way that both more 1st- and 3rd-party extensions can be created. To date though, we've only gotten to Rust and Swift.

Re: Chime 2.0 – a Go Editor for macOS

#28
post #9

Seemed interesting based on the amount of languages the editor supports on paper, but a quick trial showed that at least C# support is very, very barebones, even theoretical, as I couldn't get any kind of autocomplete to work, for example. After few minutes of usage Im unsure of what it provides aside from some syntax coloring. Maybe I did something wrong?

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.

Why not implement first class support for LSP servers, and offer extensions that wrap official LSP's?

Re: Chime 2.0 – a Go Editor for macOS

#29

Earlier quoted context omitted.

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.

Why not implement first class support for LSP servers, and offer extensions that wrap official LSP's?

That's more or less exactly what we've done. Our SDK does have support for LSP. But, unfortunately those extensions still need to be made. Or are you talking about a generic LSP extension that is server-agnostic? That is definitely buildable, but my experience has been that the experience tends to be a lot better when customized for a particular server.

Re: Chime 2.0 – a Go Editor for macOS

#30
post #8

Looks like the application requires macOS v12, which is only a year old. What features does it require that means it can't be backwards-compatible? Is it a SwiftUI thing?

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.
Post reply on HN