Many senior colleagues still use emacs today; historical inertia or they actually love that?

They use emacs for checking logs, edit commit messages and coding. I know when they grew up and started to learn programming, there may have no fancy GUI editors/IDEs for them and they had to start from something like emacs and vim. But now we have introduced VS Code (previous IDE is Eclipse) for production environment; young colleagues love that: it is faster, more responsive, robust and beautiful. We actually can monitor how many colleagues are using VS code/Eclipse, but it is disappointing to find out most of senior colleagues still stick with emacs.

I chuckled reading this because I’m (only?) 33 and definitely had access to IDEs when I was learning programming. All of the tasks you mentioned are text editing/manipulation and Emacs happens to be good at it. It shouldn’t matter what tools a productive engineer uses. I’m curious why you feel disappointed to be honest.

`(query-replace "senior" "experienced")`

> But now we have introduced VS Code ...: it is faster, more responsive, robust and beautiful. I'll grant that it's prettier. The rest seem ... debatable.

50 here and yes we had ides back when I was 16. Take away my intellij and I would only really miss code assist, especially with Java/Kotlin. I have used vim in the past and dabble with emacs for org and clojure. Would love to one day have the time to master them both to the extent where my setup matches intellij.

[deleted]

Previously we have Eclipse as our IDE and we have already found out it is not widely adopted. By then I think "OK maybe they don't like it because it is slow", and the poll does support our guess. That's why we decided to switch to VS Code. We have many performance tests and they show VS Code is indeed faster. It takes our team enormous effort to finally bring VS Code to our colleagues in development department. Our production environment is, how to say, a little bit different. The C language that we use in the product is not "regular"; it contains many extensions because it is designed to run on our proprietary ASIC processors. It has millions of lines of code in thousands of files. You can imagine how much work I and my team has done to support all these features; we want to bring the most cutting-edge and the best tool to our colleagues. It is natural to feel disappointed when your work is not recognized. I will not feel frastrated if I get thousand of bug reports and complains; but I do feel frastated to know many senior colleagues would stick with emacs. And most importantly, the situation is very polarized. Senior colleagues mostly stay on emacs but younger colleagues adapt to VS Code really fast.

Have you sat down with one of the Emacs users to watch how they use it?

I'm 60. It's both. > VS Code (previous IDE is Eclipse) for production environment; young colleagues love that: it is faster, more responsive, robust and beautiful. Hard to imagine it's faster or more responsive than emacs. You know, when I was writing Java in the 90s, and I saw Eclipse, I instantly switched to using it because of the refactorings, even though it was pretty slow. Language support was the key feature. This year I'm writing Python. If I had a month to be working at 75% productivity, I might now move to JetBrains because of the strong language support and refactorings. For much of my career, particularly the last 15 years, I've been the most productive programmer in any group I'm working with, and my code (and my commits) are practically manicured. I attribute this to programming almost every day for 40 years, and an editor which, while it doesn't have great language support, lets me rocket about like lightning. > it is disappointing to find out most of senior colleagues still stick with emacs. They are probably just as disappointed in you that you spend all this time creating drama instead of writing code.

Such troll

We did not do much comparison with emacs or vim or any other CLI-base editors. AFAIK, we never implement any extension for emacs or vim, like code highlighting, grammar checking, code assist, debugger integration, you name it. As I said in other reply, our C language is "proprietary" with many customized extensions dedicated for our own ASIC processors.

That explanation makes it a lot easier to sympathize so I appreciate the response. Emacs is fairly customizable. It is primarily a programming language that you can use to automate your own workflows. As much time as you have put into your dev tools, the senior programmers you are talking about probably have as much invested in emacs customizations for all of the tasks they want to do. Your explanation of what your extensions provide is not very clear to me. If what they enable is basically searching for stuff in files, I can understand why someone used to emacs wouldn’t see much benefit in switching to VS Code. If there’s more to it, I, personally, would just use VS Code for the workflows that it made easier and continue using Emacs for other tasks. It is not just inertia, but an educated guess that VS Code alternatives to my current workflows are not going to be quite what I want.

The thing about emacs is that it's a tool you hone over your entire career making it fit you like the perfect glove. VS code might be pretty good out of the box but I am pretty sure for those longtime users VS code is many steps back. Those devs will still be using emacs when you swap from VS Code to the next software. That is stability. To me it's more sad that the younger colleagues don't give emacs a chance. I've used a variety of IDE' I'm self teaching myself web dev and use emacs by choice. My biggest fear is a work place saying I am not allowed to use it.

Emacs users would have implemented those things themselves.

Criticize me whatever you like, I won't mind, since you don't pay my salary. We are not creating drama; we are writing and maintaining tools like debugger, compiler, IDE, and many other automated tools using in our work.

I'm 40 and went to college for a few years for coding, I ended up going a different path for much of my life but I'm self teaching myself webdev atm. I've read that LSP / elgot etc provide good language support. Do you still find emacs lacking? I'll still use emacs over anything else as I'm simply in love with it's command scheme, customizability and overall "way of thinking" the app uses. Just curious what blind spots I should compensate for so I mitigate friction from collogues and employers about choosing emacs. As a Junior they might find it strange that I'm using it over vs code.

I'm 24 and I have been using emacs for 6 years. The primary reason for starting was remote editing. A quick Google search showed that the vscode Remote Development extensions only came out in 2019 so you don't have to be that old to have had a good reason to start using emacs. But even now I prefer emacs because text manipulation is just so much more powerful. I normally have VScode open as well if there is a feature emacs is lacking and I don't want to impede my development speed. But that's normally only for a niche debugging tool. Actually coding in VScode now causes me to pull my hair out because many features are just not implemented well and don't exist by default compared to emacs. Mainly the kill ring, mark ring, handling lots of open files and switching between them. I'm sure your Senior colleagues have this frustration as well as not wanting to throw away all their customization that makes their own workflow easier.

Why is it hard to imagine? One of the most prevalent criticism (once you filter out comments about it not being "modern" enough etc.) against emacs have been its poor performance and responsiveness under load.

>Our production environment is, how to say, a little bit different. The C language that we use in the product is not "regular"; I get that. I've worked with projects using Embedded-C variants before and it's quite frustrating to get them running properly in an IDE. How did you manage to get it supported in VS Code? Did you perhaps provide a custom language server? Because in that case your senior colleagues may already be using your work in emacs via eglot/lsp-mode. If not, maybe that's the route you should consider because then it would work in all major editors without forcing your devs to use some specific fancy glorified web-app like VS Code. >And most importantly, the situation is very polarized. Senior colleagues mostly stay on emacs but younger colleagues adapt to VS Code really fast. I definitely understand some of that frustration from your perspective. I once was working on a serial terminal application for my collegues but some older engineers, out of habit, were using an ancient obscure windows terminal that didn't even support a full set of ANSI escape codes. "Just use putty or any Linux terminal" I told them. But they'd rather complain to me about the app not displaying properly every couple of weeks instead of getting used to a new program. Doesn't apply to Emacs though, because Emacs can be as modern as you want it to be.

We don't prohibit any tool as long as it can be used for commercial activities. Many IDEs are free for personal use but not commercial use; and I guess that's why they want us to implement a customized version of VS Code because it is completely free-for-all.

You should take a step back and think about why it makes you frustrated and disappointed - someone's choice of their tools should not be affecting you on a personal level. I'm assuming they were not using Eclipse before that, and they just feel comfortable using what they've been using for some time. Think about how they'd feel if someone forced them to use another editor they are not familiar with, wouldn't that make them frustrated?

AFAIK we did not have anything like that; our work has no external interfaces to provide support of any other program/editor/IDE. I cannot get down to details because NDA is there.

Technically we can remove emacs from our Linux VM and force everyone to start on VS Code. But like you can guess it is a crazy and dangerous idea. We don't want to make people sad and outrageous. OK maybe I am a little bit overreacting.

That's like different shape of learning curve, I guess? VS Code can have pretty "good" experience when someone knows nothing about what he/she gonna do and how to do it. But eventually he/she may find out VS Code cannot be as customized as emacs/vim. On the contrary, emacs/vim can be more difficult to learn; but once you take full grasp of them, you are in promised land.

If you have custom language requirements, why not use LSP so it would just plug into every compatible editor?

I'm only 22 and I've been using Emacs for 4+ years now. VS Code any more of an IDE than Emacs is, most languages have LSP implementations now, so it's really down to personal preference. Of all the editors I tried after giving up on Eclipse (including VS Code), Emacs has been the best experience so far. Emacs has flaws, and those might eventually push me to switch to something else, but right now VS Code just doesn't work for me. It's not even my second choice.

Have you heard of [Chesterton's Fence](https://fs.blog/chestertons-fence/)? Or paused to consider what these senior people know that you don't, specially about flash-in-the pan fads (as well as how unwise it is to trust a commercial company for your critical tools)?

Great read!

It actually is a little worse than that. Emacs becomes better *as you become a better programmer.* The better a programmer you are, the more you can take advantage of emacs, and emacs actively helps you become a better programmer, because it places things just slightly out of reach for the way you expect it to work. At some point your realize emacs is a custom UI to your computer and most of the world. And it doesn't have a limit. VSCode bakes a little higher, those pain points you worked to smooth over prevent the pain points that encourage learning in emacs, and then finally if you get past that initial hurdle to fully customize VSCode, you hit its limit, which is that it is a browser. Emacs being a UI is important. VSCode gives you what you can get from a web page to use, while emacs gives you the whole computer. You can interface with C, which means you can talk to everything in whatever way you need to, not just through a websocket you have to create an interface for. Finally, there are 40+ years of UI learning in emacs for productivity. New and shiny do not mean it is better, things that will last you til the end of your career are better than the new hotness that will be replaced for this or that reason. Emacs is free in every sense, so it has all of these advantages over VSCode.

I can almost guarantee, those guys will either quit, or find another way of using emacs. This is how companies lose talent, they place hurdles and pain points in their way. There is an old saying, if it ain't broke, don't fix it. Now, if emacs is affecting their ability to perform their jobs, that needs to be addressed. I would bet, however, one of them will have or be working on a solution that you never notice because they just fix stuff and move on, right?

Emacs is not a CLI based editor. It can do that, but it doesn't just do that.

[deleted]

They actually love it.

Why are you or other people disappointed that they do not give up Emacs?

I’m 55, but a sysadmin / devops guy. Ive used many text and code editors over the years, and only picked up emacs in a serious way during some enforced downtime last year. I’d say it’s both. I feel like I have some time invested in learning to use it. The longer I use it, the more customized it becomes and it comes to suit the way I like to work. An analogy here would be buying a good pair of boots: the longer I wear them the more they adjust to fit me. And .. I like using emacs. The terminal emulation with vterm works for me. Terminal and editor in one pane, todo list on my second display. It works and it’s fun to use.

> They use emacs for checking logs, edit commit messages and coding. Seems pretty convenient that you can do all of that in one application, doesn’t it? > I know when they grew up and started to learn programming, there may have no fancy GUI editors/IDEs for them and they had to start from something like emacs and vim. I grew up with IDEs and have plenty of licensed IDEs from which to choose at work, and still use Emacs for everything other than super complex, tens-of-thousands-of-lines-long C++ projects. > But now we have introduced VS Code (previous IDE is Eclipse) for production environment; young colleagues love that: **it is faster, more responsive, robust and beautiful.** I’m actually not even sure if you’re joking at this point. VS Code (and Eclipse) are both quite slow on startup. As far as responsiveness and robustness go, [the issues page on GitHub for VS Code](https://github.com/microsoft/vscode/issues) seems to indicate it may not be as robust as you believe, especially when compared to software that has withstood the test of time for over half a decade. Young colleagues love VS Code because 1. Most of them used it in college or had it recommended by someone else; and 2. It is free. Most of my colleagues who are 20-30 have no idea what Emacs even is; but they also don’t use VS Code because my company offers licenses for paid IDEs, such as CLion, which is what they use instead. > We actually can monitor how many colleagues are using VS code/Eclipse, but it is disappointing to find out most of senior colleagues still stick with emacs. I would wager that more of your developers would switch to Emacs if they knew how convenient it is and, once you get over the initial learning curve, how much more customizable and effective it is than VS Code. I can edit remote files without having to open another terminal and SSH into it, I can connect to databases without opening another application, I can commit and push code changes in three key presses, I can write well-formatted documentation and export it to other formats, and I can easily write new code to extend Emacs if I need something. Can VS Code offer any of that? *That* is why senior developers (and junior developers) still use it.

See also https://old.reddit.com/r/emacs/comments/xxfeur/what_do_you_tells_vscode_and_jetbrains_naysayers/

This is kind of a strange post. Why is it disappointing that people are using emacs? It is still regularly updated and there are a large number of very powerful packages for it. I fail to see why this means it is an antiquated tool. If anything it seems to be a very modern tool with a lot of features.

It’s pretty obvious that you are very ignorant about what Emacs actually is or what it does/can do. Many have commented various reasons for why people “still” use Emacs, but one I’d like to add is that Emacs actually includes a text editor. Well, at least two of them. And both are superior to anything I have ever witnessed in an IDE. I for one will not touch any IDE with a 10-foot-pole which requires my fingers to leave the home row to move the cursor (yes, my keyboard layout has arrow keys on the home row but that is beside the point).

This is the right question, right here.

"They" and "disappointed" hints that you never really talked to your "older" colleagues to understand what they need. The "older" vs "younger" segmentation is another problem in how you perceive the situation. Apart from your hurt ego, the lack of desire to meet your users on their ground is major Product Management failure, your department is both uneducated and arrogant. Last: your mental model of the emacs users is totally broken, biased and ageist. You don't understand what you are criticizing.

Our idea to to provide standard and easy-to-go environment to all. Before we introduced customized internal-use-only IDEs, colleagues have to configure their own IDE; that's not very efficient and we cannot possibly to support all of them. The guys before us chose to have Eclipse (years ago), and we chose to use VS Code. We use many commercial softwares in various situations, even in critical areas. We deployed RHEL in our production environment which is used by thousands of developers everyday.

Prettier is debatable too. To me they are just bloated!

When we decided to start the development and deployment of VS Code, we were thinking "one IDE to rule them all".

1. We don't SSH in our production environment; we have Linux VM for everyone. 2. We made debugger integration; you can just start debugging session in our VS Code now. 3. Git extension is there, out-of-box. You can do all daily Git operations inside it. 4. We do listen to our users' feedback; maybe our implementation is not in a timely manner but we treat them seriously.

I am not here for criticizing emacs and its users. I am simply curious about why they choose emacs prefer IDE.

We can, and have well foreseen the outcome of mandating VS Code for everyone; and that's the reason why we are not doing that.

Wow! Thank you for that link.

I’m assuming you are talking about GitHub Codespaces. I don’t understand why anyone would lock themselves into a Microsoft monoculture when GitPod is open-source and self-hostable, thus open to all.

You can also both compile and debug directly within Emacs, as well as specify linters and other features. I also noticed in another comment you’re working with proprietary C-based code, which could easily been implemented into Emacs (assuming one of your developers has not already done so). As for the git functionality, I’m sure there are various implementations for VS Code, but I would be surprised if any of them come close to *magit*. You can spend five minutes in this sub and it becomes readily apparent why this software is so revered. The community genuinely loves this software and contributes to it every day. As funny as it may sound, Emacs is a way of life to some. Once you begin using it and start integrating it into your work, it’s difficult to switch to something else. I primarily switched to Emacs because we use OneNote for note-taking at work and it’s atrocious. I started using Org Mode and gradually began using the IDE features for Python and Bash scripts and then other extensions, and since then I have used it for almost every aspect of my job because it’s so many softwares combined into one. I would honestly reconsider my employment if my company tried to tell me I couldn’t use a free and open source editor that vastly increases my productivity.

I didn't say you criticize. (Ok, I did) It's great you are curious. Go ask your colleagues!

(student) I needed to use a large (53Mb) file a few days ago. It was some generated data somebody sent me. And just having it in the project directory forced CLion to take up 7 extra GB of RAM (tested by checking the memory usage, removing and adding the file a few times, doesn't seem to change or settle), no wonder it crashed on my laptop which has half that. I clicked all of the, never analyze, don't consider, but it didn't seem to care, after a few 10s of minutes I gave up, probably I pressed something wrong I dunno. So I just finished this thing off in Emacs. Which didn't have problems even with LSP running. The one thing Emacs lacks is multithreading, which means that blocking functions will by default lock up the editor, that is why I also thought that Emacs was not too responsive, luckily there's tons of ways to get around that for almost every case now and most big jobs just run outside in another process. Maybe the performance complaints are from people that load a million plugins that all start and hook at every possible turn. Vanilla Emacs is very powerful and honestly effectively as fast as Vim (can't notice) in my experience, but taking the slightest bit of care in what you include and how makes it stay that way (which is not for everyone, I guess). Even modern browsers have plugins that can just tank their performance.

We asked. And we implemented the most wanted features and performance improvements. Due to the nature of this work we cannot satisfy everyone’s special needs but I would say most of the needs are met.

>most of senior colleagues still stick with emacs You are mistaken. They are **not** sticking with Emacs. They are sticking with their **own personal configuration**. If you give them a pre-configured Emacs, they are still not going to use it. You may give them uniform shirts, but there is no such thing as uniform underwear. ​ >I know when they grew up and started to learn programming, there may have no fancy GUI editors/IDEs for them and they had to start from something like emacs and vim. I know you have the best of intentions in mind. But, at the end of the day, that's just a shallow and patronizing way of deconstructing your senior colleagues. Instead of being concerned about seniors using Emacs, it would be better to ponder about their productivity, their knowledge, experience and so on. Can they give some training to the younger colleagues? Are the deadlines too tight? Is the team undermanned? Are people getting burnt-out? You know, these kind of things. ​ >We actually can monitor how many colleagues are using VS code/Eclipse Telemetry can be a huge turn-off.

I find that Emacs performance is poor primarily when you use a lot of the add-on packages that add a bunch of features. The core functionality of Emacs is fast. The first thing I notice when trying to use VS Code is that VS Code is slower. However, LSP integration is a leading edge feature in the "editor wars" and Emacs' LSP integration certainly isn't as smooth as VS Code's, since VS Code is essentially the reference implementation for an LSP client. This question is posed to "older" more experienced Emacs users. I suspect that many of these folks don't mess around with the latest hot new thing on MELPA, or the more "bloated" Emacs distros out there.

> Our idea to to provide standard and easy-to-go environment to all. There is no problem with that, but don't expect to provide something that makes everybody happy or most productive. Let the Emacs, and the Vim, and the Neovim folks use the tools that is less frustrating for them. I have never worked in a place where Emacs was an officially supported development environment. It has always been community supported within the company.

When I read that other comment you refer to yesterday, I couldn't help wondering how many of those millions of lines of code were written by those senior colleagues, in Emacs. I couldn't help wondering which of your polarized camps is, generally, more productive. And it seems to me the Emacs use itself should have been a clue that you all missed when undertaking this project: People who are using Emacs in 2022 are making a deliberate choice, and they have already demonstrated that they're not inclined to chase "the new hotness." They have already seen many of them come and go. It's not that they don't know how to run VS Code or can't adapt. It's that they don't believe reinventing the wheel every few years is a good use of their time when they already have a very powerful, adaptable tool that they know inside and out, that has already stood the test of time, that they have tweaked to meet their approach to things, that has long-term viability and stability, that isn't going to be dropped when the fads of the computing world move on to the next new hotness, and that still meets all their needs. You might stop a moment to consider whether their experience has lent them some wisdom in this question that is worth factoring in the next time a new hotness rolls around.

Well, I never dream that I would ever have privacy on corporation-owned devices.

The point of the Chesterton's Fence analogy is not that you must understand what you're trying to implement, which obviously you would, but rather that you understand what you're proposing to tear out and replace and why people value it.

VScode is a flaming pile of shit compared to emacs or vim.

You should have picked a better IDE then.

We took case studies on various of IDEs, both free/open-sourced and commercial/proprietary. And at last, VS Code wins.

"Evil prevails"

You are right in saying that, and I'm of the same opinion. But then again, lack of privacy is a problem, even if it's "expected" in this context. And do you really want to become part of this problem? On the other hand, at least you are being open and transparent about it; that's better than being shady.

>Our idea to to provide standard and easy-to-go environment to all. IMHO this never works, a development environment is something that you have to figure out for yourself. It grows with the developer over time. If you force them to use all your settings it will never make anyone happy.

You are not allowed to track certain things even on corporation owned device. I think those things are pretty well defined. Are you in the U.S.?

Technically such limitations do not exist. There are too many grey areas in this aspect. But don’t worry too much. I never see anyone gets any trouble for watching cat videos on YouTube. Of course, I don’t recommend to watch PornHub on that. Illegal downloads of copyrighted material is strictly prohibited also.

I say the following with great respect and with compassion. Believe me. I do believe that whatever energy that went into that exploration and decision to try to settle on one IDE was not a good use of the energy. And perhaps you have realized it. And I commend you for coming here for more information. Basically, the editor one uses is a bit like the clothes one wears. We all have very different preferences. The main thing is that the editor 'gets out of the way'. For some VSCode would seem in the way, for others Emacs would. Both editors are customizable, but how they are so will depend on the knowledge and preferences of the user. One thing to be careful about is associating Emacs with antiquity. There are some very young users embracing it, particularly in the realm of Clojure. I would suggest a U-turn. You could even invite an Emacs user in your organization to put together an Emacs presentation. It's possible feathers were ruffled and you should work to smooth them out. I use VSCode, Emacs and IntelliJ and I like them all. It's not either/or but and/and. There isn't actually an IDE 'winner'. It's only the code that can 'win'.