13 ms·

Chime – A Go Editor for macOS

170 points by dsego 7y ago

KukicAdnan 7y ago
What is the benefit of this over VS Code w/ the excellent Go extension by MS?
- telegrammae 7y ago
  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 7y ago
    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?
    - dewey 7y ago
      https://twitter.com/chimehq/status/1213931585336156165 https://twitter.com/chimehq/status/1213931585336156165 > It's mostly custom drawing on top of a customized AppKit textview. The Cocoa text system is wildly powerful, quite hard to do pixel perfect drawing with. No OpenGL or any fancy graphics libraries.
    - mattiemass 7y ago
      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 7y ago
        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 7y ago
        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.
        saagarjha 7y ago
        There are very few APIs that cannot be used from Swift. I can't even think of any off the top of my head.
        jamil7 7y ago
        You should be fine using all swift now. The only thing is there are FAR more resources for learning Swift in an iOS context out there then macOS and you may have to figure some things out on your own.
  - vips7L 7y ago
    So it's sublime with a smaller ecosystem?
  - Vesuvium 7y ago
    Non-native apps can be as performant as native ones. I imagine they checked alternatives to Electron and figured a native app would allow them to have better OS integration.
    - buzzerbetrayed 7y ago
      > Non-native apps can be as performant as native ones This may be true. However, Electron apps cannot be as performant as native apps can be, which seems to be what they are getting at.
      - monocasa 7y ago
        Vscode does a pretty damn good job.
        solarkraft 7y ago
        VSCode really stands out to me among Electron apps, which is why I would be really interested in a write up about what they are doing to get it so performant (I think Rust is a part of the answer). Of course you can write terribly performing code on all platforms, but certainly some make it easier and/or have their own performance requirements.
        monocasa 7y ago
        Part of it I think is the super text heavy use case. Unlike slack for isntance that'll have N 30MB gifs (probably multiple copies of each too) in memory at any given point.
        filleduchaos 7y ago
        And still doesn't come close.
        monocasa 7y ago
        It's pretty damn close if you compare it to native apps with the same feature set.
- robbyt 7y ago
  I use vim, so I can't comment directly, but lately people have complained about stability of the VS Golang plugin
telegrammae 7y ago
Sounds exciting! The greater the variety of editor/IDE options for Go, the better!
- diegoholiveira 7y ago
  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 7y ago
    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 7y ago
      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.
  - sgt 7y ago
    Even without that, I still think it's a niche worth pursuing. They'll be able to sell this if it really works well. All the Go developers I know use macOS as their primary development platform.
- sneak 7y ago
  The last thing the world needs is another proprietary, payware IDE (that most likely involves all sorts of phone-home telemetry to benefit them and not you).
dewey 7y ago
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.
- sethammons 7y ago
  Same. I switched to Goland due to it.
- geodel 7y ago
  There may be better way to describe my feeling. But I think this LSP thingie is Electron of language tools. With the amount of activity I notice on LSP for Go is astonishing. Writes, rewrites and re-rewrites, the constant work on refactoring and optimization seems unending.
- mattiemass 7y ago
  When we started work on Chime, there were no viable Go language servers available, so we had all custom stuff. Now, gopls is fairly good, and has been progressing fast. But, yeah LSP isn't the holy grail. Progress on the spec is surprisingly slow, especially given how many holes it has. But, I'm very optimistic that it will get better. There's just so much traction behind it. However, Chime still contains a huge amount of custom language handling stuff, and will for the foreseeable future. LSP on its own is just insufficient for a good experience.
- nicpottier 7y ago
  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.
th0114nd 7y ago
> 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 7y ago
  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 7y ago
    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 7y ago
      Same thought here. Simply omitting a cursor seems to be the most disorienting part.
      - mattiemass 7y ago
        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 7y ago
        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
gcatalfamo 7y ago
it's in closed beta.
kevindong 7y ago
> (Currently in closed Beta) So what's the point in posting this?
- sgt 7y ago
  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 7y ago
    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 7y ago
      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
    - eric-hu 7y ago
      As someone who spent some time on support, I can sympathize with their closed beta. If you reach too large an audience before you're ready, you could end up treading water because you spend too much time responding to similar bug reports and feature requests.
  - yitchelle 7y ago
    and exclusivity. Same strategy as having a full house on opening night with a long queue rather than an empty house with no queue.
jrockway 7y ago
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.
sgarg26 7y ago
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 7y ago
  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 7y ago
    Can confirm its written in go as well
    - mattiemass 7y ago
      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.
pcr910303 7y ago
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.
- MuffinFlavored 7y ago
  > Today deceloper tooling is almost all electron/Qt/custom-framework based cross-platform; Sublime Text comes to mind as an app that is native as well.
  - pcr910303 7y ago
    No, Sublime Text was one of the apps in mind when I said a custom-framwork based cross-platform (or homemade might been a better phrase). I evaluated Sublime for my editor, and found that it’s OS integration was too bad; for one it’s tabs is custom-based and it’s text fields aren’t Cocoa (or at least it doesn’t feel like one). It’s primarily built as a cross-platform, so it really doesn’t consider OS integrations IMO.
    - pixelrevision 7y ago
      Have you tried textmate? I used that for a lot of years and it was 100% cocoa focused.
Bishonen88 7y ago
same name as an Amazon communicator: https://aws.amazon.com/chime/ https://aws.amazon.com/chime/
donutloop 7y ago
Follow conversation on reddit https://www.reddit.com/r/golang/comments/ekdbiy/chime_a_go_editor_for_macos/?utm_medium=android_app&utm_source=share https://www.reddit.com/r/golang/comments/ekdbiy/chime_a_go_e... The creator of this editor contributed some comments to this post.
- mattiemass 7y ago
  Trying to comment here too now :) Hello everyone!
asdkhadsj 7y ago
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 7y ago
  Why do you want to be out of the terminal? IMO the CLI is what makes the terminal editing experience good.
  - asdkhadsj 7y ago
    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 7y ago
      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 7y ago
        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.
gigatexal 7y ago
What will the final price be? When will an open beta occur?
- mattiemass 7y ago
  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 7y ago
    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?
sneak 7y ago
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 7y ago
  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 7y ago
    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.
fmakunbound 7y ago
This looks cool. What’s the extension/language/customization mechanism?
- mattiemass 7y ago
  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.
deleted 7y ago
[deleted]
fleur-de-lotus 7y ago
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 7y ago
  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.

170 points by dsego 7y ago

KukicAdnan 7y ago

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

telegrammae 7y ago
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 7y ago
  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?
  - dewey 7y ago
    https://twitter.com/chimehq/status/1213931585336156165 https://twitter.com/chimehq/status/1213931585336156165 > It's mostly custom drawing on top of a customized AppKit textview. The Cocoa text system is wildly powerful, quite hard to do pixel perfect drawing with. No OpenGL or any fancy graphics libraries.
  - mattiemass 7y ago
    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 7y ago
      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 7y ago
        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.
      - saagarjha 7y ago
        There are very few APIs that cannot be used from Swift. I can't even think of any off the top of my head.
      - jamil7 7y ago
        You should be fine using all swift now. The only thing is there are FAR more resources for learning Swift in an iOS context out there then macOS and you may have to figure some things out on your own.
- vips7L 7y ago
  So it's sublime with a smaller ecosystem?
- Vesuvium 7y ago
  Non-native apps can be as performant as native ones. I imagine they checked alternatives to Electron and figured a native app would allow them to have better OS integration.
  - buzzerbetrayed 7y ago
    > Non-native apps can be as performant as native ones This may be true. However, Electron apps cannot be as performant as native apps can be, which seems to be what they are getting at.
    - monocasa 7y ago
      Vscode does a pretty damn good job.
      - solarkraft 7y ago
        VSCode really stands out to me among Electron apps, which is why I would be really interested in a write up about what they are doing to get it so performant (I think Rust is a part of the answer). Of course you can write terribly performing code on all platforms, but certainly some make it easier and/or have their own performance requirements.
        monocasa 7y ago
        Part of it I think is the super text heavy use case. Unlike slack for isntance that'll have N 30MB gifs (probably multiple copies of each too) in memory at any given point.
      - filleduchaos 7y ago
        And still doesn't come close.
        monocasa 7y ago
        It's pretty damn close if you compare it to native apps with the same feature set.
robbyt 7y ago
I use vim, so I can't comment directly, but lately people have complained about stability of the VS Golang plugin

telegrammae 7y ago

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

diegoholiveira 7y ago
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 7y ago
  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 7y ago
    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.
- sgt 7y ago
  Even without that, I still think it's a niche worth pursuing. They'll be able to sell this if it really works well. All the Go developers I know use macOS as their primary development platform.
sneak 7y ago
The last thing the world needs is another proprietary, payware IDE (that most likely involves all sorts of phone-home telemetry to benefit them and not you).

dewey 7y ago

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.

sethammons 7y ago
Same. I switched to Goland due to it.
geodel 7y ago
There may be better way to describe my feeling. But I think this LSP thingie is Electron of language tools. With the amount of activity I notice on LSP for Go is astonishing. Writes, rewrites and re-rewrites, the constant work on refactoring and optimization seems unending.
mattiemass 7y ago
When we started work on Chime, there were no viable Go language servers available, so we had all custom stuff. Now, gopls is fairly good, and has been progressing fast. But, yeah LSP isn't the holy grail. Progress on the spec is surprisingly slow, especially given how many holes it has. But, I'm very optimistic that it will get better. There's just so much traction behind it. However, Chime still contains a huge amount of custom language handling stuff, and will for the foreseeable future. LSP on its own is just insufficient for a good experience.
nicpottier 7y ago
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.

th0114nd 7y ago

> 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 7y ago
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 7y ago
  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 7y ago
    Same thought here. Simply omitting a cursor seems to be the most disorienting part.
    - mattiemass 7y ago
      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 7y ago
        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

gcatalfamo 7y ago

it's in closed beta.

kevindong 7y ago

> (Currently in closed Beta) So what's the point in posting this?

sgt 7y ago
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 7y ago
  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 7y ago
    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
  - eric-hu 7y ago
    As someone who spent some time on support, I can sympathize with their closed beta. If you reach too large an audience before you're ready, you could end up treading water because you spend too much time responding to similar bug reports and feature requests.
- yitchelle 7y ago
  and exclusivity. Same strategy as having a full house on opening night with a long queue rather than an empty house with no queue.

jrockway 7y ago

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.

sgarg26 7y ago

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 7y ago
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 7y ago
  Can confirm its written in go as well
  - mattiemass 7y ago
    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.

pcr910303 7y ago

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.

MuffinFlavored 7y ago
> Today deceloper tooling is almost all electron/Qt/custom-framework based cross-platform; Sublime Text comes to mind as an app that is native as well.
- pcr910303 7y ago
  No, Sublime Text was one of the apps in mind when I said a custom-framwork based cross-platform (or homemade might been a better phrase). I evaluated Sublime for my editor, and found that it’s OS integration was too bad; for one it’s tabs is custom-based and it’s text fields aren’t Cocoa (or at least it doesn’t feel like one). It’s primarily built as a cross-platform, so it really doesn’t consider OS integrations IMO.
  - pixelrevision 7y ago
    Have you tried textmate? I used that for a lot of years and it was 100% cocoa focused.

Bishonen88 7y ago

same name as an Amazon communicator: https://aws.amazon.com/chime/ https://aws.amazon.com/chime/

donutloop 7y ago

Follow conversation on reddit https://www.reddit.com/r/golang/comments/ekdbiy/chime_a_go_editor_for_macos/?utm_medium=android_app&utm_source=share https://www.reddit.com/r/golang/comments/ekdbiy/chime_a_go_e... The creator of this editor contributed some comments to this post.

mattiemass 7y ago
Trying to comment here too now :) Hello everyone!

asdkhadsj 7y ago

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 7y ago
Why do you want to be out of the terminal? IMO the CLI is what makes the terminal editing experience good.
- asdkhadsj 7y ago
  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 7y ago
    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 7y ago
      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.

gigatexal 7y ago

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

mattiemass 7y ago
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 7y ago
  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?

sneak 7y ago

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 7y ago
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 7y ago
  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.

fmakunbound 7y ago

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

mattiemass 7y ago
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.

deleted 7y ago

[deleted]

fleur-de-lotus 7y ago

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 7y ago
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.