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.

Chime has in-process crash reporting. Which is both open source (on our Github page) and you can opt-out via prefs. No other telemetry of any kind. To be honest, I'm not even sure how telemetry like that could even be used to be benefit us. But, perhaps we're just not in that mindset.

Regardless, there's nothing like this in Chime and there never will be. But I get that not everyone wants a closed-source tool. There are many open source options, including a number of high-quality macOS native ones.

We're also super curious about this. We started Chime when Coda (pre-Nova) was all but abandoned. Panic is probably the best/worst competitor you can have for a macOS app, but we're very excited to see what they do. I'll probably lose sleep checking it out when I'm finally able to.

It's a lot of work to support a language well. Our intention is to focus on Go for now, but we're open to others in the future.

Lots of reasons for building an editor, but mainly our technical backgrounds with compilers and macOS apps felt like a good combination. Also, there aren't many (any?) macOS-native editors with deep language integration, so it really felt like an under-served market.

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.

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.

I'm just really happy that you're excited!

I've covered this elsewhere, but other languages aren't going to be an immediate focus for us. Possible, but even with LSP it's a lot of work to do something well. And, we still have tons of room for improvement just with Go.

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.

Whew, let me tell you. Chime has used three different Go language servers, as well as custom stuff. Every server was different, with different behavior, performance characteristics, and supporting different feature sets in different ways. And that was just for Go! I cannot imagine how it is for other languages.

Offering high-quality language support takes a lot of work, per-language and even per-server.

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.

Trying to comment here too now :) Hello everyone!

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.

Yeah, so we didn't actually post this. And, to be honest, we weren't at all prepared for how much attention we got today. It's cool, but the timing wasn't awesome. We're trying to work our way through all the beta requests and HN/reddit comments. But, I'm a lurker, not a commenter, so I kinda don't know what I'm doing...

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.

You know, even TextMate appears to use a custom tab implementation.

And, it was a huge amount of work to get the AppKit tabs to work in Chime, even though they are supplied by the framework. All the NSWindod tabbing stuff just wasn't built to be flexible for apps that need consistent UI across tabs, like our file navigator widget.

Chime team member here.

BBEdit is an incredible text editor. If you are working with text on macOS, it's hard to beat. But, I've struggled to use it for even basic programming work. It's just not built for that specific use case so much as general text manipulation.

Chime team member here.

That's one reason exactly. TextMate is a phenomenal piece of software, and I've used it for years. Will continue to use it probably. In many ways, it was an inspiration for Chime. It can do many things Chime cannot. But, TextMate does not offer the same language-level support, syntax highlighting accuracy and speed. And, I like to think Chime has a more refined UI, but that's a personal thing :)

Matt here - developer and member of the team of two that works on Chime. Thanks for your kind words. There actually are a lot of Cocoa-based editors out there, but to my knowledge, Chime is the only one that puts such a large emphasis on language-level support. We intend to continue to focus on that going forward.

To be honest, I think the multi-platform products available today are super-compelling. One of the reasons they are so immensely popular. But, I'm glad you're into what we're doing :)

First, I work on Chime.

I agree that language-specific tools can seem like a funny choice. But, it's just really hard to support one language well. This is probably why jetbrains does what it does. Of course, they surely have a large shared base, but tooling customized for one language and environment can work well.

We haven't discounted the possibility of expanding to other languages, but the general editor market is so well served that specialized tools just seemed like a better fit for what we were trying to do.

Hello! I'm the author of this article, and one of the people that works on Chime. I'm not certain how this ended up on hacker news now, but oh well.

It is true, we're still not quite ready for general availability, but getting Real Close Now. If you'd like to check out the beta, we have contact info at chimehq.com.

As for our design goals, it's true that it can be very hard to put those kinds of things into words. We've tried to convey our aesthetic goals better on our website. Usually, this kind of thing is easier to show than to tell.

We're shooting for fewer features, built with more polish and style. Lots of people don't prioritize that kind of thing from their editor. But, I hope that we can connect with the few that are.

That's very kind of you - thank you. Of course, people just get frustrated when they see someone doing something they think is silly. In this case, I do think there is interesting technical and psychological aspects worth thinking about. Really glad you liked it.

"like hell Tesla is going to be the only one selling cars online"

Dealing with forward- and backwards-compatibility with enum changes has bit me many times in the past. So has required fields.

Wow, this seems to address a bunch of problems I've experienced with protobuf in the past. Looks awesome!

Fascinating stuff! Reminds me very much of swift's guard statement.

I work in an open office plan as well. I've also worked in a private office, and I prefer my current arrangement. But, I know that many do not. Has anyone had any experience with a hybrid setup with private rooms available when needed?

I love stuff like this. Short, understandable.

Traditionally, compilers were built as tools for end-user developers. LLVM , instead, is a library you can use to make a compiler. Clang, for example, uses the LLVM API to produce a form that the LLVM subsystems can compile into actual machine code.

Interesting, clang actually did this too - it itself is a C/ObjC/C++ parser library, which can be used to make a tool.

LLVM is fantastic because, as a language developer, you can focus on your parsing and language-specific features without needing to concern yourself with machine code generation. LLVM does that all for you.

I think the premise of following money is interesting, but the conclusion I completely disagree with. I believe Apple's focus on privacy is a direct challenge to Google's business model. Apple makes all their money from mobile device sales, don't they?