Long after you've migrated from your current favorite IDE twice over, we'll still be using emacs.

Long after whatever company sponsoring development of your current favorite IDE enshitifies them twice over, we'll still be using emacs.

Long after you relearn your IDE workflows twice over, we'll still be using emacs.

And emacs keeps evolving and can handle modern development just fine (except for the most garden-walled ones, and even then...), while not breaking our brains all the time with so many changes and migrations and trend changes.

We want to keep using our tools and get work done, not keep up with the Joneses.

I started using JetBrains IDEA 12 years ago and I'm still using it today. My confidence of it being available 12 years later is high.

Yes, if you're talking about a timeframe of ~50 years, use vim and emacs. I just don't care that level of future proof.

> Yes, if you're talking about a timeframe of ~50 years, use vim and emacs.

There isn't any compromises that make vim or emacs less useful than those tools with much less longevity. They are just as good as an editor to even those who don't care if they will be around 50 years from now.

I used vim (and still using it for non-coding text editing today) but I just don't feel it's so powerful that it's comparable to IDEA. Of course it's probably because I haven't properly taken time to learn and configure it. I only know how to move cursor around, search/replace and enable syntax highlighting.

But that's the point: I don't want to take a significant amount of time to learn and configure an editor. I want a IDE that works well almost out of box.

Maybe my opinion will change if one day I decide to try a more batteries-included vim/emacs like Doom.

I wouldn't have a counter to this normally. I prefer to heavily customize my editor without the support of a starter pack. But yes, starter packs like Doom Emacs and LunarVim do a great favor to these editors by enhancing their adoptibility for new users.

I once saw a guy coding Idris in his VIM, having VIM complete everything one could imagine and more. That thing completed whole functions based on signatures and types. And that was all years before the copilot and whatever came up. From then on I believed it, when someone said they could have IDE features in VIM.

There is Jetbrains Fleet already, so we’ll see about that.

And you can expect during the next 12 years people will be asking why you use such an ancient piece of software, then you'll understand emacs users (if you don't already) :)

I remember when people told me on this very site that atom is the future and emacs should just close up shop.

Wellllllllll....

If something has been around for 50 years and nothing has been able to displace it, that is usually because it's pretty good.

I love both my Emacs and the Jetbrain IDEs.

There is not a single modern tool that beats Emacs in ease of customizability and extension.

I'm not sure what you mean by graybeard, but I started developing software 5 years ago. Started using emacs 3 years ago (magit). Wrote my own 1000 line emacs config 1 year ago.

I'm in my late 20s.

I'm sure you can config your beard to be gray in your 20s dude, you've managed with emacs for 3-years!

Systems admin people who deal with computing clusters often use vim.

The availability of vim in some systems is not reliable. Often only either vi or nano is available. Containers may not have even that (not that it's a good practice to edit files inside containers. It's just for experiments). Emacs meanwhile, has tramp. It lets you edit files remotely and transparently - even inside Kubernetes pods. And you still get to use all your Emacs customization.

Someone who uses vim daily will surely not struggle with vi.

You are right about that. What you will miss though, are the plugins and customization while making big edits.

Never missed that on the remote systems. The out of the box vi/vim is powerful enough for most things.

You say that, I remember when my team lead was managing a Solaris box and he asked me to take a look as Vim was not working correctly. So I moseyed over and turns out it was Vi instead of Vim. He got confused by c$ not deleting everything to the end of the line.

I would ssh into remote systems, start emacs as my first command, and do everything inside of that emacs window - editing (scripts, config files, code), running shell scripts and programs, reading man pages, executing make, compiling, etc.)

Others would use tramp mode, and open multiple remote sessions within a single emacs. This makes it easy to cut and paste between systems.

I think you probably don't know emacs if you think no one should find it useful. I highly recommend you give it a go. It may not become your main IDE, but I can guarantee that you'll find it very useful for a multitude of tasks, like a lighter text editor, quick REPL, RSS feed reader, binary file reader, org mode (like an organizer of tasks/notes/literal programming etc), magit (the amazing git client), grepping and navigating easily between search result files... and so many other things.

I am in my early 20s and started using Emacs when I was 18. The reason I use Emacs instead of a more "modern" tool is because nothing else comes close in terms of ease of extensibility.

I would be interested to hear if you know of any modern editors where extending my editor is as easy as writing one line and running "eval-buffer".

What should I imagine under term "extending"? Is that adding new extensions (like in vscode)? I never felt that this is something I often enough to need quickest possible way to do it.

Or do you mean more like changing how editor looks, how many windows/panes/tabs are displayed and where are they displayed?

Literally changing the editor code, to do whatever you want. Emacs is a lisp (elisp) environment mostly with a small C based core for performance sensitive primitives. But the user code is at the same "level" as the Emacs core code.

This is very different from most extensible editors, where extensions are sandboxed and have a limited, controlled API to the core editor, which is kept separate.

This makes Emacs very "malleable", and it's likely easier than with most other tool to change it in custom, specific ways. It may seem dangerous, but it comes from a culture where this extensibility is very front and center, with documented design pattern to support it (hooks, customization settings...).

> small C based core

Count before you post; Emacs now boasts over 300,000 lines of C.

"Encompassing Massive Amount of C Source"

Ok, I should have said relatively, or even better "subjectively", small C source base.

The C base supports many platforms and variants, so only a part of it is used in a running Emacs instance. And to the 1+M lines of elisp one typically had many more extension packages. That's the the "relative".

In practice, when I want to change things I don't hit the C layer. Anytime I had to introspect Emacs to change something I was firmly in the lisp world. I don't remember having been limited by something being at the C level, which are things that cannot be changed dynamically. This is really what I meant: in practice to change Emacs the C level (although big in the absolute, and definitely complex) doesn't show up much and hasn't been a limitation at least to me.

Relative to the Lisp source, it might qualify, but wow. :)

Emacs 29.1, excluding the test directory; top ten languages:

    all          SLOC=2618374 (100.00%)     LLOC=182918  in 2584 files
    elisp        SLOC=1188181 (45.38%)      LLOC=0       in 1566 files
    man          SLOC=501820  (19.17%)      LLOC=0       in 48 files
    C            SLOC=387169  (14.79%)      LLOC=159681  in 317 files
    Texinfo      SLOC=288384  (11.01%)      LLOC=0       in 182 files
    Lisp         SLOC=175786  (6.71%)       LLOC=0       in 1 files
    Objective-C  SLOC=18289   (0.70%)       LLOC=8480    in 8 files
    Tex          SLOC=16031   (0.61%)       LLOC=0       in 23 files
    m4           SLOC=10436   (0.40%)       LLOC=0       in 133 files
    shell        SLOC=6819    (0.26%)       LLOC=0       in 28 files
    C++          SLOC=6240    (0.24%)       LLOC=2924    in 5 files

So your editor works exactly the way you want it to? Just yesterday I made a tiny tweak to a package that I use (doom-modeline). I haven't thought about it enough to make a pull request, so that tweak now lives on my fork on GitHub. It to me all of five minutes to find out where to make the change, have the code open, and the change made, loaded into my running Emacs session and uploaded to GitHub. And bear in mind I'd never looked at the code for doom-modeline before.

Good tools change the way you work because they make certain workflows possible. If it was that easy for you to tweak your editor, you would too.

Because it works, and works well.

Because it's thought out and polished by decades of use.

Because it's extensible.

Your very question, "why are people using an IDE from 1970s in 2023" should provoke some thought. Assuming that these people are not crazy (a lot of them is rather smart and rational), what us so good about Emacs (or Vim) to make it still a preferred choice?

I mean, I'm in my late 20s and use emacs.

Maybe for whatever work you do your IDE works better for you.

In my case, I mostly code in C++. I've tried JetBrains' IDEs and it drives me insane how slow they are to index and I often get freezes when working on really large codebases.

The same applies to Visual Studio (not vscode).

vscode drives me insane with the amount of dumb notifications it keeps popping up. But I can concede that for most people it works well enough. It also doesn't perform nearly as well as Sublime Text. Working on really large codebases is a PITA with vscode.

If I need autocomplete (which I actually don't like that much), LSP works well for my needs.

I'm not an old greybeard (in my 20s) and I solely use Emacs. What's "modern tools"? Emacs has everything; with the Language Server Protocol it is exactly like VS Code and the like, with autocomplete, find definitions, native tree-sitter support. It can even read PDFs, images, man/info pages, browse the web. I don't see any advantage that VS Code has over Emacs.

PS. Try Doom Emacs and evil-mode:

https://github.com/doomemacs/doomemacs/

> browse the web

Been using Vim for a few months now but I was checking out eww the other day (along with learning more about emacs in general) and it’s certainly interesting…

One thing emacs sorely lacks is support for VS Code's LiveSharing protocol. Otherwise I use emacs for everything

> I don't see why people are still using 1970s-era IDEs in 2023.

Because it works perfectly fine? So your reasoning is because is old is bad. That software that old still is being heavily used today is a testament that these tools have something that definitely the latest craze out there don't. And no, I'm not a greybeard, I'm in my 40's and been using VIM since I don't know when, probably more than 15 years for sure.

I'm a 22yo front end dev with (neo)vim as my primary editor. I'm not missing anything from Vscode.

So I'm a long-time Emacs user who tried Vim for a year a while back. What do you like about Neovim?

I have never given emacs a fair shot, so I can't compare the two. Neovim makes it easier to get modern editor features like treesitter and lsp support integrated into the editor. The Lua api seems to have been very well received, so the plugin ecosystem for neovim is thriving. It has also attracted a lot of people outside of the original vim niche (including me!) recently, which means there are more plugin developers who care about how things look and feel to use.

There are certainly some constrains on what plugins can achieve due to nvim being exclusively a TUI, but in my opinion the pros of the editor outweigh the cons.

As to what makes me choose neovim over vscode with a vim plugin, it's a combination of things. One thing I love is that neovim is extremely easy to configure. I also enjoy that everything follows vim rules, rather than some things like file trees or consoles having their own unique rules. I have also become dependent on some vim plugins that don't exist in vscode.

I'm not a graybeard, I'm 28 and I've been using Emacs since I was 15. In that time, in my circle, I've seen notepad++, sublime, atom etc. all come and go. Of course everyone at work uses VS Code, in 2 years it will be New Editor by XYZ Corp.

Being old doesn't imply something is bad. Should we be asking what Emacs and Vim have done right so that they're still being used 50 years later?

A guy in my local Emacs meetup has presented at two EmacsConfs in a row, and he said there were a LOT of participants under 30.

i'll take this banter. it's fun. long live emacs.

There are a remarkable number of people attending our Emacs meetup who are under 30. I wouldn't believe it if I hadn't seen it myself.