GNU Emacs + Cider vs VS Code + Calva

[joinr]

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.

[slipset]

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.

[olavfosse]

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!

[PEZ]

@olavfosse

For now I am going with Calva.

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.

[didibus]

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.

[Andy_Wootton]

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

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.

[joinr]

I’m starting to see Lisp as my environment

It has begun

[olavfosse]

@Andy_Wootton

I’m starting to see Lisp as my environment,

Stop before its too late

[Andy_Wootton]

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?

[PEZ]

@Andy_Wootton

emacs is customized and extended in eLisp, and VSCode in JavaScript

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.

[pieterbreed]

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.)

[jr0cket]

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

[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.