I was expecting the author to mention Smalltalk because I distinctly remember people praising Smalltalk for its IDE but I think the IDE I was thinking of is from the late 90s or early 00s.
I don't think SmallTalk ever had a TUI. Even the very early versions on the Xerox machines used a GUI, and that GUI persisted even when it was all ported to Solaris.
Oberon was this weird mix where you had a proper GUI on thr screen but it would basically only show text. You could run commands by selecting text from inside any arbitrary window. The plan9 OS and Acme editor have kept this workflow.
The title of the article doesn't mention TUIs (or UIs at all) but I was thinking of a GUI. Specifically it seems I was likely thinking of Pharo (which is '00s not '90s so off by a decade).
The article subtitle is: "A deep dive into the text mode editors we had and how they compare to today's".
The second paragraph says: "This time around, I want to look at the pure text-based IDEs that we had in that era before Windows eclipsed the PC industry."
> I think the IDE I was thinking of is from the late 90s or early 00s.
Smalltalk's from the 70s and 80s, and almost certainly had what you're thinking about given it's where both Microsoft and Apple got their foundational ideas (restricted to significantly less powerful hardware), and later unrelated smalltalks retained a lot of now quirky considerations and behaviours. Self inherited a lot of those and is from the late 80s.
So yes, I was also expecting the author to talk about Smalltalk.
If you actually look at Xerox’s hardware, it’s quite a stretch to call Lisa or Macintosh “less powerful.” It’s kind of amazing what Xerox was able to accomplish on such underpowered systems; they did it largely by having multitasking microcode to handle performance-sensitive I/O, and implementing BitBlt there too.
I suspect there are quite a few more niche languages/interfaces that the author didn’t consider when it comes to GUI IDEs. I thought of EiffelStudio immediately, myself, having worked with a group that used it in a past life.
People still forget Eclipse when it comes to a full-blown yet not bloated IDE. That thing consumes less than a bare bones VSCode install while running 5x the tools. It can handle everything from code to git to CI/CD and remote development since 2013.
I'm using it for 20 years and I think it's the unsung hero of the IDE world.
This article doesn't mention it either as a modern GUI IDE.
It was, for C++, for a couple of years, 12-13 years ago. It's neither laggy nor slow for the last 8-9 years. I've written my Ph.D. thesis on it, on C++, which was a sizeable high performance code.
It never crashed, allowed me to work remotely if required, integrated with Valgrind, allowed me to do all my tests, target many configurations at once, without shutting it down even once.
Currently it has a great indexer (which is actually an indexer + LSP + static analyzer and more), LSP support if you wish, and tons of features.
It gets a stable release every three months, comes with its own optimized JRE if you don't want to install one on your system, etc.
Plus, it has configuration snapshots, reproducible configurability, configuration sync and one click config import for migrating/transforming other installs.
While Eclipse today is certainly a quite decent IDE, I use it mostly in the form of STM32CubeIDE[1] now, it was servicable at most back in 2005-2006 when I used it for some Java classes.
In any case, it's a younger product than the offerings in the article.
Not just C++. I used to use it for Java development and had the same experiences as the GP too.
I’m sure it’s really good these days. But I’ve moved on now and my current workflow works for me, so I don’t see the point in changing it until I run into issues again.
Java never got that slow, but it used to tax the system a lot in the earlier days, yes.
I developed Java with Eclipse, but the project I did was not that big when Eclipse was not its prime, and it was in its prime when I was experienced enough to be able to "floor it" in terms of features and project complexity.
Now it's just a blip on the memory usage graph when working with big projects, and way way more efficient than the Electron apps which supposed to do 20% of what Eclipse can do.
There’s a reason people don’t talk much about Eclipse these days and it’s because it was a pain to maintain back when it really should have shone.
I really wanted to like Eclipse but gave up on it a decade ago because it required constant management from release to release. I remember one job I had where I didn’t need an IDE all that often and I would spend nearly as much time configuring Eclipse again upon the next time I came to use it, as I was spending time writing code in it.
I’m sure it’s improved leaps and bounds in that time - 10 years is a heck of a long time in any industry, let alone IT. But I do know I wasn’t the only one who got frustrated with it. So myself and others switched to other solutions and never looked back.
> I remember one job I had where I didn’t need an IDE all that often and I would spend nearly as much time configuring Eclipse again upon the next time I came to use it, as I was spending time writing code in it.
So basically the same as setting up and configuring a development environment today, except that nowadays it's a lot more centered around the command line and involves a bunch of disparate, half-documented packages/tools from GitHub (and that also inexplicably require 10 to 1000 times more space and clock cycles).
The “I” part of IDE stands for “integrated” whereas what you’re describing is just a development environment without any integration into your text editor.
That all said, I have found VSC to be piss poor for tempting out new projects. And some ecosystems like TypeScript really do need a lot of boilerplate before you can ever start on a “hello world” application.
Still is, quite a few features like Swing editors, or the two way editing between rendering templates and Java code, or the quality of profiling tools for such open source product.
I also used NetBeans a bit years ago, though that was mainly because it had a (mostly) WYSIWYG editor compared to Eclipse (technically Eclipse had a plugin for that which supposedly was also superior in how it worked - it parsed the code to figure out what the GUI would look like and updated in place instead of NetBeans' generating code with commented out sections you wasn't supposed to touch - but in practice it was both slow and clunky).
For Java specifically i felt NetBeans was faster and simpler though i bounced between it and Eclipse because i also used Eclipse for other stuff (C++ mainly) so unless i wanted a GUI i used Eclipse. I did stopped writing Java some time ago though.
I did try a recent NetBeans build but i found it much less polished than what i remember from before it became "Apache NetBeans".
Interesting - I run Intellij Ultimate on Macbooks (both Intel and m2) and never have a crash. Infrequently run into bugs when upgrading the ide or 3rd party plugins; that requires some sort of cache invalidation or project reimport (couple times a year), but it's pretty smooth sailing for something I use across many different projects and languages. Java, kotlin, TS, python, groovy, shell scripting, json/xml/yaml/html/tsx are all generally touched 40+ hours on a weekly basis - it just works.
I do agree intellij is memory hungry with multiple projects open and a variety of languages involved, but RAM is cheap enough (and VMs/Docker/K8s hungry enough) that I just don't buy a machine with less than 32GB anyway, so I give intellij up to 6 GB and never give it another thought.
I don't do much android development, but do find Android Studio to feel clunky and slow at times, guessing because of the heavy integration with Android dependencies and emulation, but not really something I know enough about to comment with any sense of authority.
VSCode is really a text editor-in-IDE-clothing. Also, it's an Electron app and those are notoriously resource heavy.
~20 years ago I became an early IntelliJ user. From version 3 maybe? It's hard to recall. I've never looked back.
But I did try Eclipse and... I never got the appeal. For one, the whole "perspectives" thing never gelled with me. I don't want my UI completely changing because now I'm debugging. This is really part of a larger discussion about modal editors (eg vim vs emacs). A lot of people, myself included, do not like modal editors.
But the big issue for Eclipse always was plugins. The term "plugin hell" has been associated with Eclipse for as long as I can recall. Even back in the Subversion days I seem to recall there were 2 major plugins (Subclipse? and another?) that did this and neither was "complete" or fully working.
To me, IntelliJ was just substantially better from day one and I never had to mess around with plugins. I don't like debugging and maintaining my editor, which is a big reason why I never got big into vim or eclipse. I feel like some people enjoy this tinkering and completely underestimate how much time they spend on this.
I’ve been using vscode for a few years now and while i find its search amazing, it doesn’t do much more for me. Its syntax highlighting is good, but the auto complete recommendations have been driving me insane recently.
Writing rails api with a nextjs ui, anyone got any suggestions on alternative paths i should take?
This may not apply to you but I find it so weird how many programmers won't invest even a modest amount into software they'll use 8 hours a day every day. Particularly when we'll so easily spend money to upgrade RAM or buy a new PC.
RubyMine on a cancel anytime personal license is $22.90/month (or $229 for a year). That's nothing. I'd say just try it. If you don't like it, you might only be out $23.
I'm not a Ruby person so can't comment on that really. For Java (and C++) it's a lifesaver. Things like moving a file to a different directory and it'll update all your packages and imports. Same with just renaming a class or even a method.
The deep syntactic understanding Jetbrains IDE have of the code base is one of the big reasons I use them.
For me, perspectives are perfect, because it provides me a perfect set of tools for everything I do at that moment. It's probably a personal choice, so I agree and respect your PoV.
The plugin conflicts were way more common in the olden days, that's true, however, I used subclipse during my Master's and it was not incomplete as my memory serves. It allowed me to do the all wizardry Subversion and a managed Redmine installation Assembla had to offer back in the day.
It's much better today, and you can work without changing perspectives if you prefer, so you might give it another shot. No pressure though. :)
Trivia: VSCode Java LSP is an headless Eclipse instance.
At a minimum, perspectives play very nicely with the plugins system.
Eclipse was created over that extremely interesting idea that you can write a plugin to do some completely random task, and have all of it reconfigured on the perfect way for that task.
But you can't have a rich ecosystem of plugins without organizing them in some way, and nobody ever created a Debian-like system for them as it's a lot of thankless hard work.
This is kind of my problem with it. I'll use VSCode for typescript but I avoid it if there are other alternatives. The entire model of VSCode just doesn't jive with me.
For about five years, my daily start of the day ritual was starting eclipse, going to a 10 minute standup, and coming back two minutes before it stopped loading. To be fair, it's probably better now, and I stopped doing Java work in 2014.
what I dont understand about java is why doesn't it just take what it needs? If I commanded eclipse to open, that's it. Open an editor, maybe 2-3 recent files, and let me move the cursor around. If IntelliJ isn't ready yet, so be it, but dont slow my UX down because it's running a bunch of services I didn't ask for. If I hit the IntelliJ autocomplete then fine, I'll wait if it's not ready, but until then, the editor frames should be just as snappy as notepad. Java doesn't put the user first!
I used to like Eclipse but honestly it was and still is a hog. At the time i used it in the late 2000s it was basically the best IDE for C++, having features that Visual C++ users either did not have or needed to pay extra for plugin to get. I used it at work then when everyone else used Visual C++.
However at home i had a computer i bought late 2003 (which was a high end PC at the time but still) and the program was so heavy i remember despite running it under a lightweight environment (just X with Window Maker) i had to choose between Firefox and Eclipse because otherwise things would crawl due to the excessive memory use both programs made :-P.
Eventually i switched to other IDEs and forgot about Eclipse. But i did try it recently again and while obviously doesn't feel as heavyweight as it did back then (i'm running it on a 8 core machine with 32GB of RAM so it better be), it still feels sluggish and startup time is still quite slow.
Also TBH i never liked the idea behind workspaces.
These days i don't write C++ much but when i do i use either QtCreator or Kate with the Clangd LSP (which i also use for C).
I think 9 seconds startup time with 1GB of memory use is pretty acceptable for an IDE at the size of Eclipse (just timed).
Considering I'm not closing it down for whole day when I'm using it, waiting for ~10 seconds in the morning is not that bad.
In 2003, Eclipse was at its infancy and was an absolute hog, I agree on that front.
Actually you are not expected to have "n" workspaces. Maybe a couple (personal and office) at most. Project relationships and grouping is handled via "referenced projects".
Kate is an awesome code-aware text editor. I generally write small Go programs with that, but if something gonna be a proper project, it's always developed on Eclipse.
> Considering I'm not closing it down for whole day when I'm using it, waiting for ~10 seconds in the morning is not that bad.
I tend to close and run the IDEs (and most programs) multiple times per day - a clean desktop kinda lets me clean/reset my thoughts - so long startup times are annoying. Of course i wouldn't avoid a program if it was responsive, fast and did what i wanted after it started up.
> Actually you are not expected to have "n" workspaces. Maybe a couple (personal and office) at most. Project relationships and grouping is handled via "referenced projects".
Yeah i also had a single workspace but i worked in a bunch of other things, including some Java stuff in NetBeans and i want to have everything in one place. I do use and prefer IDEs but every other IDE could just store projects wherever i wanted.
First, it was quite common for a company to buy a developer the exact same corporate standard computer as everyone else. So lots of computers had limited ram to run things like J2EE, Lotus Notes, and Eclipse at the same time. It was painful.
The startup was always slow because it preloaded everything. This was a deliberate choice to not load things and interrupt the developer. Just don't close it all day and the experience was very good.
A plus compared to the standard of the day was that it ran native widgets. So doing something as simple as opening a file explorer to browse through your project was considerably faster than comparable IDE's at the time.
Personally, I loved the customization which was dialed all the way up. I could have multiple windows with different arrangements of panels within them, all saved. I haven't run across anything as configurable since then.
It also had the big benefit of their plugin system which shined when working with multiple languages in the same project.
It always felt to me like it became trendy to crap on Eclipse because of the slow startup time and it never could shake that.
> I think 9 seconds startup time with 1GB of memory use is pretty acceptable.
9 seconds of startup time on a modern GHz computer is completely unnecessary and unacceptable IMO. There may be 9 seconds of work it wants to do at startup, but there's no way it needs to do it in a single thread before letting you start to interact with it. This is an optimization effort, nothing more. Give me a month with their codebase and I could get that down to under a second. (So could most decent software engineers.) It would just need to be something they actually put effort into.
In that 9 seconds, a Java VM starts up, starts up an OSGI compliant platform and loads all the plugins you have installed and enabled in that particular Eclipse installation. When the window appears 9 seconds later, the VM is warmed up, all your plugins + IDEs (yes multiple) are ready to use. No additional memory allocations are done WRT your development plugins. Also remember that these plugins are not in isolation. There’s a dependency graph among them.
In the following seconds, updates are checked and indexes of your open projects are verified and re-run if necessary which takes again <10 seconds on different threads. Your computer may scream momentarily due to increased temperature on all cores if indexes are rebuilt.
If you think that code is not optimized in the last 20 years, you’re mistaken. Many tools from Android Studio to Apache Directory Studio runs on that platform.
Nevertheless, I’ll try to profile its startup tomorrow if I can find the time.
It may not be about optimization, but about user experience. You may have to be clever and think outside the box. Can you save a snapshot of all that work so that the next instance doesn't have to do it before showing the window? And then assuming it has to do the work (which may not be necessary if it just started up--once a day is probably sufficient), it can redo the work in a separate thread.
Eclipse already does non-critical background tasks on separate threads, and non-critical startup tasks are done in "deferred early start" queue, which is emptied after initial startup.
Normally Eclipse IDE is not something like Vim, which you enter and exit 10 times a day. It just lives there and you work with it. 10 seconds in the morning for a tool that big is very acceptable, esp. after considering that everything is instantaneous after that 10 seconds.
For me it's completely wild to think that all the steps you mentioned should take more than half a second in a 2023 medium dev computer able to process 40GB/s of data in RAM and read at 7GB/s from SSDs. Normalizing things being this slow is why using computers is such a pain nowadays, this should entirely be treated as a bug.
I think there's a bit of misconception about how I run this software.
First of all, this neither machine's RAM bandwidth is 40GB/sec, nor it has a 7GB/sec PCIe drive. It's a run of the mill, SATA backed system with a 7th generation i7.
Second, JVM is always a heavy machinery to start. The startup CPU utilization is around 600%, dipping to 400% and spiking to 800% at the end, showing some plugin dependency requirements are slowing things down. Also, that's a 20 year old OSGI platform, which runs a ton of interconnected plugins, not a mere text editor. It's in the same ballpark of MATLAB or scientific modelling software in complexity and sophistication.
Lastly, as an HPC admin and develoeper, I live by and die by performance. Computers can do some complex things for humans (e.g.: Floating point number crunching) stupidly fast, but some things which are seemingly simple for us (e.g. understanding language) can be equally stupidly slow and resource hungry.
For me, it's wild to think about complaining for something without investigating and understanding it completely.
It wasn’t “a hog” it was the hog. I don’t know where OP gets the idea that it was svelte. IntelliJ is considered a pig and a half in most eras but at the time, for most if not quite all projects, Eclipse had a worse memory footprint, for less functionality.
Also the UX was mediocre at best and infuriating at worst. Practically every interaction worth performing in that editor took at least one more click or keystroke than IntelliJ, and I would rank IntelliJ as merely good, but not amazing with input economy.
I have good memories of Eclipse, from back when I was doing Java. I remember at the time it seemed everyone dissed it, much as it feels like everyone disses Jira now and for the last decade, but I liked it.
I think you are mistaken, Eclipse takes up 3 times the ram VSCode does...I can use VSCode using only 6gig ram even with big projects with native code such as kotlin, java, c, swift, etc..Eclipse will not run on 6 gig ram neither will jetbrains or android studio.
A blast from the past there. I used Eclipse for Java in its infancy while I was at university and thought it was decent enough compared to whatever version on emacs would have been on whatever version of Solaris was on my CS department servers.
A couple of years later I started an internship at a bank and spent ~3 hours trying to get a project building before someone introduced me to IntelliJ, which I still use every day almost 20 years later!
There does seem to be a lot of hate for eclipse. The complaint I always hear is that it is a pain to use. Personally I’ve always liked it, even though I’ve used the other popular IDEs.
Sorry, but "not bloated" really doesn't enter my mind when I think of Eclipse. The few times I used it for Java programming, it took forever to start up, and the UI was laggy as hell during regular use. Granted, that was about 10 years ago, but on a (at the time) beefy Windows PC.
I (author) wouldn’t say I “forgot” about it. I was there when Eclipse became a thing, and my memories are all pretty grim. Difficult to use, slow, very resource hungry… so I never really paid much attention once I finished school. It probably is better now as others are saying, but I don’t know nor care at this point to be honest.
Ha. I mostly used Eclipse in college. I learned how to compile programs from the Command Prompt (Windows user back then) primarily to avoid Eclipse LOL. It was dog slow and somewhat difficult to navigate
Interesting. I hate Eclipse with a passion, I find the ergonomics so horrendous, and back in the days it was a hog. Maybe on today's hardware it's leaner than webkit based vscode. But the last time I tried to use git with it .. it made things 10x harder than the CLI. It was so bad that I developped RSI in 24h (and I'm a daily emacs user)
It’s possible that Eclipse has had a “Firefox moment” where someone carved it down to a lighter core, but I’ve no reason to check.
Seconded on the ergonomics. They were a joke. Longest inputs of any IDE I’ve ever used. If your sequences are longer than vim you need to get your head examined.
eclipse was a child of the java components era, even a trimmed down eclipse would still have tons of baggage
i really despised (to stay polite) everything about eclipse/java culture.. lots of generic layouts and components, nothing i cared about or bringing me dense information about code. way too much chrome and perspectives and what not. it was a cultural dead end, the people who "enjoy" working this way are on a different axis from me.. give me emacs+magit where things are right under your fingers and easy to extend.. and people using this kind of tools (i'm sure vim/neovim crowd likes that too even more) produce more tools of that kind
I still love Eclipse, and you can pry it from my cold, dead hands.
The last couple of years, however, it feels like Eclipse is actively getting worse. And I don't mean that it's lacking features. I mean that every new release seems to break something else.
I tried reporting some bugs, but that required signing some kind of soul-selling agreement with the Eclipse Foundation or some other nonsense.
I then tried fixing those bugs, but there is no up to date documentation on how to build the IDE from the myriad of repositories and modules. So I gave up.
Eclips also had (have?) The very interesting mylyn plug-in which narrows down the code to the context your working within. Think collapsing everything in eg the project tree and also functions within files.
This context is built up based on what part of the code you work on.
My experience with Eclipse, about 10 to 15 years ago, was the exact opposite. It was incredibly bloated. With some combination of plugins installed, it became unusable. At a previous company, we were using some sort of Scala plugin, and Eclipse couldn't even keep up with my typing! I moved on to IntelliJ around that time.
All of the JetBrains users sitting around comparing notes, trying to figure out what was wrong with our coworkers that they thought eclipse was worth using, let alone defending.
JetBrains has plenty of problems, which they seem to want to address but I fear Fleet won’t fix, and I lament but understand people wanting something lighter these days, but eclipse isn’t even in that conversation.
Additionally, I always felt the whole Eclipse "user experience" was terrible. Setting up a project was a mess. The default layout left a tiny window for code. The default fonts were bad. I could go on.
I should fire it up, I haven't tried it in a while. It was the only thing I could use that seem to accurately (more or less) index large projects that you, uh, had some issues compiling and just want to navigate around and look through the code. now I mostly just use rg for big projects, inside of neovim
Honestly, I feel like the primary reason why IntelliJ "won" over Eclipse and Netbeans was that it was first to market with a decent-looking dark mode. Back when Eclipse and Netbeans were as stark white as Windows Notepad... and caught with their pants down as developers abruptly decided en masse that white backgrounds were over, and every app needed to be dark mode first.
Hell, Eclipse STILL doesn't really have a nice dark mode. The actual editor view looks okay, but the dark mode feels very bolted-on to the surrounding UI.
I think this is the primary reason why VSCode is eating the world today. People will talk about the plugin ecosystem and all these other community inertia advantages. However, VSCode was exploding in popularity BEFORE that plugin ecosystem was in place! If we're really honest with ourselves, we flocked to because it was even more gorgeous looking than Sublime Edit, and without the nag modal to pay someone 70-something dollars.
JetBrains “won” because of code inspection tools and code completion that was light years ahead of Eclipse and Netbeans. I remember in my Java days I used to be able to do in a keystroke what my Eclipse friends did in a dozen dialogs.
I don't disagree, but my anecdotal experience from working with peers is that the overwhelming majority of IntelliJ users never learn a small fraction of the keyboard shortcuts and advanced tooling.
I really do believe that for most people, IntelliJ is basically a VSCode that: (1) has a better debugger and some more polish around Maven/Gradle integration, and (2) came out 10+ years sooner.
But ~10 years ago, everyone I knew was flocking over because IntelliJ felt less slow and bloated than Eclipse, and its dark mode UI was more attractive in comparison. Then it became the more-or-less official way to develop Android apps (back when Android's U.S. market share was a lot higher), and that was all she wrote.
I'm shocked to hear you describe it as "not bloated". Eclipse took many seconds to start up, responded slowly to typing, and used huge amounts of memory. It was by far the slowest of any application I had used. I used it when I had to, but never got comfortable with it because it was just way too slow.
One thing these IDEs had was an integrated debugger.
It seems Unix/Linux really got a nice integrated debugger with ann IDE and gdb is powerful, it is very cumbersome. Hence, it seems there is a lot more printf debugging on Unix, and less use of debuggers than say on Windows where Visual C++ and Borland Turbo C++ both had very easy to use debugging integrated into the IDE.
Agreed, for the most part debugging has gone backwards (aside from Xcode, Visual Studio 20xx) and was always pretty bad on UNIX. Still amazes me that there isn't a really nice, batteries included TUI debugger (e.g Periscope!).
I do wonder what the easiest, most straightforward path to a full TUI IDE would be today. Perhaps starting from the codebase of a lean graphical IDE like Lapce and adding a TUI-powered backend. (Note that text editors do exist with that kind of interface, the real gap is wrt. the IDE features including LSP and DAP interop.)
Turbo C/C++ was my first IDE, when you know all short cuts, it was quite fast. Then came DJGPP with RHIDE...and for many years, IMHO, Visual Studio 6 was best for kid ( and window user ) like me.
Visual Studio and XCode are the closest experiences to “first-class IDEs”, reminiscent of the Borland stuff from the early 1990s. They offer tight integration with the native toolchains and a set of menus that mostly make sense. Environments like VSCode or Emacs are a generic platform for text editing and file manipulation, a lowest common denominator for a variety of languages, workflows and tastes.
30 years ago, I used Trash'em One on the Amiga. It was a text editor, 68000 assembler, debugger and memory monitor in one.
I preferred it over its predecessor Asm One (which had been based on Seka), but I don't remember what feature it was that made me switch.
For me, the closest modern successors to the Borland suite are Visual Studio (not VSCode) and the Jetbrains IDEs. The feel like they're the only one with a holistic, batteries included, design that actually focuses on debuggability.
I actually feel that the terminal-based focus of modern FAANG-style development actually hindered proper tool development, but I was never able to explain it to anyone that hasn't used Borland C++ or Borland Pascal in the past, except maybe to game developers on Visual Studio.
I guess it's caused by the "brogrammer" culture of Silicon Valley, where you would get hazed if you dared using a GUI-based tool.
Also, being more focused on open-sourcing their tools (because other companies do not open source them, therefore being un-cool), which begets a "simpler" and "engineeristic" approach to UX, which do not need UI experts and designers.
Except maybe Apple, all the others are service-oriented companies. They run heterogenous pieces of code on their servers and their ideology is “move fast and break things”. It’s a hipster culture that reinforced the use of 1980s “video terminal” editors and CLI tooling because they were supposedly more flexible for their workflows.
Lots of companies end up with their own internal tooling. They have their own build systems, packaging systems, release systems, version control, programming languages, configuration languages, everything.
Some even have their own editors.
There is a lot of value in picking a transferrable editor and using that. From that point it becomes "what is the best editor that will _always_ be available". Emacs/Vim fit that.
Then the muscle memory can begin to grow, and there is one less bit of friction in starting a new job.
One of the best pieces of advice I received was "pick an editor and go deep".
> One of the best pieces of advice I received was "pick an editor and go deep".
Agreed, I'd be infinitely less productive if I couldn't use the editor I learned to master in the past 20 years.
A corollary to that would be "pick a company that lets you use your own editor". There's lots of friction from IT departments towards emacs and vim. The package/plugin system is a security nightmare with lots of potential supply chain attacks and more importantly no trusted vendor to blame when something goes wrong.
C++ Builder versus Visual C++ for RAD GUI development.
I never understood why Redmond folks have so hard time thinking of a VB like experience for C++ tooling, like Borland has managed to achieve.
The two attempts at it (C++ in .NET), and C++/CX, always suffered push back from internal teams, including sabotage like C++/WinRT (nowadays in maintainance as they are having fun in Rust/WinRT).
The argument for language extensions, a tired one, doesn't really make sense, as they were Windows only technologies, all compilers have extensions anyway, and WinDev doesn't have any issues coming with extensions all the time for dealing with COM.
Or the beauty of OWL/VCL versus the lowlevel from MFC.
DevDiv vs WinDev. The Windows group maintains the C++ compiler. So you get the resource editor for dialog templates and that’s about it. And that actually got worse from Visual Studio .NET onwards, my guess is that it got took over by the DevDiv people when they unified the IDEs.
Windows could have been like Android, regarding the extent of managed languages usage and NDK, if DevDiv and WinDev had actually collaborated in Longhorn, but I digress.
Those Borland IDEs, a show of hands for Turbo Basic as well, were the main reason why I never liked the UNIX development experience, until a professor showed us XEmacs, at the time much more feature rich than Emacs, and vi was still vi, not vim.
Thankfully with KDevelop, Smalltalk, and when Java started to make IDEs more common on UNIX, I no longer needed XEmacs.
Ironically for all IDE-haters, even James Gosling, inventor of XEmacs, says people are missing out not using IDEs, he surely moved on from Emacs ecosystem.
Nit: James Gosling implemented Unipress Emacs aka. Gosmacs, not XEmacs (with a lot of licensing sturm-und-drang). XEmacs was forked from Gnu Emacs at Lucid, by jwz (Jamie Zawinski)
Seems a bit quick to dismiss modern TUI editors. Emacs in terminal mode has feature parity (almost?) with the GUI version.
And by the way classic curses like menu bar can be opened in text mode with M-x menu-bar-open which is bound to <f10> by default. You can even use mouse with xterm-mouse-mode.
The one he was looking at was text menubar emulation which is pretty powerful too if you take a minute to appreciate it.
30 years ago people were using Interface Builder already. Admittedly not that many, but the drag and drop interface is still there integrated into Xcode.
They were, and had it not been for Apple's reverse acquisition, it wouldn't be there in Xcode today.
My graduation thesis was porting a visualization particles engine from NeXTSTEP/Objective-C/OpenGL into Windows/Visual C++/OpenGL, as the department was seeing the end of NeXT and they wanted to keep the research going on.
My supervisor had a NeXT Cube getting dust on the office corner, waiting to be collected.
I loved Turbo Pascal, but to me the high point of Borland's tooling was Delphi (1995). I don't want to sound like old man yells at cloud, but every time someone says that building GUIs with Electron is so easy compared to native apps, I just wished they experienced Delphi in its prime.
There are some very short/simple demos on YouTube:
> but every time someone says that building GUIs with Electron is so easy compared to native apps, I just wished they experienced Delphi in its prime.
Every time someone says that, I mention Lazarus. I stll get a thrill out of using it (one of my github projects is a C library, and the GUI app is in Lazarus, which calls into the API to do everything).
The problem I find with Lazarus is that it seems to be slowly dying; yes, they still work on it, but feature-wise they are very behind what can be done with HTML+CSS and a handful of js utility functions.
A wealthy benefactor could very quickly get Lazarus to the point of doing all the eye-candy extras that HTML+CSS let you do (animated elements, for example).
I will happily fill an hour with trash talking Microsoft, but getting the father of Delphi on board is one of the shrewdest things they’ve managed. I wish he’d found a different project to sink his teeth into though.
We used Turbo Pascal and Turbo C++ for my high school classes, and I have very fond memories of both. This must have been on Windows.
Borland really had a series of these fantastic products, it's a shame they are no more. The only modern company in this space is JetBrains, it seems, so the niche is small.
Turbo Pascal and Turbo C++ are still used to this day in some high schools and even college intro courses. Of course nowadays you need Dosbox to run them on modern computers.
I found myself lack of energy and time stepping into my 40s and vowed never to waste time “learning” cool editors such as Vim and Emacs.
VSCode is now my one stop editor of choice on Linux and VS on Windows. I also use Jetbrain editors for work.
I’m done. For people like me, who write SQL and Python for data pipelines, the Jetbrain IDEs are no-brainers. We don’t actually get the time or energy to do a lot of side projects so it doesn’t make sense to learn advanced editors such as Vim and Emacs: 1) These two need a lot of muscle memory just to start using it, but we don’t use it on a daily basis, 2) I’m not smart enough to write code as if I’m writing this reply so fluent coding experience without mouse isn’t useful for me ——- I have to stop and think hard every few minutes anyway.
I'm in my late 30s. So maybe not so far away from the age of lack of energy :P
I like JetBrains a lot. Things work seemlessly and easily integrate with external tools that make up the whole experience. But from 2012, I tried to rely as much on shortcuts as possible, for one simple reason, the mouse.
There is no problem with using the mouse. But everytime I have to use while focusing and coding, I find that that small gesture to move my hand from the keyboard to the mouse a bit flow breaking.
I have to move to the mouse, do a thing or two, then find my way back to the J key notch.
I like what NeoVim and emacs bring with regards to the reliance on the mouse. They allow for maintaining the same posture most of the time and focus only on typing.
I dislike how brutal they are at learning how to use them to full potential, and that making them into IDEs takes ages of IDE building rather than project coding.
I like Helix. Which takes a lot of inspiration from Vim/NeoVim/Emacs. But require no configuration to get you going right away.
The documentation is easy to read, as of now there is no plugin system but there is a builtin integration with a lot of LSP servers for most of the popular languages by default.
Keys and navigation is easy, it even shows a helper popup to show you which key to use next.
My suggestion is, if you ever want to start a new silly project, and you're feeling free to take it slow for 2 days. Try using Helix on said project.
PS: Helix isn't fully complete by any means, but it really is capable of doing everything you want in many projects without being a hindrence if you can adapt to the lack of some built-in features like git and file tree. Its annoying but I am less upset about it and use alternatives
IntelliJ (and the whole Jetbrains suite of IDEs), has one of the best VIM plugins I've seen in an editor. It's hard to say what it does differently to others, but I've rarely encountered a situation where it does something common in my workflow differently to (neo)vim. It's just pleasant to use and gets out of my way, and has a nice method of configuring whether a shortcut should be handled by the IDE or the VIM plugin when they might conflict.
I've found multiple features and motions that do not work the same as in (neo)vim and end up breaking my flow a bit.
However, I have to agree it is probably the best vim plugin I've seen anywhere, and is life saviour for me :)
I was looking for this comment. I'm very happy with the combo of IntelliJ features and vim movement commands.
The only inertia vim adds to my workflow is escaping into command mode. I have a 'jk' shortcut combo rather than escape, but if I'm hammering away I often mistime it and need to backspace out my jjkk or whatever.
Honest question: are other jetbrains IDEs "feel" similar to the Android Studio one that can be downloaded for free?
I installed it a couple of weeks ago to modify some android app, and boy it gave me vibes of the old Eclipse : sluggish Java feel , with "stuff" happening all around and being slow to render basic editor stuff.
> Honest question: are other jetbrains IDEs "feel" similar to the Android Studio one that can be downloaded for free?
Android Studio is generally one generation behind mainstream Intellij and has its own modifications on top of it.
It depends on your target language. With the exception of CLion, all other forks of Intellij work much faster than Android Studio from my experience.
Funny because I entirely agree with you, even though I do the exact opposite. Everything I write is in vim because I'm too lazy to learn an IDE which may or may not still be around in 5 years. I use 0 plugin and 6 lines of .vimrc config which I know by heart, so I don't care if I'm using it locally or remote, I can always get started in 1 minute.
I tried to install plugins but there is always something that fails somehow. Nvim distributions don't install and run out of the box for the most part, I get weird errors regarding lua or something and just give up. As for VSCode I wrote my first python project using it a couple weeks ago (I'm not a developper) and it's alright but a few things annoy me, like the integrated terminal and some things getting in my way.
At the end of the day, each of us should chose whatever we feel comfortable with. I spent maybe 2 hours in my life learning vim movers and never looked back. I don't even use tmux or anything, just open 1 or 2 terminal windows and alt+tab between them, with the occasional :split or :vsplit command.
There's a strange dance of IDEs coming and going, with their idiosyncracies and partial plugins.. you still have to invest and devest everytime a new wave comes. Meanwhile emacs is still mostly emacs. I understand the dread emacs can impose on you, from old keybinding cultures and elisp but there's something timeless and freeing in emacs.
Yes I used emacs at school 15 years ago, and I agree that it was great for development ; with OCaml at the time (and also C with gdb integration, and 68k assembly later on) we shared a few tips with other students and the workflow was convenient for dev.
But vim is ubiquitous which is a huge plus when you are like me always connected remotely on a different machine. Once I learned a few shortcuts I never went back (and never dug into the tool itself actually, I can't even run a macro ; I'm still faster than most people I know with an IDE).
The only thing I was impressed with is I think phpstorm, watching a laravel dev crafting an SQL query. If I ever get serious about developping I would look into this kind of things (not just for SQL but also framework and module functions), especially if I can get vim movers, and a screen that isn't bloated. VSCode displays like 15 things and I'm only interested in 1 of them 99% of the time for example.
- for ansible on reasonably large projects (a dozen of roles) it was never a problem ; you have to understand how the project has been structured and be able to use grep and find though
- when I was playing around with os161 I don't remember it being an issue. Although for this particular case I did use the cscope vim plugin which is helpful to navigate through the codebase (there are equivalents for various languages). Not sure if os161 would qualify as "large codebase" but it's a bunch of files in a bunch of folders.
If you’re dealing with a large C or C++ codebase, Vim’s native cscope support scales way better to large codebases than the newer language server solutions from visual studio code, etc.
> There's a strange dance of IDEs coming and going [...]
Intellij IDEA 1.0 was released in 2001 - is still in active development - and as far as I know the keyboard shortcuts are still the same (depending on the configuration one chooses)
The first Microsoft Visual Studio release was in 1997.
XCode was first released in 2003.
Fog of the future not withstanding; most people aren't going to have been using IDEA since 1.0.
If you learned Java between 2001-2012 then the default was Eclipse or netbeans.
So you should not be comparing IDEA from 2001 to today (or any individual IDE), you should be comparing the IDE landscape or ecosystem of 2001 to today, and part of that analysis should be a requirement to weight IDE's based on popularity and the recommendations of established institutions (academia, companies).
I only wanted to mention that certain IDEs still used today are not coming and going but have been around for decades and are still more or less the same (keybinding, etc).
Maybe I just don't understand your comment - even translated it still confuses me tbh. (I'm not a native speaker). Sorry if you feel offended I guess.
Not offended, but not understanding because of translation is fair.
My entire point was that it's unusual for someone, especially someone who is new to IDE's or programming in general, to pick something brand new. As educational institutions will take time to change from the popular thing and most companies will also need time to adjust.
Distilled: my point is that you should not compare IDE release dates to the stability of IDEs vs Editors. -- you must consider the entire ecosystem of each at the time.
Another perhaps good example to conclude this would be something like python backends. One could (unreasonably) argue that Python has been around since 1991; but backends typically were written in Perl or PHP for a very long time. It wasn't until 2008 or so that Python started making headroom for web backends (ruby around the same time) -- The possibility existed but the popularity wasn't there.
A similar argument could be made for Sublime text (which is uncommon these days) but was extremely common in 2010. Or Atom, which doesn't even exist any longer but took considerable market share from Sublime in its heyday.
It's not fair to say "x has been around for y time therefore it is not changing", the ecosystem does change and it has darlings and detractors.
The only exception to this ecosystem over tool argument I can think of is probably visual studio itself as that was a monoculture and stuck around because of that.
We did a bakeoff of Eclipse, NetBeans and IDEA upon its beta in 2001. IDEA won hands down and is still the IDE of choice among the developers who work on our codebase.
Clearly theres something I have failed to communicate, you have an experience that does not match the most programmers and I pointed that out.
As I stated in my post above, (after someone asked me a direct question) that: despite answering the question, it was the wrong question and not the point I was making.
It is not really the learning curve, but it takes just too much time to set up to match VSCode or VS or Jetbrain IDEs, plus it requires too much muscle memory to use it effectively. It's difficult to stick unless one uses it frequently. I simply can't afford it.
TBH everything on Linux/Unix variant (except MacOS) is like that, there is no open-box solution. There is always too many configurations and even begin with (even VSCode is too configuration heavy for my taste but I use it as my Linux VM is light). This is definitely good in its own sense (more powerful), but most of time I just want something to work and concentrate on what I really want to learn. I mean, if I really want to learn how an editor works, I'd go ahead to build one myself, but in the mean time I just want to write a toy compiler so please just let me do it.
One of the nice things today is that DAP and LSP (while very much designed around VS Code's internal extension APIs), the things that use them are basically duct taped to tiny VS Code extensions over JSON RPC. They can and will outlive VS Code as the IDE of choice.
While on the surface that means that language support doesn't have to be designed for a particular editor/IDE, what's less obvious is that LSP (in particular) can be used as a generic IDE plugin API. I've heard of some non-language support extensions (ab)use LSP to get cross-editor support with the same codebase.
> you still have to invest and devest everytime a new wave comes
Not really... When a new editor/IDE comes and replaces the rest, it's because it seduces the original userbase of the previous IDE, so usually the transition is smooth (same shortcuts, similar functionalities and ergonomics). Moreover, I find it weird to "invest" time in an IDE, usually you don't really need to, you learn the basics of it and you're good to go for years.
> There's a strange dance of IDEs coming and going, with their idiosyncracies and partial plugins.
The Language Server Protocol [1] is the best thing to happen to text editors. Any editor that speaks it gets IDE features. Now if only they'd adopt the Debug Adapter Protocol [2]...
For me, cool editors are vscode and jetbrains. I've tried to make them my default editors many times but always go back to vim (which I've been using for decades).
I agree that since you are well versed in Vim, it doesn’t make sense to switch unless for something vastly better —- which I don’t see in any existing product.
I'm a heavy Vim user but I agree with your sentiment. I learned Vim during some down time in my first job out of college. It is a great skill to have in my opinion. It helps me complete complicated text editing quickly and easily, especially operations that I otherwise would never have attempted without it, but I never would have had the time or energy to learn it later in my career. I don't think learning Vim or Emacs is a waste of time but I can see how it is definitely not a priority when you have so many other things to do and little time to do them.
I am a life-long vim-er and I only use probably 30% of its features and thats ok. I learn new things all the time, sometimes adding them to my repertoire, sometimes not. There's so much time that can be wasted if you mess around with configuring tools but either fail to remember to use them or fail to get them set up. I wanted to set up ctags and tried a few times, but fell short of memorizing the forward-back shortcuts and got frustrated at the delay when it goes off scanning my HDD instead of the local code 1-2 directories away. so I just gave up.
I started with emacs. I love the buffer / windowing system and the on-the-fly macros. Also being able to do everything with the keyboard.
But the time spent getting multimode up or good autocomplete when you can simply fire up something like jetbrains IDE, having most of your ecosystem tools integrated the second you launch it makes the decision to switch easy.
Also, dev machine tend to have a lot of resource nowadays so the RAM hungry IDEs are not a problem.
I wouldn't consider myself a vim user, but learned the basic keybindings awhile back (IMO modal editing is the correct way to edit). Knowing those makes it much easier to bounce between IDEs. Sometimes I don't realize if I'm in VSCode or IntelliJ (especially the new UI) until I try to run something.
> I’m not smart enough to write code as if I’m writing this reply so fluent coding experience without mouse isn’t useful for me ——- I have to stop and think hard every few minutes anyway.
I've worked with good programmers who literally hunt and peck. It drove me nuts, but as most will agree, typing is rarely the bottleneck when programming. I've also worked with people who I would consider vim power users, and while they were faster at typing out some tasks than I am, I found they were often typing/moving around the file as their method of thinking. Whereas I might reach for the mouse and scroll around instead. Again, typing speed is rarely the bottleneck.
VSCode and JetBrains are better overall, but many of the good editing features of Vim are available via their respective Vim emulation plugins. It is still worth it to learn and use Vim mode for efficiency (in my opinion).
I have tried to use VSCode more, but, the original emacs keyboard movement is burned into muscle memory. VSCode has a keyboard mapping for emacs, but, its does not feel right. At the end of the day, who cares? Its just a tool, whatever works.
VSCode has solved so many problems for me. The only time I step out of it is when I run into something that might be a configuration issue. For instance, if I’m programming an Arduino, and it’s not working, it’s worth hoping over to the official Arduino IDE to make sure that the “supported” way doesn’t work as well.
Otherwise, VSCode solves almost all my problems, and virtually all my key-bindings are identical.
they're really not that difficult, its not a badge of honor to use them. I used xemacs and liked it ages ago, and I still use raw vim for quick edits or views occasionally. The reality is modern ides are simply better for 99.99% of use cases. I might not use idea for open log files that are massive, and that's about it.
Likewise. I'm 46, and started my career in the late 90s using mostly light editors on Windows (Homesite, etc). Along the way, I've tried a few times to really dive into vim, but just couldn't see the advantage over editors like VS Code, Sublime, Atom, or some of the editors popular before then like Eclipse. However, I do feel comfortable enough in it that I can edit files on servers/containers, which is something I feel is useful for everyone.
wow, i had the same experience. reaching my 40s and decided to drop all the cool kids stuff. i used to have emacs/scheme evangelist phases in my life, now i do all my coding using enterprise languages and tools.
Turbo Pascal and Turbo Prolog - those were the days.
Borland had the greatest products, and the accompanying books were always well written, used beautiful fonts, and, not less important, smelled nice.
If my memory serves me right, Borland even released their Text User Interface (TUI) library for developers to use in their own applications.
At least the programs in the screenshot have actually useful and visible scrollbars. Seriously, scrollbars are super useful and should never be hidden, they both provide information you want to see and actions you want to do, why is everything trying to make them as subtle as possible today, even most Linux UI's which I'd expect are normally made more for usefulness than "design trends"?
GitHub's Android app doesn't even show scroll bars. And no scroll grab or snapback in apps even when there is a scroll bar. Am I the only person who scrolls back to check something and wants to quickly return to where I was in a document? Even if just FF on Android had this I would be happy.
On desktop we can drag scrollbars but I can't imagine what it's like to use modern 4-8px action area scroll bars if you have fine motor control challenges.
I just don't understand how we got to this point. Do people not use the apps they write?
This must be a bug though. If you unfold hidden comments, you jumpt to the BOTTOM, where you just WERE, rather than the top. So you scroll up, with no scrollbar, frantically, because you don't know how far you have to go. Until you reach the top - and you drag down ONE MORE TIME, because you're scrolling frantically, so the whole thread reloads, and everything is folded again, and you're back where you started.
On Linux this depends on your theme really, all the themes i use have scrollbars - e.g. here is an example with Gtk3 (which IIRC introduced the "autohiding scrollbars" to Linux desktop)[0]. It is "cdetheme-solaris" which i think is from [1]. I might have modified it a bit though. Though normally i use Gtk2 apps with a modified "cleanlooks" theme (a screenshot from Lazarus[2] i made a couple of days ago shows it - including the scrollbars :-P).
> there are a few things that VSCode doesn’t give us.
> The first is that a TUI IDE is excellent for work on remote machines—even better than VSCode. You can SSH into any machine with ease and launch the IDE. Combine it with tmux and you get “full” multitasking.
I definitely disagree with this sentiment. At my last job, I had to do most of my work on a remote server (because it had a GPU), and I found VS Code far more pleasant to use than plain old SSH. People recommended using an editor on the server side or freaking around with Win SCP / Cyberduck, but VS Code was just so much better in so many ways.
Because of VS Code's web roots, it can easily run its frontend on your own local computer while running its backend somewhere else. This means that most common actions, like moving the cursor or selecting text, can be done locally, without the need for a round trip to the server. The operations that do have to be executed remotely, like saving a file for example, are properly asynchronous and don't interrupt your workflow. Everything is just far snappier, even if you're working from home, through a VPN, on barely working WiFi and an ADSL line.
As a bonus, you get fully native behavior and keyboard shortcuts that you'd expect from your platform. Things like text selection and copying just work, even some of your addons are carried over.
Using the editor on the server from a remote connection is silly. However VSCode is not unique. On my local Emacs I use ssh via tramp [0] to browse files on the server and then edit localy. HOWEVER I also have physical access to my server. Emacs then gives me the added benefit of being able to run in terminal on the physical server without any window manager installed.
> Using the editor on the server from a remote connection is silly.
In my experience, this is the best way to do remote work. The alternative is to either not work with remote resources (data, hardware, etc), work locally and sync changes to remote, or work locally with a remote mounted file system (unless you need remote hardware).
For the parent, they needed GPU access, so they had to run remotely for hardware access.
I normally need particular data that is too big to move locally, so I like to work remotely for that reason. I could remotely mount drives via an SSH Fuse mount, however the IO speed for this method can quickly become a problem. For me, it is a much better experience to either use a remote web editor (rstudio server), VSCode remotely (which is a remote web editor over ssh), or vim. With web based remote editors, you still draw the screen locally, but get updates from remote. And more importantly, compiling and building takes place remotely.
I find this method much better than either pure remote access (VNC/RDC/X11) or local-only editing with syncing code and/or data. But it very much depends on your work. When I don’t need to work with remote data, a locally managed Docker devcontainer provides a much better development experience.
In my experience, it's the worst way to do remote work. There are so many better solutions.
If TRAMP is too slow, just mount the remote filesystem locally using FUSE somehow. Use SSH to run processes on the remote system like compile and run the program. No need to run the text editor on the remote system.
You can also do it the other way around: have your remote system load your local data. I developed a small bare metal OS this way. Ran the cross compiler locally, had the output go to some NFS mount which was also available via TFTP. Booted the target system with PXE.
Running a text editor on a remote system is good for one off things and maybe as a last resort, but that's it.
Is there an efficient way to do "Find in files" from a vim or vscode instance running locally and editing+compiling remote files via ssh ? Preferably something that runs instantly for 1 GiB repos ?
Haven't tried on exceptionally large repos, but in VSCode since actual find logic is on server, it should work simply fine. If I remember correct, even on vscode.dev (in browser with no server), your browser downloads the search index and then search and navigation are fast. Though it may struggle with very large repos.
I’m not sure what you mean by vscode running locally with editing via ssh. I’m fairly certain that when you do a remote connection in vscode, it literally runs the vscode program remotely and you are just connecting to a tunneled web interface. The only thing running locally is the Electron browser shell. So, remote “find in files” is running remotely, so it should be as efficient as it would be from that side.
That said, you can also open a terminal in vscode and use grep. If you’re running remotely, the terminal is also remote. That’s what I normally do.
> just mount the remote filesystem locally using FUSE somehow
This is the step that never works consistently for me. There is always some amount of random extra latency that makes the this workflow painful. I work with some extremely large data files, so random access to these is the primary issue.
In general, the idea is that it is often better to do compute where the data already is. My experience is that you should also do the programming closer to where the data is as well. This tends to make an iterative development loop tighter.
But this is highly dependent upon what you’re doing.
That's a different thing, though. You don't edit the data in a text editor interactively, do you? I would do any interactive editing with a local editor and then fire off remote processes to operate on the data.
It's funny because my reasons against using a text editor remotely are exactly the same: to make the development loop tighter. I am very upset by latency and always try to remove it where possible. I think this is the kind of thing where we'd need to look over each other's shoulders to understand our respective workflows.
> You don't edit the data in a text editor interactively, do you?
That’s exactly what I’m doing. The code is written on the remote server. VSCode’s remote setup is actually very good at this. Mainly because, it is really a web editor that is hosted remotely and you use a local browser (Electron) to interact with it. The processing loop then happens all remotely.
But really, I’m talking more about data analysis, exploration, or visualization work. This is when I need to have good (random) access to 100’s of GB of data (genomics data, not ML). For these programs, having the full dataset present during development is very important.
If I’m working on more traditional programming projects, I can work locally and then sync, but recently I’ve been using more docker based devcontainers. These are great for setting up projects to run wherever, and even in this case, the Docker containers could be hosted remotely or locally (or more accurately in a VM).
Yeah I used to work with genomics data and never did I think I needed to have part of my text editor running on the high performance cluster.
I think people are just talking about different things and confusing each other. The original comment I replied to was arguing against SSHing in (or vnc or something) and running the text editor there. VSCode isn't doing that. It is running the interactive part locally. It's hard for me to understand why it needs a server part, though. If you want to edit something locally it has to send it across the network. There's no way around it. It seems like six of one and half a dozen of the other.
Have you actually used vscode remote? If not you should. If you have all I can is that I’ve personally used all the solutions you are mentioning and for me vscode remote is the top bar none even for very large repos.
I worked at a place that had a half built distributed system that we still needed to use (many bidders buying Ad space from a API based market). one great thing with tramp is that you can tramp into multiple systems simultaneously. So you are editing say files from 5 different systems (tweaking the yaml or whatever) at the same time. You could then start eshells on each of those systems at the same time. It made it really easy to adjust the settings and restart multiple apps really quickly (big screen, 5 files on top, 5 shells on bottom). I always get a kick out of people saying "you use that! you need to switch to editor X it has feature Y!" And me thinking yeah, that feature has been in emacs since before you were born. it is getting a bit crufty in its age though. Its main attraction is for people who like LISP. There a project called lem (IIRC) that is rewriting it in much higher performance Common Lisp.
What does it mean "more powerful" ? Do you mean in terms of productivity ? It probably depends on your task anyways. In 2023, it's still a pain to have decent debugging in Vim. For pure text editing, I can believe you, but for software development, I highly doubt it.
The difference here is that VisualStudio code fully runs the GUI on the local machine and only file IO or external programs (compiler, the actual program being devleoped, ...) run remotely. Thus the UI reacts promptly to all interactions and many of the remote interactions happen asynchronously, thus even saving a file will not block further actions.
Whereas any non trivial X application does work in the client, thus even basic interactions have a notable delay, depending on connection.
It shows you never used slow telnet sessions over modems.
There is no difference between doing this over text or graphics, in terms of the whole setup regarding network communications for data input and output.
VS Code isn't doing this with text or graphics, though. In X terms, it's running both the client and server on your local machine. It simply doesn't put the network boundary in the same place as an X application.
VS Code's "backend" that runs on the remote machine is rather only in charge of more "asynchronous" operations that aren't part of the UI's critical path, like saving files or building the project. It doesn't speak anything as granular as the X protocol.
Again: The key difference is that in VS.Code the UI runs local, thus all UI interactions are "immediate" and there is no difference between local and remote operation. Yes, IO has latency, but where possible that is hidden by the UI (possible: saving a file happens without blocking UI; not possible: loading a file requires the file to be loaded .. but even then the UI can already prepare the window layout)
Thisnis very different form a system, where each keystroke and each menu action has to be transfered first, before the remote side can identify the needed UI update and send that back
Johannes's point was, I believe, that using VSCode remotely works fundamentally different than using apps remotely via X. I don't think he is confused about how X was designed.
Arguments to authority aren't appealing. Arguments from logic are. The fact is that X and VSCode's remote protocols are designed very differently, and in high-latency and high-jitter connections (and many low-bandwidth ones), VSCode's protocol is simply better.
You're assuming someone would be running Emacs on the remote machine talking to a local X server in order to edit files on a remote machine, but people would generally not do that, but use something like TRAMP, where Emacs would be running on your local machine, but accessing remote files.
TRAMP only requires ssh or telnet (or scp, rsync, any number of other methods) on the remote machine.
I'm sorry to say I'm as confused as I was before I read these sentences.
Let me try to rephrase: with X Windows, the UI server runs on your local machine, while the UI client runs on the remote machine (e.g. your application's server). Is that correct?
Thanks for elaborating, it helped a bit and now this section of the Wikipedia article fully clicked for me:
"""The X server is typically the provider of graphics resources and keyboard/mouse events to X clients, meaning that the X server is usually running on the computer in front of a human user, while the X client applications run anywhere on the network and communicate with the user's computer to request the rendering of graphics content and receive events from input devices including keyboards and mice."""
I'm surprised pjmip is missing the point here. Or maybe I am
> Instead of sending streams of bytes to render text, it sends streams of encoded X Windows commands to draw the UI.
(Simplified) VSCode is sending no bytes to a server when you're editing a file. The entire file exists on the client, you can edit all you want and everything stays on the client. Only when you pick "save" is a data sent to the server.
My understanding with X Windows is as you mentioned above, you press a key, that key it sent app on another machine, that other machine sends back rendering commands. Correct? Vs VSCode, you press a key, nothing is sent remotely
Note: There's more to VSCode, while it doesn't have to send keystrokes and it is effectively editing the file locally (so fast). It does send changes asynchronously to the remote machine to run things like the Language Server Protocol stuff and asychronously sending the results back. But, you don't have to wait for that info to continue to edit.
The fact that it is easy to confuse the server with the client in X, it does not change the fact that the XServer and XEmacs are running on different computers, so each interaction is a round-trip.
XServer and XEmacs are both running on the client machine.
Also it is impossible by laws of physics by using distributed computing, not having each keypress and its display on a rendering surface, being a two way street.
By the "client machine" where XServer and XEmacs are both running, do you mean the machine where the human user is entering keypresses and viewing windows? Or do you mean the machine where the files are ultimately getting edited? Clearly, there has to be something running on each of the machines, since otherwise one side would have nothing to connect to on the other side. What is running on the machine opposite the "client machine"?
The idea with VS Code is that neither the keypresses nor the displayed windows are being sent over the network, but are kept within the same machine where the user is entering or viewing them. Only the file data (or debugger status, etc.), which are cached and far less frequently updated, are sent over the network. Are you saying that XEmacs can also function remotely in this way, with neither keypresses nor displayed windows sent over the network?
There’s some confusion in some of the replies here. The point this person is trying to make is that you get the remote machine’s key bindings, not the local’s. That’s an artifact of the experience being a remote desktop.
It's similar in outcome (doing "stuff" remotely), but not the same architecturally.
VScode runs on the computer in front of you, and it _does not_ send key-presses or other user input over the network at all. Instead VScode sends file-changes over the network to the remote, and executes commands on the remote (e.g. SSH's in and runs 'gcc ...').
With X, XEmacs is not running on the computer in front of you; it's running on a computer far away. Every key-press and mouse click must be transmitted from the computer in front of you over the network, received by the remote computer, then a response sent from the remote to the computer you're interacting with, where it'll be displayed.
In the spirit of what the person you are replying to wrote, you really weren't doing the same thing 30 years ago, because X Windows doesn't really have the capabilities vscode has for remote work. X Windows approach is very primitive compared to what vscode does.
Emacs can edit files remote to where Emacs runs with e.g. TRAMP. Emacs can also run remote to where the X server runs. Those two are entirely orthogonal to each other.
The resource consumption on the client doesn't bother me one bit. Any minimally decent laptop can put up with that load, on battery power, for hours.
I would agree with “whatever it takes to make the server install leaner, more portable, etc” just without sacrificing many features.
If the server side doesn't run on FreeBSD that's really too bad. If Microsoft makes it hard to improve by not making those bits open source, that's very unfortunate.
This ability also proves useful when trying to do complex package management in an isolated manner with ROS; I ultimately used a remote vs code shell running off the robots OS to just have my ide recognize the many local and built dependencies that requires a full ROS setup.
I've been wanting to try something like that with neovim's remote features, but haven't found the time. Has someone attempted this? If so, how successful was it?
I've always been a big user of powerful laptops because I do like the mobility (allows me to work/browse stuff outside my home office) and I dread the pains of properly synching my files across a laptop and desktop (not only documents/projects, but also configs and whatnot).
VS Code remote in some cases is better than local.
As the remote can be a docker container, so when I have to do some experiment, I create a container takes 5 min to setup. I than can play around, test dozen packages and configs, once I am comfortable commit last version.
If I want to do some quick testing on project by different team, again a local container is setup in 2-10 mins. Once done delete the container and my local system isn't messed up.
Last is obvious use case if you want to test anything on reasonable large data or GPUs. Create a cloud server, get data run your code, tests. Push data to S3 and done.
What were you trying to do with tramp? I’ve used it for coding Common Lisp, together with a remote SLIME session - ie slime-connect - and while I have run into at least 1 limitation with paths, I have a decent enough work around for it. I think the setup was just a matter of setting some customizable variables.
I see. I thought I had some .emacs customized settings I could share, but they're all slime specific. It appears tramp otherwise just works without further configuration - unless I set them in ielm and forgot about them before copying them over to .emacs, but I didn't see anything like that in my ielm history.
I use that all the time in my hobby tinkering pseudo cloud server on a odroid SBC. It feels like I'm literally on that specific computer directly. Plugins like docker work as well
> I definitely disagree with this sentiment. At my last job, I had to do most of my work on a remote server (because it had a GPU), and I found VS Code far more pleasant to use than plain old SSH. People recommended using an editor on the server side or freaking around with Win SCP / Cyberduck, but VS Code was just so much better in so many ways.
I'm not familiar with VS Code setup for remote editing. Does it run LSP on remote and give you full hints, errors, etc. locally?
> As a bonus, you get fully native behavior and keyboard shortcuts that you'd expect from your platform. Things like text selection and copying just work, even some of your addons are carried over.
Selecting text with Shift+ArrowKey or something like that is not a "bonus", it is just a bad text editing experience. Keyboard shortcuts are the way they are on Vim/Emacs not because their developers can't figure out how to bind Ctrl+C/Ctrl+V...
My understanding follows (I don’t use it but I’ve noticed the processes running on other people’s machines). Corrections welcome.
It’s split into a client (web frontend) and server that’s doing all the work. The server can be run anywhere but it’s effectively a bunch of stuff installed in a docker container. When you start an instance for a project, it creates a container for that instance with all the code folders etc bound in. LSPs are running in that container too.
It’s possible to use your own image as a base (you might have custom deps that make installing the requirements for an LSP hard, for example).
The trick they use here is that there’s some base container/volume that has most of the server stuff downloaded and rest to go. Whether you start a normal instance or from a custom image they do it the same way by just mounting this shared volume and installing what they need to bootstrap the server.
It also appears they create a frontend window per server process too. So the master client process starts, you select a project folder, they create a new server container and a new client window connected to it. The frontend client is local while each server can be anywhere (obviously you could run the client with X if you wanted to further muddy that).
> I'm not familiar with VS Code setup for remote editing. Does it run LSP on remote and give you full hints, errors, etc. locally?
Not sure about other languages, but when I use VS Code to develop Rust remotely, it prompts me to install the rust-analyzer extension (which is my preferred LSP server for Rust) to a remote whenever I'm opening a project for the first time. VS Code is able to distinguish between extensions that need to be installed on the same machine as the code (like the LSP server) and extensions that are just making changes to the local UI.
> Selecting text with Shift+ArrowKey or something like that is not a "bonus", it is just a bad text editing experience. Keyboard shortcuts are the way they are on Vim/Emacs not because their developers can't figure out how to bind Ctrl+C/Ctrl+V...
I use an extension for vim keybindings in VS Code. When connecting to a remote host, the vim plugin still works fine, itand doesn't prompt me to install anything on the remote side, since the changes are synced to the remote host at a much higher level than that (i.e. locally mapping "dd" to "delete this line from this file" and sending that to the remote rather than sending the remote the keystrokes "dd" and having the remote determine how to interpret it).
Thirty years ago is 1993, and I was a junior dev using CodeCenter on SunOS. It was a nice editor/debugger with a C interpreter mode that iirc let you inspect aa variable's history and un-execute lines of code.
A few years later I was using SparcWorks on Solaris. When I realised you could pause on a breakpoint and hover the cursor over a variable in the editor to see its value, my brain nearly fell on the floor.
A few years after that I moved to PC development using Visual C++, and then Visual Studio 97 on NT4. Drag and drop UI builders for Windows and Web.
And 30+ years later I still spend a significant part of my working day in VS.
I love the aesthetic of Borland Turbo TUIs. I went back and tried to use TurboVision some time last year. It was not good, to say the least. Would be pretty cool if VSCode were themable to the extent that WinAmp was, so we could reclaim that old style.
In the early 2000s, back in my homeland, high schools were still stuck using Turbo C for programming classes. This was mainly because there weren't many free and lightweight C IDE options available for Windows (I know Turbo C is not a free software technically).
While Dev-C emerged as a possible alternative for console programs and programming contests, it wasn't enough for developing native Windows GUI applications without shelling out for Visual Studio.
This limitation ultimately led me and some friends to explore development on alternative platforms like OS X and Linux. Ironically, even to this day, none of us mastered the WIN32 API.
One nice side effect of modern TUI applications is that they can be distributed via Docker Hub as platform-agnostic applications that just require a compatible color terminal.
E.g. here's my C64 emulator running in Docker (it's a real C64 emulator underneath, but only renders the C64 PETSCII buffer via ncurses, e.g. no graphics or audio output):
611 comments
[ 3.8 ms ] story [ 351 ms ] threadThe second paragraph says: "This time around, I want to look at the pure text-based IDEs that we had in that era before Windows eclipsed the PC industry."
Demos for a couple old versions: https://www.youtube.com/watch?v=NqKyHEJe9_w Demo for Pharo: https://www.youtube.com/watch?v=baxtyeFVn3w
Interlisp-D, Mesa (XDE) and Mesa/Cedar, all shared same ideas with Smalltalk, regarding developer tooling.
Same on Genera with Lisp Machines.
Smalltalk's from the 70s and 80s, and almost certainly had what you're thinking about given it's where both Microsoft and Apple got their foundational ideas (restricted to significantly less powerful hardware), and later unrelated smalltalks retained a lot of now quirky considerations and behaviours. Self inherited a lot of those and is from the late 80s.
So yes, I was also expecting the author to talk about Smalltalk.
I'm using it for 20 years and I think it's the unsung hero of the IDE world.
This article doesn't mention it either as a modern GUI IDE.
It never crashed, allowed me to work remotely if required, integrated with Valgrind, allowed me to do all my tests, target many configurations at once, without shutting it down even once.
Currently it has a great indexer (which is actually an indexer + LSP + static analyzer and more), LSP support if you wish, and tons of features.
It gets a stable release every three months, comes with its own optimized JRE if you don't want to install one on your system, etc.
Plus, it has configuration snapshots, reproducible configurability, configuration sync and one click config import for migrating/transforming other installs.
That thing is a sleeper.
In any case, it's a younger product than the offerings in the article.
[1]: https://www.st.com/en/development-tools/stm32cubeide.html
Yeah, but my gripe was about the closing of the article, which mentioned VSCode. I think the author just doesn't know about it.
Eclipse is my DeFacto C++/Python IDE and I'd love to develop a decent Go plugin for it, too. Maybe someday.
I’m sure it’s really good these days. But I’ve moved on now and my current workflow works for me, so I don’t see the point in changing it until I run into issues again.
I developed Java with Eclipse, but the project I did was not that big when Eclipse was not its prime, and it was in its prime when I was experienced enough to be able to "floor it" in terms of features and project complexity.
Now it's just a blip on the memory usage graph when working with big projects, and way way more efficient than the Electron apps which supposed to do 20% of what Eclipse can do.
I really wanted to like Eclipse but gave up on it a decade ago because it required constant management from release to release. I remember one job I had where I didn’t need an IDE all that often and I would spend nearly as much time configuring Eclipse again upon the next time I came to use it, as I was spending time writing code in it.
I’m sure it’s improved leaps and bounds in that time - 10 years is a heck of a long time in any industry, let alone IT. But I do know I wasn’t the only one who got frustrated with it. So myself and others switched to other solutions and never looked back.
It just updates now, and I export my installation XML and send to people when they want the exact same IDE I use.
So basically the same as setting up and configuring a development environment today, except that nowadays it's a lot more centered around the command line and involves a bunch of disparate, half-documented packages/tools from GitHub (and that also inexplicably require 10 to 1000 times more space and clock cycles).
That all said, I have found VSC to be piss poor for tempting out new projects. And some ecosystems like TypeScript really do need a lot of boilerplate before you can ever start on a “hello world” application.
I’ve gotten back up to speed via IntelliJ but it still doesn’t feel as effortless as it did in Netbeans. And way less care and feeding than Eclipse.
Sorry, there’s a lot of “feels” in this post but for me, Netbeans was the one Java IDE that I didn’t have to fight with.
For Java specifically i felt NetBeans was faster and simpler though i bounced between it and Eclipse because i also used Eclipse for other stuff (C++ mainly) so unless i wanted a GUI i used Eclipse. I did stopped writing Java some time ago though.
I did try a recent NetBeans build but i found it much less polished than what i remember from before it became "Apache NetBeans".
Running m1 sonoma
I do agree intellij is memory hungry with multiple projects open and a variety of languages involved, but RAM is cheap enough (and VMs/Docker/K8s hungry enough) that I just don't buy a machine with less than 32GB anyway, so I give intellij up to 6 GB and never give it another thought.
I don't do much android development, but do find Android Studio to feel clunky and slow at times, guessing because of the heavy integration with Android dependencies and emulation, but not really something I know enough about to comment with any sense of authority.
~20 years ago I became an early IntelliJ user. From version 3 maybe? It's hard to recall. I've never looked back.
But I did try Eclipse and... I never got the appeal. For one, the whole "perspectives" thing never gelled with me. I don't want my UI completely changing because now I'm debugging. This is really part of a larger discussion about modal editors (eg vim vs emacs). A lot of people, myself included, do not like modal editors.
But the big issue for Eclipse always was plugins. The term "plugin hell" has been associated with Eclipse for as long as I can recall. Even back in the Subversion days I seem to recall there were 2 major plugins (Subclipse? and another?) that did this and neither was "complete" or fully working.
To me, IntelliJ was just substantially better from day one and I never had to mess around with plugins. I don't like debugging and maintaining my editor, which is a big reason why I never got big into vim or eclipse. I feel like some people enjoy this tinkering and completely underestimate how much time they spend on this.
Writing rails api with a nextjs ui, anyone got any suggestions on alternative paths i should take?
RubyMine on a cancel anytime personal license is $22.90/month (or $229 for a year). That's nothing. I'd say just try it. If you don't like it, you might only be out $23.
I'm not a Ruby person so can't comment on that really. For Java (and C++) it's a lifesaver. Things like moving a file to a different directory and it'll update all your packages and imports. Same with just renaming a class or even a method.
The deep syntactic understanding Jetbrains IDE have of the code base is one of the big reasons I use them.
The plugin conflicts were way more common in the olden days, that's true, however, I used subclipse during my Master's and it was not incomplete as my memory serves. It allowed me to do the all wizardry Subversion and a managed Redmine installation Assembla had to offer back in the day.
It's much better today, and you can work without changing perspectives if you prefer, so you might give it another shot. No pressure though. :)
Trivia: VSCode Java LSP is an headless Eclipse instance.
Eclipse was created over that extremely interesting idea that you can write a plugin to do some completely random task, and have all of it reconfigured on the perfect way for that task.
But you can't have a rich ecosystem of plugins without organizing them in some way, and nobody ever created a Debian-like system for them as it's a lot of thankless hard work.
This is kind of my problem with it. I'll use VSCode for typescript but I avoid it if there are other alternatives. The entire model of VSCode just doesn't jive with me.
Tuning startup heap size could cut upward of 40% off of startup and settling time.
However at home i had a computer i bought late 2003 (which was a high end PC at the time but still) and the program was so heavy i remember despite running it under a lightweight environment (just X with Window Maker) i had to choose between Firefox and Eclipse because otherwise things would crawl due to the excessive memory use both programs made :-P.
Eventually i switched to other IDEs and forgot about Eclipse. But i did try it recently again and while obviously doesn't feel as heavyweight as it did back then (i'm running it on a 8 core machine with 32GB of RAM so it better be), it still feels sluggish and startup time is still quite slow.
Also TBH i never liked the idea behind workspaces.
These days i don't write C++ much but when i do i use either QtCreator or Kate with the Clangd LSP (which i also use for C).
Considering I'm not closing it down for whole day when I'm using it, waiting for ~10 seconds in the morning is not that bad.
In 2003, Eclipse was at its infancy and was an absolute hog, I agree on that front.
Actually you are not expected to have "n" workspaces. Maybe a couple (personal and office) at most. Project relationships and grouping is handled via "referenced projects".
Kate is an awesome code-aware text editor. I generally write small Go programs with that, but if something gonna be a proper project, it's always developed on Eclipse.
I tend to close and run the IDEs (and most programs) multiple times per day - a clean desktop kinda lets me clean/reset my thoughts - so long startup times are annoying. Of course i wouldn't avoid a program if it was responsive, fast and did what i wanted after it started up.
> Actually you are not expected to have "n" workspaces. Maybe a couple (personal and office) at most. Project relationships and grouping is handled via "referenced projects".
Yeah i also had a single workspace but i worked in a bunch of other things, including some Java stuff in NetBeans and i want to have everything in one place. I do use and prefer IDEs but every other IDE could just store projects wherever i wanted.
First, it was quite common for a company to buy a developer the exact same corporate standard computer as everyone else. So lots of computers had limited ram to run things like J2EE, Lotus Notes, and Eclipse at the same time. It was painful.
The startup was always slow because it preloaded everything. This was a deliberate choice to not load things and interrupt the developer. Just don't close it all day and the experience was very good.
A plus compared to the standard of the day was that it ran native widgets. So doing something as simple as opening a file explorer to browse through your project was considerably faster than comparable IDE's at the time.
Personally, I loved the customization which was dialed all the way up. I could have multiple windows with different arrangements of panels within them, all saved. I haven't run across anything as configurable since then.
It also had the big benefit of their plugin system which shined when working with multiple languages in the same project.
It always felt to me like it became trendy to crap on Eclipse because of the slow startup time and it never could shake that.
9 seconds of startup time on a modern GHz computer is completely unnecessary and unacceptable IMO. There may be 9 seconds of work it wants to do at startup, but there's no way it needs to do it in a single thread before letting you start to interact with it. This is an optimization effort, nothing more. Give me a month with their codebase and I could get that down to under a second. (So could most decent software engineers.) It would just need to be something they actually put effort into.
In the following seconds, updates are checked and indexes of your open projects are verified and re-run if necessary which takes again <10 seconds on different threads. Your computer may scream momentarily due to increased temperature on all cores if indexes are rebuilt.
If you think that code is not optimized in the last 20 years, you’re mistaken. Many tools from Android Studio to Apache Directory Studio runs on that platform.
Nevertheless, I’ll try to profile its startup tomorrow if I can find the time.
Normally Eclipse IDE is not something like Vim, which you enter and exit 10 times a day. It just lives there and you work with it. 10 seconds in the morning for a tool that big is very acceptable, esp. after considering that everything is instantaneous after that 10 seconds.
First of all, this neither machine's RAM bandwidth is 40GB/sec, nor it has a 7GB/sec PCIe drive. It's a run of the mill, SATA backed system with a 7th generation i7.
Second, JVM is always a heavy machinery to start. The startup CPU utilization is around 600%, dipping to 400% and spiking to 800% at the end, showing some plugin dependency requirements are slowing things down. Also, that's a 20 year old OSGI platform, which runs a ton of interconnected plugins, not a mere text editor. It's in the same ballpark of MATLAB or scientific modelling software in complexity and sophistication.
Lastly, as an HPC admin and develoeper, I live by and die by performance. Computers can do some complex things for humans (e.g.: Floating point number crunching) stupidly fast, but some things which are seemingly simple for us (e.g. understanding language) can be equally stupidly slow and resource hungry.
For me, it's wild to think about complaining for something without investigating and understanding it completely.
Also the UX was mediocre at best and infuriating at worst. Practically every interaction worth performing in that editor took at least one more click or keystroke than IntelliJ, and I would rank IntelliJ as merely good, but not amazing with input economy.
I don't think VSCode will use 400MBs with that amount of code, plus electron, plus all the LSP stuff you run beneath it.
In that state Eclipse will fit into a 6GB system just fine. I'd love to try that at a VM right now, but I don't have the time, unfortunately :)
At the time most of us felt it was worth the cost of entry for all of the tools you got, which eclipse had a subset of.
A couple of years later I started an internship at a bank and spent ~3 hours trying to get a project building before someone introduced me to IntelliJ, which I still use every day almost 20 years later!
Eclipse is Visual Age for Smalltalk reborn, after all.
It was common to have plugins corrupt its metada, but somehow it finally became quite stable.
You will find old rants from me complaining about workspaces metadata, but that problem has been sorted for quite sometime now.
Seconded on the ergonomics. They were a joke. Longest inputs of any IDE I’ve ever used. If your sequences are longer than vim you need to get your head examined.
i really despised (to stay polite) everything about eclipse/java culture.. lots of generic layouts and components, nothing i cared about or bringing me dense information about code. way too much chrome and perspectives and what not. it was a cultural dead end, the people who "enjoy" working this way are on a different axis from me.. give me emacs+magit where things are right under your fingers and easy to extend.. and people using this kind of tools (i'm sure vim/neovim crowd likes that too even more) produce more tools of that kind
The last couple of years, however, it feels like Eclipse is actively getting worse. And I don't mean that it's lacking features. I mean that every new release seems to break something else.
I tried reporting some bugs, but that required signing some kind of soul-selling agreement with the Eclipse Foundation or some other nonsense.
I then tried fixing those bugs, but there is no up to date documentation on how to build the IDE from the myriad of repositories and modules. So I gave up.
This context is built up based on what part of the code you work on.
thank god
JetBrains has plenty of problems, which they seem to want to address but I fear Fleet won’t fix, and I lament but understand people wanting something lighter these days, but eclipse isn’t even in that conversation.
Hell, Eclipse STILL doesn't really have a nice dark mode. The actual editor view looks okay, but the dark mode feels very bolted-on to the surrounding UI.
I think this is the primary reason why VSCode is eating the world today. People will talk about the plugin ecosystem and all these other community inertia advantages. However, VSCode was exploding in popularity BEFORE that plugin ecosystem was in place! If we're really honest with ourselves, we flocked to because it was even more gorgeous looking than Sublime Edit, and without the nag modal to pay someone 70-something dollars.
Appearances MATTER.
I really do believe that for most people, IntelliJ is basically a VSCode that: (1) has a better debugger and some more polish around Maven/Gradle integration, and (2) came out 10+ years sooner.
But ~10 years ago, everyone I knew was flocking over because IntelliJ felt less slow and bloated than Eclipse, and its dark mode UI was more attractive in comparison. Then it became the more-or-less official way to develop Android apps (back when Android's U.S. market share was a lot higher), and that was all she wrote.
User experience matters. Most of user experience has nothing to do with dark mode. Dark mode is pure fashion, and should be prioritized appropriately.
I used it for quite awhile until JetBrains stole my heart, but it was nothing if not bloated, even then.
It's bizarre to now see it described this way.
Interview with an Emacs enthusiast https://m.youtube.com/watch?v=urcL86UpqZc
It seems Unix/Linux really got a nice integrated debugger with ann IDE and gdb is powerful, it is very cumbersome. Hence, it seems there is a lot more printf debugging on Unix, and less use of debuggers than say on Windows where Visual C++ and Borland Turbo C++ both had very easy to use debugging integrated into the IDE.
Linux eventually got DDD.
Unknown to most is that gdb has a TUI, and is highly scriptable in Python.
[1]: https://github.com/magiblot/tvision
https://www.pouet.net/prod.php?which=92408
You can run Asm One in the browser here: https://archive.org/details/ASM-One_v1.02_1991_Gram_Data
I actually feel that the terminal-based focus of modern FAANG-style development actually hindered proper tool development, but I was never able to explain it to anyone that hasn't used Borland C++ or Borland Pascal in the past, except maybe to game developers on Visual Studio.
Some even have their own editors.
There is a lot of value in picking a transferrable editor and using that. From that point it becomes "what is the best editor that will _always_ be available". Emacs/Vim fit that.
Then the muscle memory can begin to grow, and there is one less bit of friction in starting a new job.
One of the best pieces of advice I received was "pick an editor and go deep".
Agreed, I'd be infinitely less productive if I couldn't use the editor I learned to master in the past 20 years.
A corollary to that would be "pick a company that lets you use your own editor". There's lots of friction from IT departments towards emacs and vim. The package/plugin system is a security nightmare with lots of potential supply chain attacks and more importantly no trusted vendor to blame when something goes wrong.
I never understood why Redmond folks have so hard time thinking of a VB like experience for C++ tooling, like Borland has managed to achieve.
The two attempts at it (C++ in .NET), and C++/CX, always suffered push back from internal teams, including sabotage like C++/WinRT (nowadays in maintainance as they are having fun in Rust/WinRT).
The argument for language extensions, a tired one, doesn't really make sense, as they were Windows only technologies, all compilers have extensions anyway, and WinDev doesn't have any issues coming with extensions all the time for dealing with COM.
Or the beauty of OWL/VCL versus the lowlevel from MFC.
Windows could have been like Android, regarding the extent of managed languages usage and NDK, if DevDiv and WinDev had actually collaborated in Longhorn, but I digress.
Thankfully with KDevelop, Smalltalk, and when Java started to make IDEs more common on UNIX, I no longer needed XEmacs.
Ironically for all IDE-haters, even James Gosling, inventor of XEmacs, says people are missing out not using IDEs, he surely moved on from Emacs ecosystem.
And by the way classic curses like menu bar can be opened in text mode with M-x menu-bar-open which is bound to <f10> by default. You can even use mouse with xterm-mouse-mode.
The one he was looking at was text menubar emulation which is pretty powerful too if you take a minute to appreciate it.
What is completely fair. Emacs in particular is more featureful than VS-Code, but hell, it's hard to make use of all of it.
Or just the menu and toolbar weren't immediately disabled by most.
My graduation thesis was porting a visualization particles engine from NeXTSTEP/Objective-C/OpenGL into Windows/Visual C++/OpenGL, as the department was seeing the end of NeXT and they wanted to keep the research going on.
My supervisor had a NeXT Cube getting dust on the office corner, waiting to be collected.
There are some very short/simple demos on YouTube:
https://www.youtube.com/watch?v=m_3K_0vjUhk
Or, use Lazarus/Free Pascal, which is almost identical, except for the documentation, which needs a massive overhaul, in tooling and content.
Those can profit from very latest version.
Every time someone says that, I mention Lazarus. I stll get a thrill out of using it (one of my github projects is a C library, and the GUI app is in Lazarus, which calls into the API to do everything).
The problem I find with Lazarus is that it seems to be slowly dying; yes, they still work on it, but feature-wise they are very behind what can be done with HTML+CSS and a handful of js utility functions.
A wealthy benefactor could very quickly get Lazarus to the point of doing all the eye-candy extras that HTML+CSS let you do (animated elements, for example).
Borland really had a series of these fantastic products, it's a shame they are no more. The only modern company in this space is JetBrains, it seems, so the niche is small.
VSCode is now my one stop editor of choice on Linux and VS on Windows. I also use Jetbrain editors for work.
I’m done. For people like me, who write SQL and Python for data pipelines, the Jetbrain IDEs are no-brainers. We don’t actually get the time or energy to do a lot of side projects so it doesn’t make sense to learn advanced editors such as Vim and Emacs: 1) These two need a lot of muscle memory just to start using it, but we don’t use it on a daily basis, 2) I’m not smart enough to write code as if I’m writing this reply so fluent coding experience without mouse isn’t useful for me ——- I have to stop and think hard every few minutes anyway.
I like JetBrains a lot. Things work seemlessly and easily integrate with external tools that make up the whole experience. But from 2012, I tried to rely as much on shortcuts as possible, for one simple reason, the mouse.
There is no problem with using the mouse. But everytime I have to use while focusing and coding, I find that that small gesture to move my hand from the keyboard to the mouse a bit flow breaking.
I have to move to the mouse, do a thing or two, then find my way back to the J key notch.
I like what NeoVim and emacs bring with regards to the reliance on the mouse. They allow for maintaining the same posture most of the time and focus only on typing.
I dislike how brutal they are at learning how to use them to full potential, and that making them into IDEs takes ages of IDE building rather than project coding.
I like Helix. Which takes a lot of inspiration from Vim/NeoVim/Emacs. But require no configuration to get you going right away. The documentation is easy to read, as of now there is no plugin system but there is a builtin integration with a lot of LSP servers for most of the popular languages by default.
Keys and navigation is easy, it even shows a helper popup to show you which key to use next.
My suggestion is, if you ever want to start a new silly project, and you're feeling free to take it slow for 2 days. Try using Helix on said project.
PS: Helix isn't fully complete by any means, but it really is capable of doing everything you want in many projects without being a hindrence if you can adapt to the lack of some built-in features like git and file tree. Its annoying but I am less upset about it and use alternatives
The only inertia vim adds to my workflow is escaping into command mode. I have a 'jk' shortcut combo rather than escape, but if I'm hammering away I often mistime it and need to backspace out my jjkk or whatever.
Good Vim input plugins can make IDEs more pleasant and efficient for users who prefer vim, neovim, vi, elvis, etc.
I installed it a couple of weeks ago to modify some android app, and boy it gave me vibes of the old Eclipse : sluggish Java feel , with "stuff" happening all around and being slow to render basic editor stuff.
Android Studio is generally one generation behind mainstream Intellij and has its own modifications on top of it. It depends on your target language. With the exception of CLion, all other forks of Intellij work much faster than Android Studio from my experience.
I tried to install plugins but there is always something that fails somehow. Nvim distributions don't install and run out of the box for the most part, I get weird errors regarding lua or something and just give up. As for VSCode I wrote my first python project using it a couple weeks ago (I'm not a developper) and it's alright but a few things annoy me, like the integrated terminal and some things getting in my way.
At the end of the day, each of us should chose whatever we feel comfortable with. I spent maybe 2 hours in my life learning vim movers and never looked back. I don't even use tmux or anything, just open 1 or 2 terminal windows and alt+tab between them, with the occasional :split or :vsplit command.
But vim is ubiquitous which is a huge plus when you are like me always connected remotely on a different machine. Once I learned a few shortcuts I never went back (and never dug into the tool itself actually, I can't even run a macro ; I'm still faster than most people I know with an IDE).
The only thing I was impressed with is I think phpstorm, watching a laravel dev crafting an SQL query. If I ever get serious about developping I would look into this kind of things (not just for SQL but also framework and module functions), especially if I can get vim movers, and a screen that isn't bloated. VSCode displays like 15 things and I'm only interested in 1 of them 99% of the time for example.
- for ansible on reasonably large projects (a dozen of roles) it was never a problem ; you have to understand how the project has been structured and be able to use grep and find though
- when I was playing around with os161 I don't remember it being an issue. Although for this particular case I did use the cscope vim plugin which is helpful to navigate through the codebase (there are equivalents for various languages). Not sure if os161 would qualify as "large codebase" but it's a bunch of files in a bunch of folders.
Intellij IDEA 1.0 was released in 2001 - is still in active development - and as far as I know the keyboard shortcuts are still the same (depending on the configuration one chooses)
The first Microsoft Visual Studio release was in 1997. XCode was first released in 2003.
If you learned Java between 2001-2012 then the default was Eclipse or netbeans.
So you should not be comparing IDEA from 2001 to today (or any individual IDE), you should be comparing the IDE landscape or ecosystem of 2001 to today, and part of that analysis should be a requirement to weight IDE's based on popularity and the recommendations of established institutions (academia, companies).
Maybe I just don't understand your comment - even translated it still confuses me tbh. (I'm not a native speaker). Sorry if you feel offended I guess.
My entire point was that it's unusual for someone, especially someone who is new to IDE's or programming in general, to pick something brand new. As educational institutions will take time to change from the popular thing and most companies will also need time to adjust.
Distilled: my point is that you should not compare IDE release dates to the stability of IDEs vs Editors. -- you must consider the entire ecosystem of each at the time.
Another perhaps good example to conclude this would be something like python backends. One could (unreasonably) argue that Python has been around since 1991; but backends typically were written in Perl or PHP for a very long time. It wasn't until 2008 or so that Python started making headroom for web backends (ruby around the same time) -- The possibility existed but the popularity wasn't there.
A similar argument could be made for Sublime text (which is uncommon these days) but was extremely common in 2010. Or Atom, which doesn't even exist any longer but took considerable market share from Sublime in its heyday.
It's not fair to say "x has been around for y time therefore it is not changing", the ecosystem does change and it has darlings and detractors.
The only exception to this ecosystem over tool argument I can think of is probably visual studio itself as that was a monoculture and stuck around because of that.
I know there are many editors fighting for its market share, like Zed from the original Atom team or Fleet from Jetbrains.
We did a bakeoff of Eclipse, NetBeans and IDEA upon its beta in 2001. IDEA won hands down and is still the IDE of choice among the developers who work on our codebase.
But my point is much, much broader than one persons experience.
Just so I understand you correctly - am I using your comment
> That's cool, I didn't know you were most programmers.
correctly here?
As I stated in my post above, (after someone asked me a direct question) that: despite answering the question, it was the wrong question and not the point I was making.
TBH everything on Linux/Unix variant (except MacOS) is like that, there is no open-box solution. There is always too many configurations and even begin with (even VSCode is too configuration heavy for my taste but I use it as my Linux VM is light). This is definitely good in its own sense (more powerful), but most of time I just want something to work and concentrate on what I really want to learn. I mean, if I really want to learn how an editor works, I'd go ahead to build one myself, but in the mean time I just want to write a toy compiler so please just let me do it.
While on the surface that means that language support doesn't have to be designed for a particular editor/IDE, what's less obvious is that LSP (in particular) can be used as a generic IDE plugin API. I've heard of some non-language support extensions (ab)use LSP to get cross-editor support with the same codebase.
Not really... When a new editor/IDE comes and replaces the rest, it's because it seduces the original userbase of the previous IDE, so usually the transition is smooth (same shortcuts, similar functionalities and ergonomics). Moreover, I find it weird to "invest" time in an IDE, usually you don't really need to, you learn the basics of it and you're good to go for years.
The Language Server Protocol [1] is the best thing to happen to text editors. Any editor that speaks it gets IDE features. Now if only they'd adopt the Debug Adapter Protocol [2]...
[1] https://microsoft.github.io/language-server-protocol/
[2] https://microsoft.github.io/debug-adapter-protocol/
What are the six lines in your .vimrc?
set softtabstop=2
set shiftwidth=2
set expandtab
syntax on
set bg=dark
optionally :
set autoindent
on wsl :
set t_u7=
(no value ; almost pulled my hair finding this one out)
https://vi.stackexchange.com/questions/27391/why-it-enters-r...
But the time spent getting multimode up or good autocomplete when you can simply fire up something like jetbrains IDE, having most of your ecosystem tools integrated the second you launch it makes the decision to switch easy.
Also, dev machine tend to have a lot of resource nowadays so the RAM hungry IDEs are not a problem.
These editors are going to be replaced and emacs and vim will be kicking.
> I’m not smart enough to write code as if I’m writing this reply so fluent coding experience without mouse isn’t useful for me ——- I have to stop and think hard every few minutes anyway.
I've worked with good programmers who literally hunt and peck. It drove me nuts, but as most will agree, typing is rarely the bottleneck when programming. I've also worked with people who I would consider vim power users, and while they were faster at typing out some tasks than I am, I found they were often typing/moving around the file as their method of thinking. Whereas I might reach for the mouse and scroll around instead. Again, typing speed is rarely the bottleneck.
Otherwise, VSCode solves almost all my problems, and virtually all my key-bindings are identical.
i have never been so productive.
Turbo Pascal and Turbo Prolog - those were the days. Borland had the greatest products, and the accompanying books were always well written, used beautiful fonts, and, not less important, smelled nice.
If my memory serves me right, Borland even released their Text User Interface (TUI) library for developers to use in their own applications.
Fond memories indeed!
On desktop we can drag scrollbars but I can't imagine what it's like to use modern 4-8px action area scroll bars if you have fine motor control challenges.
I just don't understand how we got to this point. Do people not use the apps they write?
[0] https://i.imgur.com/CAyu5Ay.png
[1] https://github.com/josvanr/cde-motif-theme
[2] https://i.imgur.com/Yw1tTcD.png
> The first is that a TUI IDE is excellent for work on remote machines—even better than VSCode. You can SSH into any machine with ease and launch the IDE. Combine it with tmux and you get “full” multitasking.
I definitely disagree with this sentiment. At my last job, I had to do most of my work on a remote server (because it had a GPU), and I found VS Code far more pleasant to use than plain old SSH. People recommended using an editor on the server side or freaking around with Win SCP / Cyberduck, but VS Code was just so much better in so many ways.
Because of VS Code's web roots, it can easily run its frontend on your own local computer while running its backend somewhere else. This means that most common actions, like moving the cursor or selecting text, can be done locally, without the need for a round trip to the server. The operations that do have to be executed remotely, like saving a file for example, are properly asynchronous and don't interrupt your workflow. Everything is just far snappier, even if you're working from home, through a VPN, on barely working WiFi and an ADSL line.
As a bonus, you get fully native behavior and keyboard shortcuts that you'd expect from your platform. Things like text selection and copying just work, even some of your addons are carried over.
[0] https://www.gnu.org/software/tramp/
Why?
Which is also immediately mentioned after the claimed that using a remote editor is silly.
In my experience, this is the best way to do remote work. The alternative is to either not work with remote resources (data, hardware, etc), work locally and sync changes to remote, or work locally with a remote mounted file system (unless you need remote hardware).
For the parent, they needed GPU access, so they had to run remotely for hardware access.
I normally need particular data that is too big to move locally, so I like to work remotely for that reason. I could remotely mount drives via an SSH Fuse mount, however the IO speed for this method can quickly become a problem. For me, it is a much better experience to either use a remote web editor (rstudio server), VSCode remotely (which is a remote web editor over ssh), or vim. With web based remote editors, you still draw the screen locally, but get updates from remote. And more importantly, compiling and building takes place remotely.
I find this method much better than either pure remote access (VNC/RDC/X11) or local-only editing with syncing code and/or data. But it very much depends on your work. When I don’t need to work with remote data, a locally managed Docker devcontainer provides a much better development experience.
If TRAMP is too slow, just mount the remote filesystem locally using FUSE somehow. Use SSH to run processes on the remote system like compile and run the program. No need to run the text editor on the remote system.
You can also do it the other way around: have your remote system load your local data. I developed a small bare metal OS this way. Ran the cross compiler locally, had the output go to some NFS mount which was also available via TFTP. Booted the target system with PXE.
Running a text editor on a remote system is good for one off things and maybe as a last resort, but that's it.
That said, you can also open a terminal in vscode and use grep. If you’re running remotely, the terminal is also remote. That’s what I normally do.
This is the step that never works consistently for me. There is always some amount of random extra latency that makes the this workflow painful. I work with some extremely large data files, so random access to these is the primary issue.
In general, the idea is that it is often better to do compute where the data already is. My experience is that you should also do the programming closer to where the data is as well. This tends to make an iterative development loop tighter.
But this is highly dependent upon what you’re doing.
It's funny because my reasons against using a text editor remotely are exactly the same: to make the development loop tighter. I am very upset by latency and always try to remove it where possible. I think this is the kind of thing where we'd need to look over each other's shoulders to understand our respective workflows.
That’s exactly what I’m doing. The code is written on the remote server. VSCode’s remote setup is actually very good at this. Mainly because, it is really a web editor that is hosted remotely and you use a local browser (Electron) to interact with it. The processing loop then happens all remotely.
But really, I’m talking more about data analysis, exploration, or visualization work. This is when I need to have good (random) access to 100’s of GB of data (genomics data, not ML). For these programs, having the full dataset present during development is very important.
If I’m working on more traditional programming projects, I can work locally and then sync, but recently I’ve been using more docker based devcontainers. These are great for setting up projects to run wherever, and even in this case, the Docker containers could be hosted remotely or locally (or more accurately in a VM).
I think people are just talking about different things and confusing each other. The original comment I replied to was arguing against SSHing in (or vnc or something) and running the text editor there. VSCode isn't doing that. It is running the interactive part locally. It's hard for me to understand why it needs a server part, though. If you want to edit something locally it has to send it across the network. There's no way around it. It seems like six of one and half a dozen of the other.
As the author states, IDEs haven't necessarily gotten a lot better, but imo advanced features have become a lot more accessible.
I absolutely agree, assuming you're using "powerful" in the same sense as saying that a Turing machine is more powerful than a MacBook.
That's better than SSH for sure, but still not as good as the web model.
The client is the server application.
The server application isn't guessing keys, regardless of the connection format.
What matters is how the communication is being compressed and local optimizations.
Whereas any non trivial X application does work in the client, thus even basic interactions have a notable delay, depending on connection.
There is no difference between doing this over text or graphics, in terms of the whole setup regarding network communications for data input and output.
VS Code's "backend" that runs on the remote machine is rather only in charge of more "asynchronous" operations that aren't part of the UI's critical path, like saving files or building the project. It doesn't speak anything as granular as the X protocol.
Long are the days using pizza boxes for development it seems.
Thisnis very different form a system, where each keystroke and each menu action has to be transfered first, before the remote side can identify the needed UI update and send that back
Not going to waste more my time explaining this.
Arguments to authority aren't appealing. Arguments from logic are. The fact is that X and VSCode's remote protocols are designed very differently, and in high-latency and high-jitter connections (and many low-bandwidth ones), VSCode's protocol is simply better.
TRAMP only requires ssh or telnet (or scp, rsync, any number of other methods) on the remote machine.
Let me try to rephrase: with X Windows, the UI server runs on your local machine, while the UI client runs on the remote machine (e.g. your application's server). Is that correct?
The client application (on X Windows nomenclature), runs on the remote server and is headless.
Instead of sending streams of bytes to render text, it sends streams of encoded X Windows commands to draw the UI.
Everything else regarding compilers, subprocesses and what have you keeps running on the server, regardless how the connection is made.
Think big X Windows terminals or green/ambar phosphor terminals accessing the single UNIX server, used by the complete university department.
"""The X server is typically the provider of graphics resources and keyboard/mouse events to X clients, meaning that the X server is usually running on the computer in front of a human user, while the X client applications run anywhere on the network and communicate with the user's computer to request the rendering of graphics content and receive events from input devices including keyboards and mice."""
> Instead of sending streams of bytes to render text, it sends streams of encoded X Windows commands to draw the UI.
(Simplified) VSCode is sending no bytes to a server when you're editing a file. The entire file exists on the client, you can edit all you want and everything stays on the client. Only when you pick "save" is a data sent to the server.
My understanding with X Windows is as you mentioned above, you press a key, that key it sent app on another machine, that other machine sends back rendering commands. Correct? Vs VSCode, you press a key, nothing is sent remotely
Note: There's more to VSCode, while it doesn't have to send keystrokes and it is effectively editing the file locally (so fast). It does send changes asynchronously to the remote machine to run things like the Language Server Protocol stuff and asychronously sending the results back. But, you don't have to wait for that info to continue to edit.
No, you weren't doing this. You were making a round trip to the server when you moved the cursor or selected text.
Of course this being X, your machine ran the server and the remotes were the clients…
Also it is impossible by laws of physics by using distributed computing, not having each keypress and its display on a rendering surface, being a two way street.
The idea with VS Code is that neither the keypresses nor the displayed windows are being sent over the network, but are kept within the same machine where the user is entering or viewing them. Only the file data (or debugger status, etc.), which are cached and far less frequently updated, are sent over the network. Are you saying that XEmacs can also function remotely in this way, with neither keypresses nor displayed windows sent over the network?
VScode runs on the computer in front of you, and it _does not_ send key-presses or other user input over the network at all. Instead VScode sends file-changes over the network to the remote, and executes commands on the remote (e.g. SSH's in and runs 'gcc ...').
With X, XEmacs is not running on the computer in front of you; it's running on a computer far away. Every key-press and mouse click must be transmitted from the computer in front of you over the network, received by the remote computer, then a response sent from the remote to the computer you're interacting with, where it'll be displayed.
https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...
https://code.visualstudio.com/docs/remote/remote-overview
The resource consumption on the client doesn't bother me one bit. Any minimally decent laptop can put up with that load, on battery power, for hours.
I would agree with “whatever it takes to make the server install leaner, more portable, etc” just without sacrificing many features.
If the server side doesn't run on FreeBSD that's really too bad. If Microsoft makes it hard to improve by not making those bits open source, that's very unfortunate.
I've always been a big user of powerful laptops because I do like the mobility (allows me to work/browse stuff outside my home office) and I dread the pains of properly synching my files across a laptop and desktop (not only documents/projects, but also configs and whatnot).
As the remote can be a docker container, so when I have to do some experiment, I create a container takes 5 min to setup. I than can play around, test dozen packages and configs, once I am comfortable commit last version.
If I want to do some quick testing on project by different team, again a local container is setup in 2-10 mins. Once done delete the container and my local system isn't messed up.
Last is obvious use case if you want to test anything on reasonable large data or GPUs. Create a cloud server, get data run your code, tests. Push data to S3 and done.
It can be a bit heavy in cpu usage depending on plugins though.
I like emacs tramp in theory since it doesn't impose that, but latency suffers.
With correct ssh config it usually works well, but many times I'd prefer lower latency with emacs being on the host.
That's supposedly possible, but I've never gotten it working.
- docker containers - accessing boxes on same network
Sometimes its fine, but then perhaps because of regressions, I get buffers that never seem to recover and have to be cleaned up.
I'm not familiar with VS Code setup for remote editing. Does it run LSP on remote and give you full hints, errors, etc. locally?
> As a bonus, you get fully native behavior and keyboard shortcuts that you'd expect from your platform. Things like text selection and copying just work, even some of your addons are carried over.
Selecting text with Shift+ArrowKey or something like that is not a "bonus", it is just a bad text editing experience. Keyboard shortcuts are the way they are on Vim/Emacs not because their developers can't figure out how to bind Ctrl+C/Ctrl+V...
It’s split into a client (web frontend) and server that’s doing all the work. The server can be run anywhere but it’s effectively a bunch of stuff installed in a docker container. When you start an instance for a project, it creates a container for that instance with all the code folders etc bound in. LSPs are running in that container too.
It’s possible to use your own image as a base (you might have custom deps that make installing the requirements for an LSP hard, for example).
The trick they use here is that there’s some base container/volume that has most of the server stuff downloaded and rest to go. Whether you start a normal instance or from a custom image they do it the same way by just mounting this shared volume and installing what they need to bootstrap the server.
It also appears they create a frontend window per server process too. So the master client process starts, you select a project folder, they create a new server container and a new client window connected to it. The frontend client is local while each server can be anywhere (obviously you could run the client with X if you wanted to further muddy that).
Not sure about other languages, but when I use VS Code to develop Rust remotely, it prompts me to install the rust-analyzer extension (which is my preferred LSP server for Rust) to a remote whenever I'm opening a project for the first time. VS Code is able to distinguish between extensions that need to be installed on the same machine as the code (like the LSP server) and extensions that are just making changes to the local UI.
> Selecting text with Shift+ArrowKey or something like that is not a "bonus", it is just a bad text editing experience. Keyboard shortcuts are the way they are on Vim/Emacs not because their developers can't figure out how to bind Ctrl+C/Ctrl+V...
I use an extension for vim keybindings in VS Code. When connecting to a remote host, the vim plugin still works fine, itand doesn't prompt me to install anything on the remote side, since the changes are synced to the remote host at a much higher level than that (i.e. locally mapping "dd" to "delete this line from this file" and sending that to the remote rather than sending the remote the keystrokes "dd" and having the remote determine how to interpret it).
A few years later I was using SparcWorks on Solaris. When I realised you could pause on a breakpoint and hover the cursor over a variable in the editor to see its value, my brain nearly fell on the floor.
A few years after that I moved to PC development using Visual C++, and then Visual Studio 97 on NT4. Drag and drop UI builders for Windows and Web.
And 30+ years later I still spend a significant part of my working day in VS.
While Dev-C emerged as a possible alternative for console programs and programming contests, it wasn't enough for developing native Windows GUI applications without shelling out for Visual Studio.
This limitation ultimately led me and some friends to explore development on alternative platforms like OS X and Linux. Ironically, even to this day, none of us mastered the WIN32 API.
E.g. here's my C64 emulator running in Docker (it's a real C64 emulator underneath, but only renders the C64 PETSCII buffer via ncurses, e.g. no graphics or audio output):
...code is here: https://github.com/floooh/docker-c64