Show HN: CodePerfect, a fast, lightweight IDE for Go(codeperfect95.com)
codeperfect95.com
Show HN: CodePerfect, a fast, lightweight IDE for Go
https://codeperfect95.com
16 comments
Ironic that it has an in-window file menu and is currently macOS only. Usually it's the Linux/Windows apps that are ported to macOS that have this.
Yup, this is a very non-Mac-like Mac-only app.
The GUI looks like Dear Imgui. Probably easier for the developer to not use Mac only APIs. Hopefully they fix it later.
Fast is not everything. Switch some years ago from Sublime to VSCode. Sublime is super fast, has many extensions, but VSCode is another league with more and powerfull extension and functions and a huge community.
Electron etc. are not really arguments in 2023, cause my computer is fast, faster than i could do anything.
The extensions and function help me working faster, not the text editor.
Agreed.
People talk about fast start-up times, and no latency etc like these are problems with vscode?
I just did a cold start of vscode here and it took approx 1 second to start on a M1 mac. For what it is worth, I generally never really even close vscode during the day - its typically open for days and days at a time so startup time seems kinda unimportant.
And as for latency, has anyone ever noticed any latency at all when using vscode? I certainly have not, and either way I have never been held back from coding by how fast I can type things, instead the limited function in programming has always been the thought process and deliberation for how to approach a problem. If anything, build/test times are the limiting factor after that, not UI latency.
People talk about fast start-up times, and no latency etc like these are problems with vscode?
I just did a cold start of vscode here and it took approx 1 second to start on a M1 mac. For what it is worth, I generally never really even close vscode during the day - its typically open for days and days at a time so startup time seems kinda unimportant.
And as for latency, has anyone ever noticed any latency at all when using vscode? I certainly have not, and either way I have never been held back from coding by how fast I can type things, instead the limited function in programming has always been the thought process and deliberation for how to approach a problem. If anything, build/test times are the limiting factor after that, not UI latency.
Never noticed UI latency when doing elixir programming. The slowdown is always the very slow compiler and language server.
Takes a few seconds to even highlight issues, and that’s when it works.
Takes a few seconds to even highlight issues, and that’s when it works.
I still use Sublime. No complaints, and as a bonus it isn't an Electron app.
> No language servers.
Why is that a good thing?
Why is that a good thing?
There is a lot of brouhaha about this. Two school of thoughts...
- LSP are a good idea but a terrible execution, YAGNI, etc.
- LSP are god send, burn my cpus I don't care
I'm being a little sarcastic but I think that's the gist of it. I'm neither pro or against LSPs. I use them when available.
- LSP are a good idea but a terrible execution, YAGNI, etc.
- LSP are god send, burn my cpus I don't care
I'm being a little sarcastic but I think that's the gist of it. I'm neither pro or against LSPs. I use them when available.
The negative opinions I've seen weren't exactly calling it a good idea, it went more along the lines of "it's now a distributed system more complex".
Though honestly I think it's the best we have right now and it's worth the cost. Partially because I don't like IDEs and LSP doesn't need to be integrated and tailored to one specific environment.
Though honestly I think it's the best we have right now and it's worth the cost. Partially because I don't like IDEs and LSP doesn't need to be integrated and tailored to one specific environment.
What I've heard (and what basically makes sense to me) is that falling back to the network layer as an abstraction is borne of web programmers trying their hand at building native applications (they do not know what dynamic linking is), with all that comes of it (both positive and negative).
On the contrary, we came to realize the security and stability issues caused by loading foreign code in-process.
Modern hardware is powerful enough to go back to classical UNIX IPC for plugins, while achieving security and host stability in the process.
Plus, shared memory is still a possibility for performance, with the same caveats as loading in-process foreign code.
It is also how Plan 9 works, everyone loves Plan 9.
Modern hardware is powerful enough to go back to classical UNIX IPC for plugins, while achieving security and host stability in the process.
Plus, shared memory is still a possibility for performance, with the same caveats as loading in-process foreign code.
It is also how Plan 9 works, everyone loves Plan 9.
Pretty sure LSPs communicate by stdin/out don't they?
Agree generally.. But I gotta admit, MS's LSP protocol has been successfully implemented by many non-MS IDEs. I'm doubtful this would be the case had they defined a c api instead.
Agree generally.. But I gotta admit, MS's LSP protocol has been successfully implemented by many non-MS IDEs. I'm doubtful this would be the case had they defined a c api instead.
I looked it up and apparently this is left unspecified[0]. So I suppose I take that back!
Also yeah, I use LSPs and I myself don't have a strong grasp of the use of dynamically linked libraries. I don't mean it as a put-down of web programmers (I am one). There is value in this microservice type approach, though it does feel very "webby".
0: https://en.wikipedia.org/wiki/Language_Server_Protocol#Techn...
Also yeah, I use LSPs and I myself don't have a strong grasp of the use of dynamically linked libraries. I don't mean it as a put-down of web programmers (I am one). There is value in this microservice type approach, though it does feel very "webby".
0: https://en.wikipedia.org/wiki/Language_Server_Protocol#Techn...
They communicate by all possible OS IPC protocols.
Thanks for doing this, that is a massive achievement.
My main nitpick is about picking up another IDE just for_ one_ language.
I dislike VSCode as much as the next guy, but having an IDE just for Go doesn't make much sense to me in 2023.
Most of us use far more than one language or stack every day, so there is enormous value proposition by supporting many languages, and even opening up possibilities with a plugin system. I hope you're considering those ideas. I guess you might since it's called CodePerfect and not GoSomething :)
I think your pricing is on point though.
My main nitpick is about picking up another IDE just for_ one_ language.
I dislike VSCode as much as the next guy, but having an IDE just for Go doesn't make much sense to me in 2023.
Most of us use far more than one language or stack every day, so there is enormous value proposition by supporting many languages, and even opening up possibilities with a plugin system. I hope you're considering those ideas. I guess you might since it's called CodePerfect and not GoSomething :)
I think your pricing is on point though.
I like that it is written C/C++. I remember Eclipse was written in Java, and I thought that was really cool. Java to edit Java.
Eclipse was less cool once you had to use it. Only IDE to have a restart option in the file menu, for when it got confused.
I don't understand the past tense here, Eclipse is alive and kicking.
I recently had to choose a Java IDE to learn/use. It's pretty much a clean slate for me, as I've done only very little java in the 20-odd years that I've been developing software, and none at all over the last five years.
I comparatively looked into Eclipse, NetBeans, VSCode, and IntelliJ, and picked Eclipse.
The main drivers of my decision: Eclipse doesn't force you into any particular build system like maven (or using one at all), and doesn't force you to lay out your project folder in any particular way. This was ideal for my polyglot project, where I wanted to keep the Java component minimalistic and avoid dependency hell.
It also has a rich plugin ecosystem. With some of the other alternatives, I couldn't even use subversion, my preferred VCS, which is apparently exotic these days.
The guts of the language server behind the Java tooling most commonly used with VSCode actually come from the eclipse project, while exposing only a tiny fraction of the functionality you'd get when using eclipse directly.
It's both free as in beer and free as in freedom, and the Eclipse Foundation looks (at least to an uninformed outsider's eye) like a force for good in the Java ecosystem, fighting for what's right.
I recently had to choose a Java IDE to learn/use. It's pretty much a clean slate for me, as I've done only very little java in the 20-odd years that I've been developing software, and none at all over the last five years.
I comparatively looked into Eclipse, NetBeans, VSCode, and IntelliJ, and picked Eclipse.
The main drivers of my decision: Eclipse doesn't force you into any particular build system like maven (or using one at all), and doesn't force you to lay out your project folder in any particular way. This was ideal for my polyglot project, where I wanted to keep the Java component minimalistic and avoid dependency hell.
It also has a rich plugin ecosystem. With some of the other alternatives, I couldn't even use subversion, my preferred VCS, which is apparently exotic these days.
The guts of the language server behind the Java tooling most commonly used with VSCode actually come from the eclipse project, while exposing only a tiny fraction of the functionality you'd get when using eclipse directly.
It's both free as in beer and free as in freedom, and the Eclipse Foundation looks (at least to an uninformed outsider's eye) like a force for good in the Java ecosystem, fighting for what's right.
It's past tense because the situation may have changed since I last used it. It was indeed a very generically (in a good way) built product, designed to accommodate all sorts of UI customisations and project layouts. I think once IBM decided to commoditise their complement a well-meaning software architect got stuck in with a deep plugin architecture, which is very smart but in practice used to get confused a lot. Glad to hear it's better now!
Thankfully we live in a world in which we constantly start new containers with every merge to master and the orchestrator will simply restart your container if it your application gets OOM killed, so Java is finally usable :)
IntelliJ has this too.
Goland does too
Funny that you mention it, I was surprised that it wasn't written in go ( but I don't really care about the language it's written in.)
Hmm on their pricing page they say that only the pro version can be expensed.
That seems a bit bold. Surely it is not up to them what can and can't be expensed. If it is just a terms and conditions thing of "oh if you want to expense this then it is exactly the same but twice the price" then that leaves quite an unpleasant taste.
That seems a bit bold. Surely it is not up to them what can and can't be expensed. If it is just a terms and conditions thing of "oh if you want to expense this then it is exactly the same but twice the price" then that leaves quite an unpleasant taste.
Cool! Finally an IDE not based on electron or java! There has been another one but it was abandoned many years ago.
I still enjoy Geany. It is lacking certain features I could do with, but it's joyful to use something that light: https://www.geany.org/
I don't think I'll ever use a non-free-software code editor.
The risk of lock-in is too high. My editor is the most important tool I use every day, I don't want to be beholden to some company for my muscle memory.
The risk of lock-in is too high. My editor is the most important tool I use every day, I don't want to be beholden to some company for my muscle memory.
I am stuck with Goland, which i really like, because i cannot stand vscode. But like all jetbrains products, i use about 1% of the functionality of the IDE. So having appropriately priced alternatives, WITHOUT subscription model which i will never pay for, is very welcome.
PS: all I use is terminal tabs, looking up functions/method/properties and their descriptions, go-to definition, open folder, and run tests(which is just small command anyway). as i have said, 99% of IDE is worthless to me.
PS: all I use is terminal tabs, looking up functions/method/properties and their descriptions, go-to definition, open folder, and run tests(which is just small command anyway). as i have said, 99% of IDE is worthless to me.
But technically Goland isn't 'on a subscription model' but a 'you want updates you need to pay for it model' , nothing stops you for just paying 1 year and having that license for life :)
How does it compare to Goland?
Been using LazyVim for professional go development for over a year now. I can't see any features promised here that I do not already have. LazyVim is a NeoVim configuration for those who don't know. Together with the golsp its insane how good it is. Sometimes I miss those heavy refactoring functions that Jetbrains provide though, like extract function etc.
Absolutely agree. LunarVim is my NeoVim configuration of choice and 90% of my usual workflow is present and with the missing rest I can still manage to be productive enough.
I don't see not having LSP as a positive aspect to mention by their IDE.
I don't see not having LSP as a positive aspect to mention by their IDE.
I use NeoVim and write the configuration myself. It's great with LSPs and I love the fact that I can interface with my editor in Lua.
In the same way, I love how Blenders interface is entirely scriptable with python. I wish Digital Audio Workstations like Ableton Live offered something similar.
It's interesting to see that they distinguish between pro and private users by not allowing private users a receipt.
I'm pretty sure this is illegal where I live. I like the idea, though. If you're hobbyist you typically don't need a receipt.
I'm pretty sure this is illegal where I live. I like the idea, though. If you're hobbyist you typically don't need a receipt.
[deleted]
Interesting choice to forego language server protocol.
Has that been a performance bottleneck?
Has that been a performance bottleneck?
So it is written in C or C++?
Apparently Go isn't good enough to write an IDE, even that it lags behind Java.
Apparently Go isn't good enough to write an IDE, even that it lags behind Java.
> Apparently Go isn't good enough to write an IDE, even that it lags behind Java.
The GUI situation in go is poor, but other than that I would say go is an excellent tool to write the remainder of the IDE in.
The GUI situation in go is poor, but other than that I would say go is an excellent tool to write the remainder of the IDE in.
writing desktop UI is really difficult these days. I mean i'm not saying it used to be easier, but the amount of technologies you can use to write a web application or desktop/javascript application and easiness of creation is overwhelming, while the amount of GUI frameworks stays the same, while some of them are decaying (no new version for a long time).
So we have objective-c/swift (new!) for macos, MFC for MSVC++, WPF/UWP for C# - all those for windows, and we have QT/GTK for Linux and de facto multiplatform. That's basically all usable at the moment, but GTK is heavy on windows/mac in my opinion.
New languages bubbling up from the opensource ground meanwhile do not offer many bindings for those above, while QT had made it hard to do any reliable binding at all, apparently...
So we have objective-c/swift (new!) for macos, MFC for MSVC++, WPF/UWP for C# - all those for windows, and we have QT/GTK for Linux and de facto multiplatform. That's basically all usable at the moment, but GTK is heavy on windows/mac in my opinion.
New languages bubbling up from the opensource ground meanwhile do not offer many bindings for those above, while QT had made it hard to do any reliable binding at all, apparently...
Hardly any different from going with C and C++, which could have been wrapped via CGO.
sorry, in theory it's okay, in practice it's much more difficult.
-- edit -- speaking of Qt
-- edit -- speaking of Qt
CGO supports C++.
Qt framework is not about C++. It creates another language inside with different mechanics. And most important, different memory management patterns. Sometimes the objects are managed by Qt parent object, sometimes not. I wouldn't commit to a project that would create a GUI in Qt using CGO.
It's not what the language is for. Go is really strong for greenfield server projects (and bad pretty much anywhere else)
In my opinion the language itself lends it self pretty well for GUIs. The concurrency and synchronization primitives are strong.
The problem would be to have native bindings to the GUI elements of the various desktop OSes. Which are hard to build as calling C or C++ libraries aren't a real option.
I would love to hear why Go as a language isn't suited for GUIs. I've built a couple of toy GUIs and it's been a pleasure doing so.
The problem would be to have native bindings to the GUI elements of the various desktop OSes. Which are hard to build as calling C or C++ libraries aren't a real option.
I would love to hear why Go as a language isn't suited for GUIs. I've built a couple of toy GUIs and it's been a pleasure doing so.
> Which are hard to build as calling C or C++ libraries aren't a real option.
Using CGO is hardly any different from JNI in complexity.
Using CGO is hardly any different from JNI in complexity.
Cgo is not Go ref https://go-proverbs.github.io/
Last time I checked it is.
https://pkg.go.dev/cmd/cgo
https://pkg.go.dev/cmd/cgo
try it and see. there is a reason for the proverb.
I think it is also very good for CLI’s and background agents
CGO exists.