> 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++, 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

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.

Writing c and go, and using c bindings is pretty painful compared to just writing go. It's technically possible Just like being technically correct, it's the worst kind of correct/possible.

Just like JNI, if only there were a couple of companies that would embrace JNI to create IDEs...

It's not what the language is for. Go is really strong for greenfield server projects (and bad pretty much anywhere else)

I think it is also very good for CLI’s and background agents

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.

> 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/

Last time I checked it is.

https://pkg.go.dev/cmd/cgo

try it and see. there is a reason for the proverb.

CGO exists.

Why would you write an IDE in Go?

Because it is an IDE for Go.