GNU Emacs + Cider vs VS Code + Calva

VSCode is much friendlier to beginners, uses a UX language that is more modern with more modern shortcuts, and it plays well with Windows.

I never liked Emacs’ parallel universe of short cuts. A couple of decades growing up on windows, using C-x, C-c, C-v, C-z, for cut, copy, paste, undo (especially after writing many many papers…). So the first think I do when working with folks coming to Emacs from a windows background is have them turn on CUA-mode, which turns emacs into more-or-less an advanced notepad for them. Then instead of flailing around trying to learn new shortcuts and avoiding the mouse via the “Emacs way” (which is honestly weird), they can immediately apply what they know and get to work (similar to what you get with VSCode or any other typical editing environment). Use familiar keyboard/mouse interactions and emacs feels far less alien. Migrate toward keyboard only if you want/need to later (extremely advantageous when accessing remote machines via terminal).

it is unclear to me which editor

Spacemacs + Clojure layer (includes Cider) + CUA-mode is my go to. I am fascinated by the growth in usability of the VSCode world though; the out-of-box experience is pretty excellent, and probably welcome for beginners. I think the emacs setup will grow with your for the long haul, since you can use emacs seamlessly for everything (e.x. editing org, latex, html, whatever…). Any time I have needed to edit something, I find a spacemacs layer or an emacs package for it. So the “ecosystem” is incredibly robust IMO, even without all the customizations you can apply.

I am unsure about the debugging situation in Calva, but Cider’s debugger integration and inspector are really nice. I tend not to use them a lot, but when I have needed them they were invaluable.

2 Likes

Even as a long time emacs user, on and off for about 30 years, I would always recommend Code + Calva, or perhaps Intellij + Cursive (if you’re used to Intellij. Calva is super friendly and @PEZ is a very responsive maintainer.

The interactive getting started guides are also very nice in Calva.

One tip though, is to spend an afternoon teaching yourself the basics of paredit. barf/slurp, forwards/backwards sexps are such time savers and they reduce all the friction you might have with the parens.

3 Likes

For now I am going with Calva.

spend an afternoon teaching yourself the basics of paredit. barf/slurp, forwards/backwards sexps are such time savers and they reduce all the friction you might have with the parens.

Will do!

2 Likes

I hope you’ll enjoy it and will chose to stay! Please consider joining the #calva channel on the Clojurians Slack. It’s a typical Clojure community place, I would say. Full of friendly and helpful people all interested in seeing others succeed.

As for the major thing lacking in Calva, compared to CIDER, I think that is the inspector. Maybe lately that has become a less glaring hole, because of tools like Reveal, Portal, shadow-cljs, and more.

2 Likes

I think the conclusion to take is that the relevant choice is more about Emacs vs VSCode, because in terms of Clojure, both Cider and Calva are pretty similar in their feature set, with Cider having just a little more features but nothing major.

1 Like

I don’t think anyone has mentioned it but emacs is customized and extended in eLisp, and VSCode in JavaScript. I’m starting to see Lisp as my environment, rather than my Linux OS or the browser. I’m thinking of installing the GNU Guix package manager so I can configure Linux in Guile Scheme too. I’m sure working in three different Lisps won’t be confusing :slight_smile:

I sometimes use very slow machines with low memory. VSCode isn’t practical there. Emacs can be used without a GUI, though that’s not very useful for productive ClojureScript development.

2 Likes

I’m starting to see Lisp as my environment

It has begun :slight_smile:

3 Likes

Stop before its too late :smiley:

I was initially drawn to Clojure because it was a Lisp. I wanted to experience code as data. Now I have, why would I ever give that up? :grinning:

1 Like

Calva is written partly in ClojureScript, and there are extensions written entirely like that. Full hot reload and all that. Also, with tools like sci we will see more end user customization using Clojure.

3 Likes

One thing I haven’t seen anybody mention that is a decider for me is that emacs runs fine via ssh X11-forwarding. VSCode, being electron based, does not support this use-case.

(I have a windows desktop, with ubuntu VM’s. I connect to the VM’s with putty and XMing. In this environment emacs feels very close to a native windows desktop app which is lovely.)

4 Likes

I suggest there is a far greater difference in user experience than specific Clojure features.

Although both VS Code and Emacs can be configured to work in a very similar manner, using VSpaceCode and Spacemacs, which even share very similar key bindings (partly because I contributed many of those key bindings to each project)

There are even a lot of cross over between packages.

So as a user there can be just a difference in UI, even then the differences are becoming increasingly few and far between.

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)

There is a really wide support for Clojure in many editors and most can be configured to be relatively equivalent in Clojure specific features

https://practical.li/clojure/clojure-editors/

Hope this helps
John

1 Like

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.

3 Likes

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.

1 Like

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
1 Like

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.

2 Likes

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.

6 Likes

My advice to anyone starting their Clojure journey who is unsure about what editor to use:

  • Pick something today and start writing Clojure.
  • Probably pick an editor you are familiar with already.
  • If you’re not familiar with any editor yet or you don’t have a strong allegiance to one, choose VS Code and Calva.
  • Switch to something else only if you encounter persistent annoyances that you can’t remove with plugins, code/config changes, help from the community, or more sleep.

I now use VS Code with Calva every day but went through a long journey trying almost every other editor and plugin combo first. I switched from Emacs to VS Code, which might make my perspective different to others here.

I also sponsor PEZ and sponsor Brandon because Calva is exciting to me. I encourage others to support whatever editor/package they end up settling on and using day-to-day. (I sponsor Bozhidar too because nrepl/Cider backs Calva and also how could you not?)

A journey through editors

  • Vim was my favourite editor. I started with Clojure + vim-fireplace, then moved to Conjure for the auto REPL connect and the richer experience.
  • Moved from Vim to IntelliJ + Cursive because Vim is an incredible text editor but a bad IDE. I found myself valuing IDE features that work out of the box more and more for navigating large complex codebases at work (non-Clojure projects, but I like to use the same editor/IDE for everything).
  • Moved from IntelliJ to Emacs because Clojure people kept telling me I should try Emacs, it gave me similar IDE features (plus Magit!) with more hackability, fewer interruptions (the fatal error report prompt was a daily annoyance with IntelliJ), and because Cursive does not have inline evaluation yet (it’s coming soon maybe, though).
  • Switched from Emacs to VS Code when I realised how much time I was spending tweaking Emacs to behave in ways that IntelliJ and VS Code do by default, and after experiencing repeated small annoyances that led to spending evenings and weekends writing Emacs Lisp instead of Clojure. A handful of examples that are still fresh:
    • Configuring whitespace conventions automatically when an .editorconfig is present but inferring spacing from the project otherwise.
    • Trying to get save-on-entering-normal-mode hooks working with evil. (There are various approaches posted online but all have gotchas.)
    • Trying to hide irrelevant buffers in Ivy.
    • Trying to get Treemacs and Projectile playing well together. (I eventually got this working after a day or so.)
    • Having to configure gc-cons-threshold values to prevent repeated occasions where the point would freeze for a second or more (running Emacs on macOS on a maxed-out MacBook Pro).
    • Tracking down the modes that Ivy should use regex–fuzzy and the modes it should use regex–plus to make it feel like VS Code/IntelliJ finder-pickers do by default.
    • Spending hours tweaking LSP servers to work well with Emacs via settings buried in inconsistent documentation (generally a fault of the LSP servers, which tend to be configured by default for VS Code users and have VS Code plugins to make configuration quicker and discoverable there).

Why VS Code over Emacs?

I tried Doom Emacs, saw the potential, then built out my own lighter custom config from scratch to understand Emacs better.

I don’t consider the time wasted, but I also now have an understanding of why “make Emacs popular again” movements haven’t yet driven real change. A fair contingent of Emacs users are content to individually spend their literal working lifetimes customizing Emacs to their needs as a point of pride, for better or worse! Some consider that a willingness to follow that same path is the price of entry for new users and that Emacs shouldn’t bend to them. Popularising Emacs in terms of both “get more programmers to use it” and “get more non-programmers to use it” would probably now mean collectively thinking about, agreeing on (this always seems to be the hard part), and making changes to defaults that a large contingent of users have effectively been working with and around since the late 80’s.

Reading about Bodil making a similar transition to VSC but after 20 years with Emacs, as well as this thoughtful essay on VS Code’s momentum and likely staying power helped me feel better about leaving Emacs and the inevitable nerd points I would shed.

After trying VS Code for a week with Calva I was sold. Emacs has its perks, but I managed to replace most of the things I miss from Emacs:

  • VS Code has a Magit! port called edamagit that I’ve contributed to and am happy enough with.
  • Swiper has a (less good but useable) equivalent in Fuzzy Search.
  • Which Key is a VS Code equivalent of the same thing from Emacs that makes keyboard-driven VS Code and generating custom mnemonic key maps a pleasure.
  • File Browser from Bodil makes file navigation and creation much more pleasant and Emacs-like.

I started with the jaded assumption that VS Code was probably bad because it’s built by committee at Microsoft on a web-tech based Electron stack, only to find that it succeeds in embodying the spirit of a “hacker’s editor” more than even Emacs does in many ways:

  • Better at day-to-day text file and terminal management out of the box than Emacs/Neovim/Vim (file switching, file tree browsing, terminal multiplexing).
  • Arguably still better at IDE basics even when you’ve configured Emacs to allow quick file switching/searching/terminal multiplexing. (libvterm is probably the best Emacs terminal option but it’s still slower and less easy to manipulate than VS Code terminal splits. Projectile is great but some of the default behaviours feel odd to an IntelliJ/VS Code-native; I think by default it still keeps previous project buffers around when switching projects, for example. Ivy is lovely but surprisingly hard to configure if you don’t want it to appear at the bottom of the frame; there is ivy-posframe but I found it would make closing Ivy require multiple attempts sometimes).
  • More consistent cross-platform than Emacs/Neovim/Vim. (In particular, Windows support for Emacs is understandably not great.)
  • Easier to extend and theme than Emacs, Vim, and IntelliJ if you’re already very fluent with JavaScript or TypeScript.
  • Has a better accessibility story (certainly compared to Vim and Emacs, but also for IntelliJ which only claims to be accessible on Windows).
  • Likely to be the editor a friend or colleague is already using when they say, “can you show me that Clojure thing you keep raving about?”, at least if you work in frontend/fullstack development.
  • Popular enough now that it probably isn’t going away or being superseded any time soon.
  • Free in terms of both, “you don’t have to pay for it” and, “you don’t have to adopt a philosophy or wear it as part of your personal identity”.

On the benefits of Calva:

  • Of all the amazing Clojure community projects, Calva seems most likely to encourage new users to try Clojure and ClojureScript. A lot of developers use VS Code. It’s been tricky to convince frontend developer friends to try ClojureScript, but at least they don’t have the excuse that they’ll need to switch editors to even try it now. I think as a community we should try to support the projects that encourage Clojure’s adoption and ease of use, including by using those products ourselves.
  • Calva provides a better first-time experience than any other editor/plugin combo whether you’re new to Clojure or not. You can install the plugin and be chatting with your REPL in under a minute without any knowledge of Elisp or VimScript/Lua or how to configure Run Configurations in IntelliJ.
  • The default key bindings are good and the commands are easily discoverable.
  • For its age it’s surprisingly feature rich (Calva already has inline evaluation, for example.)
9 Likes

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.

5 Likes

Those questions never end, do they? :slight_smile: 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. :beers:

13 Likes