
Chime – A Go Editor for macOS - dsego
https://www.chimehq.com/
======
pcr910303
I’m not a Go user, so I’m not a bit of the target audience, but it’s so
refreshing that it has the native UI on macOS. Today deceloper tooling is
almost all electron/Qt/custom-framework based cross-platform; I was really
disappointed when I tried to find a decent editor with autocomplete (based on
LSP), project management with a cocoa-based UI (like native tabs and cocoa
textfields) and found... nothing.

It was really disappointing to find that nobody developing the developer tools
really consider user experience or nativeness... even on the mac where Cocoa
is very emphasized by the users. (For more of my arguments about native UI,
see my comment against flutter:
[https://news.ycombinator.com/item?id=20612195](https://news.ycombinator.com/item?id=20612195))

This product with some C/Rust/Lisp support would be the product I would have
to like to find, and I’m really looking forward to this product with the
expectation where this might be more configurable or some other language
support is added.

Great job for the developer, I really is thankful for showing that a cocoa-
oriented editor is possible & feasible. Thanks.

~~~
moooo99
The majority of users leverage these technologies for a reason. If you use
cross-platform technology you can simply reach a broader audience and in the
case of a commercial product, generate more revenue with only minimal
additional effort. From my personal experience users don't care at all if the
app has a native look or not, as long as the app looks decent and works. I
assume having the native UI components of an OS is a very specific
requirement, that does not apply to the vast majority of users. In fact, the
majority of users likely prefer having the same, highly customized UI of an
application, rather than having a completely different looking app when
switching platforms. Take Visual Studio Code as an example. Within a few
years, this editor became one of the most popular code editors. The app uses
mainly web technology and a browser window and does not look like a native
application at all, yet for the majority of users, it feels like a very fast
native application.

~~~
ridiculous_fish
Why do you say that "VSCode does not look like a native app at all?" It has a
Mac menu bar, context menus, drag and drop, familiar key equivalents. It's not
a completely foreign experience like (say) vim.

Achieving these things has required heroics on Microsoft's part. Very few
other electron apps go to those lengths.

Users switch between applications far more often than they switch OSes. Native
behavior allows users to bring expertise from one app to another. I'd be
productive more quickly with Chime, because I already speak its UI vocabulary.

~~~
jchw
Native menu bar and context menus are very much built into Electron, even
Hello World will have a proper menu on macOS. Some of the stuff like
integrated title bar is also pretty recent, and likely wasn’t a contributing
factor to its adoption.

Not to say VSCode doesn’t put any effort in or anything but I think Electron
apps are about on par with Qt apps in terms of native look and feel, albeit
they have their own strengths and weaknesses and are not easy to directly
compare.

------
dewey
Interesting, VSCode + Go plugin got very unreliable since I switched to the
language server integration. I have to restart the language server at least
once a day to make autocomplete in VSCode work again.

It'd probably be hard to switch as there's a bunch of other plugins for VSCode
that I use on top of all the keyboard shortcuts but it's nice to have an
option if it continues to be developed.

~~~
nicpottier
While the switch to go modules was pretty smooth on the code front, the
tooling was another matter. They had to rewrite everything to support modules
and decided to create this concept of a "language server" which would then be
universal across languages and help editors like VSCode support new languages
that pop up as long as they provide their own language server that matches the
spec.

It's a nice idea but has been (and continues to be) super painful for anybody
actually trying to get work done. This was a huge fuckup on the part of the
Google engineers to combine the rewrite with module support. They should have
first added module support to the existing tools THEN bitten off the totally
new paradigm of a language server. Yes it would have been more total work but
so many person-years of productivity was lost with the approach they took and
we are still counting.

~~~
mikewhy
Just FYI, your comment reads like you're saying the Go developers created the
concept of language servers, but they were created by MS for VS Code.

------
kevindong
> (Currently in closed Beta)

So what's the point in posting this?

~~~
sgt
Creating awareness, which is fine as they accept your e-mail address so they
can let you know when it's possible to test it.

~~~
kevindong
I don't agree with that strategy. This isn't a SaaS company where they're
actually resource constrained in terms of server capacity.

Chime has been under development since at least October 24, 2017 [0] and
there's no ETA on a public alpha/beta/GA.

Assuming that the poster is (one of) the author(s) of Chime, they shouldn't
post this until everyone can download it. It can be alpha/beta software, but
to post what amounts to a handful of screenshots is pointless in my opinion.

[0]:
[https://twitter.com/chimehq/status/922905555013947395](https://twitter.com/chimehq/status/922905555013947395)

~~~
1123581321
It wasn’t posted by the creator.

GitHub of the link submitter:
[https://github.com/dsego](https://github.com/dsego)

Twitter of the Chime dev:
[https://twitter.com/mattie](https://twitter.com/mattie)

------
KukicAdnan
What is the benefit of this over VS Code w/ the excellent Go extension by MS?

~~~
telegrammae
This one seems to be a native app for macOS, not an Electron app. So,
hopefully this allows to achieve higher performance with much lighter resource
utilization.

~~~
blondin
very interesting. i wonder about the tech behind it. always wanted to get into
native mac app development but objective-c is a little daunting. i wonder if
it's using swift ui?

~~~
mattiemass
I'd be happy to discuss! My first all-swift project. Was pretty rough at
first, but Apple's done a great job of iterating on it. 100% AppKit, though.
SwiftUI looks super cool, but it's just too new for me to feel confident
relying on it. Plus, we currently support 10.14 as well.

~~~
blondin
thanks for replying! the app looks totally awesome. i was asking my question
because i have been gathering resources for learning swift but from time to
time i would read things like it's not mature enough with some macOS
frameworks and you have to use objective-c. these comments and the fact that
the language itself kept changing/evolving are often off-putting. but i think
this just renewed my interest!

~~~
mattiemass
Thank you so much!

I think Swift is there now. There were some very painful migrations, but for
the past 2-3 years it has been different. It is true that it's a real pain to
use some C-based APIs with it, but those are pretty rare. And, often you can
find a Swift wrapper for them if you really need to. I've been using ObjC for
25 years, but I'm now pretty into Swift. I'd go for it.

------
sgarg26
Looks similar to the open source lime text project.
[http://www.limetext.org/](http://www.limetext.org/)

Are they leveraging the same codebase in any way? How does Chime want to be
different? I think lime is also written in go.

LimeText is still actively being developed here: Github:
[https://github.com/limetext](https://github.com/limetext)

~~~
thenewnewguy
When they say Chime is a Go editor they don't mean it is written _in_ Go
(although it could be), but that it is written _for editing_ Go.

~~~
fourseventy
Can confirm its written in go as well

~~~
mattiemass
I'm going to have to go ahead and disagree with you :) Developer here -
there's Go in our backend systems, but not in the app, unfortunately.

------
donutloop
Follow conversation on reddit

[https://www.reddit.com/r/golang/comments/ekdbiy/chime_a_go_e...](https://www.reddit.com/r/golang/comments/ekdbiy/chime_a_go_editor_for_macos/?utm_medium=android_app&utm_source=share)

The creator of this editor contributed some comments to this post.

~~~
mattiemass
Trying to comment here too now :) Hello everyone!

------
telegrammae
Sounds exciting! The greater the variety of editor/IDE options for Go, the
better!

~~~
diegoholiveira
I do agree. My concern is about the future of the project. If they do a great
job, I do think they should support others languages, perhaps having a
ecosystem like jetbrains. I think it's inviable survive supporting only one
language.

~~~
mroche
I’m not in their beta, but the following statement doesn’t give me a lot of
faith in a native Jetbrains-like alternative:

> Our whole philosophy is fewer features, built with more polish. Attention to
> detail and thoughful design is what Chime is all about.

They seem to be pretty focused on editor usage, not tooling and ecosystem.
That could definitely change over time, but I’m not currently interpreting
this application as a pluggable IDE-like scenario.

They also have barely any information on their site, so it’s hard to form an
opinion on this. It’s something to keep an eye on, though.

~~~
mattiemass
No, you got it. No public plugin system now, though anything is possible.
There are already so many editors that fill that role.

For now, we're 100% focused on delivering a great Go experience.

------
asdkhadsj
God I hope to see some great looking editor like this (or Panic Nova?) with ..
somehow.. integration with Neovim, Kakoune and etc. Aka an editor that can be
a frontend to "classical" CLI editors.

I would pay so much to be out of the Terminal, but I need to use my normal
editor (Kakoune in my case). I want to pay for a high quality frontend.

I fear the market isn't there and so the product I want will never be made. My
hope however is that someday someone can make a great editor GUI that could be
pluggable for users like me.

~~~
Skunkleton
Why do you want to be out of the terminal? IMO the CLI is what makes the
terminal editing experience good.

~~~
asdkhadsj
I like the CLI too, and would still need it if I "left" the Terminal.

What I mean by out of the terminal is that I simply want my editing experience
to have variable fonts, popups, borders for windows that aren't bound to font
size, better icons, underlines, etc etc.

~~~
Skunkleton
yeah, I totally get that. I keep toying with VSCode for the same reason. The
problem w/ gui based tools in general is that they don't usually follow unix
design principles. You end up making lots of little compromises just to
integrate into your editor.

~~~
asdkhadsj
Yea, which is why I want a _real_ frontend, not an emulator or w/e. Ie, there
are real frontends for both Neovim and Kakoune. They let the editor do the
real lifting, and they merely change the UI.

That is what I want, but in a super well presented manner. I'd happily pay
~200/y for that. BUT, I think this frontend would also have to have a "normal"
editor built in, because I don't think people like me would pay enough to
allow a dev to write this editor full time.

~~~
Skunkleton
VS Code has a plugin that uses neovim as a backend. I haven't tried it yet:
[https://marketplace.visualstudio.com/items?itemName=asvetlia...](https://marketplace.visualstudio.com/items?itemName=asvetliakov.vscode-
neovim)

------
jrockway
Pretty much all Go editor tooling is provided by "gopls" today, so if you have
an editor that supports the Language Server Protocol, you can have all these
features in your editor right now. I was never a tab completion person, but
gopls changed my mind. It's fast and works really well. Jump to definition and
related functionality also works very well. One keystroke to see the source
code of any function you call is great.

If it doesn't use gopls, then it will probably break in every corner case like
previous tools did. When modules first came out, you had to go like 3 forks
deep in "gocode" (the previous completion provider) because the original
author stopped caring at go 1.10, then the person who forked that didn't
support modules, then finally the author of gopls started maintaining it. This
maintenance overhead was exponential, given that gocode was not the only
editor integration; syntax highlighting, godef, etc. all had to be tweaked for
every editor and every go release. Now gopls handles all of this and is
maintained by the go team itself, so it will support new features in the go
language at the same time as go.

(I believe even dedicated go IDEs like goland have always been a little behind
go itself. It simply doesn't scale to have every editor implement their own go
tooling.)

gopls also addresses interesting corner cases. Say you build your project with
Bazel, and you generated protocol buffers as part of your build so that
developers don't have to find the right version of the protobuf compiler,
install it, and then debug why changing one name in the proto file caused a
600 line diff. gopls and go itself can't know that you are generating some Go
files with a build tool, so Bazel projects will have squiggly missing import
underlines below your proto imports, won't be able to tab complete, and godoc
won't be able to show you documentation for the protos. But, there is a
solution; the "package listing" functionality is modular and can have a
"driver" set at runtime, so all the go core tooling CAN find these generated
files and treat them as though they were natively checked into your
repository. It is reasonable to write one plugin for your build system to
support Go tools, but kind of insane if every Go editor had to do this. gopls
exists to make this work.

So with that in mind, every Go editor should be about the same. If you want
new features, add them to gopls. If you are writing a new code editor today,
just support the Language Server Protocol and you get great Go support, and
support for every other language.
[https://langserver.org/](https://langserver.org/) contains a list of
supported languages, and it's pretty much everything. Last I looked, even
things like Arduino were moving to LSP.

So I think the age of editors-for-a-language are over. Even if you restrict
your focus to just one language, which isn't that useful to begin with, you
will always be behind for some reason, be it new build systems, polyglot apps,
new language features... it's not worth it. Just use LSP and focus on core
editing.

~~~
cube2222
> (I believe even dedicated go IDEs like goland have always been a little
> behind go itself. It simply doesn't scale to have every editor implement
> their own go tooling.)

This isn't true in my experience. Goland worked well with go modules the day
the Go release candidate including them was published.

The jetbrains ecosystem is also overall great for polyglot apps including
stuff like different language injection in string literals in another
language.

Afaik they are explicitly not using language servers, as they have their own
generic language representation, which enables a lot of refactorings by
itself.

All in all, whenever a teammate complained about something not working in vs
code, I was successfully using it in Goland.

~~~
sethammons
This aligns with my experience. I switched from vs code because Goland was
simply better. It just works. VS code, using the language server, could not
even jump to declaration inside the same file

------
Bishonen88
same name as an Amazon communicator:
[https://aws.amazon.com/chime/](https://aws.amazon.com/chime/)

------
gcatalfamo
it's in closed beta.

------
fmakunbound
This looks cool. What’s the extension/language/customization mechanism?

~~~
mattiemass
Chime team member here.

Uhh, none :) It's built specifically for Go, and today supports no other
languages. I'm not sure when, or even if, we'll do a public plugin API.

------
sneak
I don’t think closed-source tools are ever going to be a major part of my
development workflow in the future.

Every part of my toolchain needs to be subject to my own itch-scratching, as
well as the ability to patch out the telemetry/spyware that everyone seems to
want to put in their apps these days.

~~~
mattiemass
Many people feel this way. This is why there are so many incredibly high-
quality open source tools today. Chime is definitely not made for people that
want to tinker. Some major components of the app are open source, though, and
more are coming.

But, there's no spyware in the app and there absolutely will never be in the
future. Of course, if you don't want to take my word on that (and also do not
trust Little Snitch), open source is the best option. There are tons of good
things out there, even specifically for the Mac.

~~~
sneak
The Golang ecosystem into which your product will presumably be marketed would
not exist if not for free software.

Your decision is an outlier, and you should reconsider.

------
gigatexal
What will the final price be? When will an open beta occur?

~~~
mattiemass
Final price is TBD. We've got a lot of beta testers now, so unsure how an open
beta will go. It's quite possible we go right from closed beta to general
availability.

~~~
gigatexal
will it be a one-off price or a subscription model? are you going to be
feature gating with tiers? like a pro, premium, enterprise level?

------
th0114nd
> Attention to detail and thoughful design is what Chime is all about.

Sorry for the nitpick, but a typo in this particular sentence was too good to
pass up.

~~~
Uehreka
Also the “tf” in Printf in the example is syntax highlighted wrong.

Admittedly, I’d rather a development team spend more time and attention on
their app than their landing page, but they should probably fix that since it
kinda sticks out. Hopefully they’ll see these comments.

~~~
alangpierce
From the screenshot, it looks like the intention is that "Prin" has been typed
by the user and "tf" is a suggestion, so it makes sense that "tf" would be
gray and "Prin" would be green. (Of course, that could be made more clear.)

~~~
tksb
Same thought here. Simply omitting a cursor seems to be the most disorienting
part.

~~~
mattiemass
I swear it makes sense when you us it! But, the cursor is there. "Prin" before
the insertion point, and the autocomplete suggestion of "t(<placeholder>)"
comes after.

~~~
alangpierce
Makes sense! The image we're referring to is the one for the "Built for macOS"
section, not the full screenshot at the top of the page. That one doesn't have
a cursor in it.

[https://www.chimehq.com/assets/images/built-for-
macos.png](https://www.chimehq.com/assets/images/built-for-macos.png)

~~~
mattiemass
Oh man I'm an idiot. Yes. You've all figured it out. Cursor there would indeed
make sense. Will fix!

------
fleur-de-lotus
Do you have a business model, or are you just developing for the fun?

I am a Sublime Text user and would be hesitant to pay money for just another
editor.

~~~
mattiemass
Both :) We'll be using a "Sketch-style" pricing model, licenses work forever,
but updates are only for a year.

I'd say that most developers are like you, invested in one editor. It's hard
to change, especially given how much customization is possible. Chime's really
tailored to people looking for a dialled-in macOS experience. Usually, the
people that want that kind of thing are out looking for it. It's pretty niche.

