GNU Emacs + Cider vs VS Code + Calva

[didibus]

@jr0cket

I don’t believe any editor is any easier than any other editor for someone with no preconceived idea of how to use an editor. It just needs a good user guide (they are too feature rich to be intuitive)

I think the difference for me, with Emacs (which is what I prefer and use), is that similar to linux, it does not go through thorough review and QA processes before release, and a lot of the features are provided by different people collaborating distantly in the open-source, on mailing list, with no dedicated team, and that has the benefit of having a lot of innovation, but also it means often things break, and it doesn’t always work in all setup, etc.

But, similar to Linux, and this is where I say Emacs is not as “easy”, as a user, you can learn to self-diagnose and fix all such issues yourself. This is the beauty of Emacs, but doing so is next-level compared to just someone who needs an editor, you have to learn to program in ELisp, understand the design of the Emacs code-base and how things are modeled, etc.

As a programmer, this appeals to me a lot, since I can program and know Clojure, learning ELisp is not difficult, and that gives a lot of power to customize everything and fix issues I face myself. And customizing Emacs and fixing issues with it is done using interactive REPL driven development, best of all worlds.

But I reckon if you are new at programming, are not a programmer, don’t know Clojure or Elisp or any Lisp, are not a fast learner, or don’t have time to learn, because of that I say Emacs is “harder”, because in my experience, it won’t work “out of the box”, and when it doesn’t, “fixing it” often requires programming like diagnostic on your part.

Similarly, I’ve find VSCode works more often out of the box, Microsoft controls most of it, and keep things more in check so they work, does extensive QA, and all that. You can still have extensions that don’t work, but you’ll use much less of them overall, and they can’t do as much as they are more restricted.

The actual UX, well I think I’d agree, if you come at it blind with no prior expectations of what “standard editing shortcuts are” or how a “GUI” should work, or what a “window” is compared to a “frame”, etc.

[jr0cket]

I dont know what Emacs version or Linux distributions you are using, but all the versions I use as heavily reviewed and QA’d. I am sure the Linux Kernel team may wish to dispute your claim. My laptop is even certified to the release of Linux I am using.

I have a very different experience of VS Code. I have 10 extensions and only 1 of those is by Microsoft. I have no understanding of the QA process that Microsoft undertakes for VS Code itself, but what ever it does not seem to be the disaster that all their other software products are.

And no, in my experience having installed VS Code on about 50 different laptops (for ClojureBridge London), most of them the many different versions of Windows, VS Code is not out of the box. I would argue that nothing is out of the box on Windows unless its pre-installed (which is why Microsoft spent decades ‘encouraging’ PC manufacturers to have Windows pre-installed).

But now we are both way off topic so wont be replying further to this discussion.

[didibus]

I encourage people to use Emacs and Linux, that said, I want to set people’s expectations, I personally use Linux and Spacemacs, so I definitely prefer them and recommend using them for Clojure development. But in my experience with people on my team, you need to be ready to get your hands dirty with Emacs, and if you’re not that person, you might not like it, while if you are, you’ll be really happy. And that’s because it tends to require a bit of a deeper understanding of how it works internally compared to some other editors. The closest way I know for people to relate to what I mean, is basically Linux versus Windows or MacOS. It’s a great OS, but might need a bit of tweaking to get it just right for your system and to understand how to get things done will require a little more understanding of the internals, same for Emacs in my opinion.

I’d love to hear from people who aren’t the type to enjoy fiddling with their tools and getting their hands dirty, and maybe who also love Emacs and have not found it problematic in that regard. As I might be worried for nothing.

• Currently on Emacs 27.2 as well as 26.3 with Spacemacs develop branch
• Current Linux is openSuse Tumbleweed and RHEL 5

[PEZ]

@didibus

I’d love to hear from people who aren’t the type to enjoy fiddling with their tools and getting their hands dirty

I don’t mind getting my hands dirty. Not particularly fond of fiddling with my tools. I like’em best when I don’t have to fiddle with them. Which was not Emacs for me. Granted, I only used it for a little under a year, but it drove me a bit crazy. It felt like with everything I wanted to do I needed to spend a lot of time figuring out how to do it, and then configuring things so that it was less awkward. Then I forgot how to do it anyway and needed to check my configuration… Every day I started with wondering what Emacs would surprise me with that day. I kinda love Emacs a little bit, but I don’t miss it the slightest.

VS Code is bliss. I have never ever figured long about how to do something. It is a perfect match to my intuition as that has been formed by other applications I use. It’s fast, it never crashes. It keeps my unsaved things safe. We are buddies. I have about zero configuration. When it can’t do something out of the box, or with some extension, I write myself an extension that does it. I have a few extensions that I haven’t published because I do not have the time to polish and maintain. Maybe this could count as configuration, but it is for rare use cases, so nothing I rely on daily.

[johnchristopherjones]

VS Code has a really good remote story now, though just barely out of a year long beta. With VS Code you can use the official “Remote - SSH” and “Remote - Containers” extensions to work in a project on a remote machine or inside a container. (Every VS Code window is anchored to a project, which is a directory, or a workspace, which is a multi-project configuration file.)

When you open a project over SSH, VS Code runs locally and (with permission) installs a VS Code agent on the remote side, executes it, and talks to that. VS Code appears to respect XDG and everything. In some ways it’s better than X11 forwarding, though FAR less general-purpose. All extensions work normally and you can open normal terminals in the remote environment. Performance is generally pretty snazzy, since you usually get the benefits of both editor-local caching and host-local filesystem access.

[dawran6]

Hi, I just want to provide another data point here. I started learning Clojure using my own free time back in 2018Q3 while having a full-time software engineering job in Java + Python. I picked up Emacs (Spacemacs at the time) around 2018Q4 for no particular reason other than I always gravitate toward ancient technologies. There’s just something about the aesthetics that I love about old technologies. I watched a few Clojure talks using Emacs on YouTube at the time and thought Emacs was pretty cool, and thought I wanted to be like those Clojure Emacs people. I was fairly fluent in Vim keybindings before that, so Spacemacs made the transition a bit easier.

There were lots of challenges to overcome to learn Clojure and Emacs at the same time. And oh boy, that was a lot of fun! I think both learning Clojure and learning Emacs are very rewarding experiences to me. The more time I spent on it, the more knowledge I gained, the more powerful I felt. I really think Clojure and Emacs are the two best things ever happen to my developer career so far.

I’d say that I got pretty fluent in Clojure by 2019Q4 when I got my first and current Clojure full-time position but was still a beginner Emacs. Today, I feel pretty comfortable rocking my own Emacs configuration without using any off-the-shelve Emacs distribution. I can read and write ELisp code (but not so fluently) and know a couple of tricks to debug/troubleshoot issues with 3rd party packages.

One benefit I found from learning Clojure and Emacs(Lisp) at the same time is that many of the concepts are transferable to one another. For example, the REPL driven development I love doing in Clojure is right there for you in Emacs, a highly moldable and inspectable Lisp machine like your Clojure REPL. Also, I couldn’t grasp the idea of dynamic vars in Clojure until I learned it from Emacs Lisp.

I know that the general sentiment towards Emacs is that it is too hard, and I get that. But I mean, what’s fun in learning it if it’s just easy? After using Emacs as my daily driver for almost 3 years, I am still having fun learning bits and bits about Emacs.

[bbatsov]

Those questions never end, do they? I’m once again reminded that I should probably put something on the subject in CIDER’s docs.

That being said, I won’t be making any case for chosing CIDER over Calva. For me the choice was pretty simple - I was already an Emacs user a decade ago and I developed CIDER to have a great Clojure programming experience for myself. I’m happy that CIDER drew a lot of people to Emacs over the years, but for me this was never a goal (converting people from other editors/IDEs). For me it’s clear that if someone is already invested/profficient in VS Code or IntelliJ they should probably go with Calva or Cursive. In the early days of the Clojure community there was just SLIME and afterwards CIDER, so many people were kind of forced to use Emacs for Clojure programming, but this is definitely not the case anymore.

Emacs is a great (the greatest?) editor and a lifelong journey - if you’re up for a big adventure you can consider CIDER as well. If not - there are less bumpy and less time consuming routes that one may (and probably should) take.