So it is written in C or C++? Apparently Go isn't good enough to write an IDE, even that it lags behind Java.
Why would you write an IDE in Go?
Because it is an IDE for Go.
Show HN: CodePerfect, a fast, lightweight IDE for Go
41–50 of 65 posts
Re: Show HN: CodePerfect, a fast, lightweight IDE for Go
#42Earlier quoted context omitted.
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).
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.
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...
Re: Show HN: CodePerfect, a fast, lightweight IDE for Go
#43Re: Show HN: CodePerfect, a fast, lightweight IDE for Go
#44Earlier quoted context omitted.
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…
> 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.
Re: Show HN: CodePerfect, a fast, lightweight IDE for Go
#45It'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.
Re: Show HN: CodePerfect, a fast, lightweight IDE for Go
#46Earlier quoted context omitted.
> 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.
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++,…
Hardly any different from going with C and C++, which could have been wrapped via CGO.
Re: Show HN: CodePerfect, a fast, lightweight IDE for Go
#47I 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/
Re: Show HN: CodePerfect, a fast, lightweight IDE for Go
#48Ironic 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.
Re: Show HN: CodePerfect, a fast, lightweight IDE for Go
#49Earlier quoted context omitted.
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…
> 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.
Cgo is not Go ref https://go-proverbs.github.io/