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.
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.
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.
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".
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 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.
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 :)
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.
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.
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.
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 :)
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 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.
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...
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.
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.
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.
