Forgive me if this has been asked before. I was wondering if there has been any consideration to maybe begin using JetBrains Rider as a IDE for RemObjects. I am aware that Visual Studio offers free versions and Rider does not however Rider provides more cross platform capabilities and would give RemObjects 1 IDE for all platforms. Right now You deliver Water, Fire, Visual Studio and Command Line tools. Seems like building support into Rider could kill some of the redundancy of trying to maintain 3 different IDE’s none of which provides support for Linux deployments. I could be off here but it seems like working with Rider would be a good thing as it would bring linux into the fold gracefully the external compilers already work on Linux and .Net is a first-class citizen on Linux and Mac as well all the other element languages have been first-class citizens for decades. As far as Visual Studio having a free version RemObjects is not Free and therefore could maybe hook up with Jetbrains to include a subscription to Rider in our remobjects Subscription. I mean If Rider was the default IDE (I already have It) I wouldn’t blink twice at having it bundled in my payment to RemObjects. If I was Jetbrains I would not hesitate to work out a bundled deal for Remobjects using my IDE to deliver their platform. I say this out of frustration that even as dotnet has made it’s way into the xplatform realm that it’s community still looks at linux as it’s a second class system and even though it runs there it is not a real focus so other then VSCode there is not IDE support (they archived monodevelop after making the mac version of visual studio from it’s codebase) seems like that is the same here I would for once love to be able to write and build on every OS out the box without having to macgyver things on linux. Using Jetbrains Rider could make this possible for RemObjects.
Sorry for the delay; I have seen this, and will reply in depth, tomorrow.
Hi Patrick,
thanx for your feedback. Unfortunately it is not as much slam dunk as it might seem — and yes, we have considered integrating with Rider, or IntelliJ in general, before, but rejected the idea.
For one integrating with a new IDE is a lot of work, and a third-party IDE does not actually save as much work over our own, as it adds. It costs exponentially more effort to keep integrated with VS and to add new features into VS, than it does to Fire/Water. SO adding a third (Fire and Water are really one code base) option there is not something we’d take on lightly,
Then yes, there’s the fact that IntelliJ/Rider is a paid IDE option. We already have an uphill battle getting customers to pay for a compiler, when most platforms have free ones, these days. People see the benefits of Elements, as I assume do you, but it’s still hard to compete with “crapy, but free”. Asking customers to buy a commercial IDE (from a competitor, no less) is not really going to make for a good sales story. (Neither is eating the cost and paying IntelliJ out of our sales margin for Elements).
Then there’s the “you save work on Fre/Water” argument, but the thing is: we won’t, because I fricking love Fire and working in (and on Fire), and so do many of our customers. If I have one career goal, it is to never have to work (full time) in another IDE again, because Fire is Just. So. Much. Better. There’s no chance in hell that we’d abandon Fire/Water for IntelliJ (or any other third party IDE option). So that means adding IntelliJ/Rider would be purely additive to our workload (we’d not drop VS for it, at this stage, either).
Also, IntellJ is based on Java, and our entire compiler back-end (which alsom drives IDE intelligence) is based on .NET. And on macOS and Linux, Java and Mono do not do well (read: cannot co-exist at all)in the same process. Which adds another layer of technical complexity to integrating with IntelliJ.
Then there’s also the not trivial fact that I (personally) hate IntelliJ’s guts. That alone is not a showstopper — I don’t particularly like working in Visual Studio either, and luckily I dint have to (but we’d probably also not add support for it now, if we didn’t already have it). But it’s just sooo bad. Everytime I have to deal with Android Studio (also based on IntelliJ), I wanna kill myself. It’s so boatedk, it makes Xcode and VisualStudio look lean. Even if my dislike of it doesn’t universally translate to everybody — is this really an IDE experience I want to wish upon our users? No, it’s not :(.
So that’s my 2 cents. Rather than saying “we’ll think about it”, and know we won’t, i’d better come out and say: then chances of usnintegrating with Rider are close to zero.
As for Linux: we do see very little demand here still (the year if Linux on the Desktop has yet to arrive), but if we’d wanted (and saw the market for) to provide an IDE that an on Linux, I would tend towards a port of Fire/Water to a Linux-native UI such as Gtk which — given how Fire/Water are abstracted — would actually be pretty doable and leave us with a reusable Linux GUI framework/abstraction we could also make available to users. So that looks like the better storey for a Linux IDE (but this too has a very blow chance of happening, unless the demand for on-Linux development changes drastically or we somehow end up with a couple bored GTtk-savvy devs who have no other things to do ;).
—marc
Hello Marc
Kinda figured you would say that LOL. I totally get your stance and have many of them myself. I will keep my fingers and toes crossed that maybe one day your team will actually use Fire/Water to make a Linux IDE and give us that GUI framework that could come from that. for me it’s not so much about Rider or Visual Studio as I too try and avoid them when I can, I just like being able to code where I need to as most everything I do server side is deployed on Linux so as we develop sometimes it is just faster to pull up the Ubuntu Desktop fire up that IDE code your service, test and deploy or even let me containerize my app from a host that will also be my target OS rather then OK how do I get this on that Linux box. When I want to do something that will be deployed on a Mac I pull down the source and code, test and deploy on the Mac it would be nice to be able to do the same on Linux. Thanks for the reply Marc.