I think so (and hope so!) - there’s so much community investment around nREPL that it’s been sad to see it languishing. Chas seems keen to reinvigorate it and there have been a couple of people investigating things like a native CLJS implementation. It’s a somewhat difficult situation that there are two camps, people who believe that streaming REPLs are superior and those who like nREPL :-). I’ve found an RPC model easier to develop tooling over than pure streaming, but it’s not without its limitations too, especially around user input. Like most things, it’s a tradeoff - the problem is that it’s difficult for tools developers to write functionality supporting both (as I’m sure you’re aware!)
3 Likes
I’ve been (very pleasantly) surprised how well Cursive has been selling, before I started I really had no idea how many people would be interested in paying for tooling. Clojure is still a niche market - Cursive pays me a great salary, but it doesn’t pay me two great salaries so growing a team would be difficult even if I wanted to. By contrast, I think JetBrains have about 15 people working on PyCharm and they have multiple hundreds of thousands of users - it’s a totally different ball game.
In terms of growth, sales are pretty spiky so it’s difficult to tell. Currently my sales for the last year are slightly down on the previous year (I don’t maintain great stats so I’m just eyeballing numbers from my payments provider), about 5%. But it doesn’t take many sales to make that up, and when I first started selling Cursive there was a large spike as everyone in the beta program paid for it, so I’m not worried about it. I’d say it’s about stable over time. It’s an interesting figure as a proxy for Clojure community size - sales are generally the derivative of community growth, so perhaps the community is growing linearly? I’m not really sure though, since I don’t give back money when people stop using Clojure.
But the important thing for me is that Cursive is definitely sustainable financially for me at the moment, and it’s a really fun thing to work on.
6 Likes
In general, my main obstacle is just time - developing plugins for IntelliJ is a lot of work, and I do a lot of support work which leads to a ton of yak shaving. I’ve been planning better CLJS REPLs forever and it just always seems to be the next thing I’m planning to work on.
Two things that immediately spring to mind as hard to implement are better macro support, and boot support. The macro support is hard because it’s basically going to be an API to the Cursive internals, which will require documentation, support and so on. I also have a couple of fairly bad fundamental decisions which I made right at the start which are still blocking that. That’s an ongoing project which I’ll get done one day.
Boot support is hard because boot is so dynamic. Cursive (or IntelliJ, really) needs a bunch of static information about a project in order to index it correctly - which libs are dependencies, where are the source folders and so on. Lein is at least somewhat declarative so I can get that information out even though it’s surprisingly tricky at times, but it’s really hard with boot because that information can be calculated by any arbitrary code. I have a plan to do this with a mix of static analysis and just invoking custom boot tasks to get that information, but it’s a very hard problem. It’s one thing that gradle did really well - gradle is extremely flexible but it was designed with IDE support in mind so it supports that much better than boot.
2 Likes
Do you think some bits of Cursive can be extracted and be useful to tools like CIDER (or any other Clojure IDE for that matter)?
1 Like
What are the missing Clojure(Script) features that would simplify your life as an IDE author?
What are the missing things (libraries, tools, funding, whatever) that prevent us from having exceptional IDEs for Clojure development today?
This is difficult, unfortunately. IntelliJ has its own AST classes that my AST elements have to derive from, so code working with standard Clojure datastructures or e.g. the tools.analyzer AST format doesn’t work in Cursive, and the Cursive code doesn’t work with them well either. So I have my own Clojure reader, essentially (it’s a classical lexer + parser, not much like the actual Clojure reader). Most of the JetBrains IntelliJ plugins end up having to do the same, more or less reimplementing the semantics of the language which is a huge amount of work in some cases (e.g. Scala or Rust).
1 Like
Are you thinking of putting together a build of Cursive that’s a single downloadable ‘Cursive IDE’ package so that you don’t need to install idea CE and then add cursive as a plugin?
Static types? 
Actually, as dynamic languages go Clojure is surprisingly easy to write static tooling for, mostly because users tend to not go crazy with macros or dynamism.
More than the language itself, things like build tooling have been a major pain point, both lein and boot are pretty difficult to integrate into something like Cursive.
If people end up using spec for their macro forms, that will help develop functionality for them in Cursive because the grammar will already be written. I haven’t seen anyone doing that yet though.
5 Likes
What improvements would you expect from ‘better CLJS REPLs’ from the perspective of a Cursive user?
What made you decide to write Cursive and build a business around it?
1 Like
This is something that I’ve been thinking about for a long time, yes. However the benefit is currently pretty small - Cursive is pretty easy to get started with these days, you don’t even need to download a JVM (IntelliJ comes with one bundled which you can use) or lein.
Developing this is a lot of work because there’s a lot of black magic in the build process to do so, and it’s currently totally undocumented by JetBrains. I’m hoping to work with them at some point with the promise of documenting the process for them, I’m sure they’ll be keen to collaborate on that. I’m also a little worried about cross-platform support, which is currently an almost total non-issue for me - JetBrains have done a really great job of making IntelliJ work everywhere.
That said, there are a couple of use cases that this would be great for that I’d love to support better - things like ClojureBridge and also use in academic environments. As part of making a single downloadable build, I’d also like to modify the startup process to offer the possibility to simplify things, i.e. hide a lot of menus and UI by default, and have a simple UI similar to DrRacket so it’s not so intimidating for completely new users. But again, that’s probably quite a lot of work.
3 Likes
In no particular order: ease of use (i.e. just be able to click a button and get a CLJS REPL configured and running with figwheel and so on), the various niceties around the REPL which the Clojure support has such as macroexpansion, and things like better output formatting and highlighting. I’d also like a CLJS REPL to have a CLJ view and a CLJS view and intelligent switching between them - CIDER already has things like this but it’s currently very clunky in Cursive.
I’m also planning better support both in the editor and the REPLs for self-hosted CLJS environments like Lumo and Planck, so you’ll be able to just add a Lumo module to your project, tell Cursive where your Lumo is installed and spin up a REPL.
4 Likes
We already have them! I actually think Clojure has really good editor support now. CIDER has much better Clojure support than most language modes in Emacs, proto-REPL is really nice for Atom and Cursive is good for IntelliJ. It’s hard to compare Cursive to JetBrains’ language support plugins since they have so many more resources and it takes so long to figure out IntelliJ plugin development, but Cursive is more polished than most other third-party language plugins.
I think the main thing that will always help is a larger community - that just leads to more OSS contributors, more money from companies for tooling, etc. One thing I would like to see is more people contributing to existing tooling projects rather than starting new ones - it’s always fun to build your own thing and working with large existing projects can be messy and, well, not fun. But in a lot of cases we’d be better off with improvements to what we have rather than new things, since what we have is what people are already using even if it’s not perfect.
5 Likes
Similar question: How did you initially decide that the market for Cursive could be big enough for it to be sustainable?
1 Like
You presented quite some interesting ideas regarding error messages — are you still integrating those ideas into Cursvie?
If you could go back and start the project again, would you build Cursive fundamentally differently, or go about it mostly the same?
1 Like
As all strict necessities have been integrated into Cursive, I was wondering what Major Items you are working on. Any possibility we can get a glimpse of what’s coming?
Is it useful to allow IntelliJ to send crash reports to you, or do you not actively inspect those from time to time? (I probably hit that Send button about 20 times per week - mostly to get rid of the annoying flashing red icon.)
I’ll answer both of these together - initially Cursive started life as a fork of La Clojure, which was a Clojure IntelliJ plugin made by some JetBrains devs in their 20% time but was mostly abandoned at the time. My previous job was pretty stressful, and I’d decided to take some time off when that job finished for a sabbatical and work on something interesting for a while. I was interested in playing around with Clojure but I wasn’t keen to pick up Emacs again, I’d used it for years a long time ago when I worked with C++. So I started working on La Clojure and migrating a bunch of it to Clojure (it was all in Java) and I’d built up a pretty sizeable fork. I was about to submit it back when I started wondering if there might be a product in it. I really didn’t do a lot of market research, I just asked on the mailing list if anyone would pay for a professionally supported editor and a few people said yes - after that it was mostly just hoping for the best.
3 Likes