[HN Gopher] Chime 2.0 - a Go Editor for macOS
___________________________________________________________________
Chime 2.0 - a Go Editor for macOS
Author : parsd
Score : 60 points
Date : 2022-10-31 18:13 UTC (4 hours ago)
(HTM) web link (www.chimehq.com)
(TXT) w3m dump (www.chimehq.com)
| KerrAvon wrote:
| I'd expect the website to describe some of the features, but I
| can't seem to find any real sales effort. Lots of stellar
| competition in this area considering Mac-only editors alone:
| TextMate, BBEdit, Nova.
| thangngoc89 wrote:
| For context, this is probably posted after Apple ExtensionKit[1]
| made it to the homepage of HN.
|
| [1]: https://developer.apple.com/documentation/extensionkit
| throwaway102233 wrote:
| I just downloaded this to give it a trial and so far my exprience
| has been infuriating. I go to quick open a file - it takes 5
| seconds to provide me a suggestion, I select my suggestion and
| hit enter, nothing, I double click, nothing, I hit the space bar,
| nothing.... Okay, let me maximise the window, I double click the
| window title, nothing, hmm, let me double click where the window
| controls are, nothing. It hardly feels 'Mac native'.
|
| edit: after typing this out and letting it rest in the
| background, the quick open now actually opens a file.
| mattiemass wrote:
| 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.
| cytzol wrote:
| 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?
| mattiemass wrote:
| 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.
| Hovertruck wrote:
| Why does the title refer to this as a Go editor when the linked
| page is talking about having support for 23 different languages?
| Jtsummers wrote:
| 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.
| parsd wrote:
| 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.
| mattiemass wrote:
| 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.
| 0x37 wrote:
| 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?
| mattiemass wrote:
| 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.
| nateb2022 wrote:
| Why not implement first class support for LSP servers, and
| offer extensions that wrap official LSP's?
| mattiemass wrote:
| 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.
| woumn wrote:
| 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.
| nicoburns wrote:
| > 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.
| whimsicalism wrote:
| Only benefit i have found is if it is on a remote machine and
| you do not feel like ssh-ing twice.
| kactus wrote:
| 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.
| cweagans wrote:
| 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.
| chank wrote:
| > 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.
| nateb2022 wrote:
| 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.
| ankurpatel wrote:
| Kukumber wrote:
| what other features do you need in a text editor other than
| typing text and getting code completion?
| smoldesu wrote:
| A pricing scheme where I don't pay $29.99 for a minimalist
| editor that gets one year of updates.
| sgt wrote:
| It doesn't expire and it's a way to support the little guy
| while getting a great product. I don't see the issue here.
| Also, $30 is how many cups of coffee? 6-7?
| smoldesu wrote:
| You Mac users and your coffee comparisons... there are
| free editors out there that would put Chime to shame. I'd
| rather use Coteditor if I want a MacOS-native editor, or
| BBedit if minimalism is paramount.
|
| I'm also the sort of person who balks at Sublime
| licenses, so take my opinion with a grain of salt. Still
| though, there are many (even Mac-native) editors that put
| up stiff competition.
| Kukumber wrote:
| there is value in independent craftmanship
|
| you can still feed the big corps with your data if that's
| what you prefer
|
| but the people working on vscode don't do it for free
| either ;)
| smoldesu wrote:
| > you can still feed the big corps with your data if
| that's what you prefer
|
| This is an app for MacOS, the desktop operating system
| that sends Apple telemetry after every time you open an
| app. The notion that Chime is more private than
| comparable open-source editors is an outright lie, I
| welcome you to prove me wrong.
| dang wrote:
| Related:
|
| _Chime, a Go Editor for macOS - v1.0 Now Available_ -
| https://news.ycombinator.com/item?id=22436773 - Feb 2020 (26
| comments)
|
| _Chime - A Go Editor for macOS_ -
| https://news.ycombinator.com/item?id=21963708 - Jan 2020 (126
| comments)
| bendur_ wrote:
| How is Chime better/different from other options, like say
| Sublime Text?
| 404mm wrote:
| Cute but seems a bit too simple. I'm no fan of VSCode, I like my
| UI clean and simple (like Atom for example). Oh well, will
| continue waiting on Zed.
| zero_ wrote:
| out of curiosity: still using atom or vscode or switched to
| something else?
___________________________________________________________________
(page generated 2022-10-31 23:01 UTC)