It's been a long time since I last used RubyMine, but I always felt that it was the weakest of the JetBrains tools. And not because JetBrains didn't try hard enough, but because Ruby just doesn't offer a lot of opportunities for an IDE to take advantage of.
I ended up cancelling my subscription over some trivial thing (I think it was the fact that I couldn't quite get the IDE to preserve the indentation of a file. It was an all-or-nothing global setting, but I work on codebases that might have a 4-space indent HTML file and a 2-space indent HTML File in the same directory, and the IDE was ignoring the current style of the file and using whatever indent level I had configured).
It might be the weakest of the jetbrains IDEs[0], but for a long time it was simultaneously the best Ruby IDE for my needs. It had reliable jump to definition when nobody else did. That was key for me circa 2015 when I was coming from Java and struggling with my first dynamically typed language since Perl. There are probably better Ruby editors out there now. I stick with RubyMine because I use jetbrains for other languages and like the consistency.
[0] I won’t say the weakest of their tools because youtrack exists.
> [0] I won’t say the weakest of their tools because youtrack exists.
I realized something shocking while nodding along to your observation: they are a dev-tools company, and made their own issue tracker, but I still have to populate every single field, by hand, when reporting a bug against one of their products. But they have total control over the content emitted by RubyMine > About in order to package up the "what, exact, release and platform is the user on". Ironically, I could file that as a YouTrack against the YouTrack product if I enjoy spitting into the wind
In general it's impossible to "find usages" or "go to definition" when the language not only fails to equip IDEs and tooling with the static typing information that would grant definitive answers to such questions; but even goes further and allows methods to be redefined or even synthesized and defined, for the first time, at runtime, with no corresponding source location or file. Method lookup and dispatch are fully Turing complete (you can `#send` anything, including fully dynamic method names, and respond to any message with arbitrary logic in `#method_missing`), and you can even redraw the method lookup chain and inheritance hierarchies at runtime (includes, mixins, module prepend, eigenclasses et al).
This is not a failing of JetBrains tooling but rather a pervasive language smell and consequence of Ruby philosophy.
It is infrequent that "find usages" and "go to definition" don't work for me on good sized ruby code bases. Both solargraph and ruby-lsp seem to work fine for me. Occasionally, I'm surprised when they don't work. In my recent mileage, that happens once every couple weeks, and I use find references and go to definition multiple time per-hour.
Metaprogramming has fallen out of fashion in the ruby community for the most part. Rails is a great example of where that shift has happened. ActiveRecord used to have `find_by_<attr-name>(<value>)`, which became `find_by(<attr-name>, <value>)`. Sure devs can still go wild with metaprogramming in ruby, but it is generally discouraged.
They work well enough to a first approximation, but it's far from the certainty one has using other JetBrains products (e.g. C# ReSharper) on a statically typed codebase.
RubyMine will give you "Untyped (potential) usage." That's not good enough if I need to make a breaking API change and be sure that I've fixed all the callsites, such that I don't find out that I've missed a spot when the change breaks in production.
For all this talk about LLMs and AI improving developer productivity - what is one click and a few seconds in ReSharper to "Change Signature" or "Pull Members Up," which is a 100% guaranteed safe refactoring that will not introduce regressions, ends up being anywhere from "a few hours" of playing whack-a-mole with usage sites, to "completely intractable" in 15+ year old 1MLOC+ codebases making heavy use of metaprogramming.
If the Ruby milieu has turned against metaprogramming, I say good riddance; but my understanding is that it is still quite deep in technologies like Rails and RSpec in particular, where it's the fundamental secret sauce that enables convention-over-configuration and fluent, natural-language like DSLs.
"Find usages" and "Go to definition" work very well in RubyMine in my experience, at least in normal Rails projects - I use them all the time with command-click.
> In general it's impossible to "find usages" or "go to definition"
> Anecdata that something is effective in 98% of cases is different from provable static verification that works 100% of the time.
Ruby has its faults. But you're not making sense complaining first about the "in general" situation, then complaining about a 2% situation. And it is a 2% situation, I'll add my anecdata as verifying 98% (or better) it works really well.
Secondly, you're mixing concepts of static typing and metaprogramming by saying "the language not only fails to equip IDEs and tooling with the static typing information that would grant definitive answers to such questions." Static typing is not the solution, or at least not the only solution, to metaprogramming concepts. For example, if I statically define a Ruby object via RBS, I may still do the things you list that are problematic.
Thirdly, you're complaining about runtime issues making things difficult for the IDE while doing a lookup. What language and IDE do you prefer that does this so much better?
> But you're not making sense complaining first about the "in general" situation, then complaining about a 2% situation.
The use of "in general" has long established usage in mathematics to refer to properties that hold for all objects in a given collection [0] [1]. Thus, if 2% of those objects fail to satisfy these properties, you cannot say that such properties hold "in general."
> Secondly, you're mixing concepts of static typing and metaprogramming by saying "the language not only fails to equip IDEs and tooling with the static typing information that would grant definitive answers to such questions." Static typing is not the solution, or at least not the only solution, to metaprogramming concepts.
Propose alternate solutions then.
IDEs and tooling (let's leave LLMs and other stochastic methods aside for now) can only inspect the lexical, syntactic, and semantic (types) structure of source code in order to navigate and validate it. Thus, information that is absent from the lexical, syntactic, and semantic structure of the source code, is unavailable to the IDE and static tooling. Ruby, being a dynamically typed language, does not statically encode any structure regarding types, callgraphs/callsites/usages, definitions, or otherwise, in the syntax of the language alone. The behavior of a Ruby program - how its methods are defined, where they are defined, and which runtime objects invoke send what messages to whatever recipients, are only discoverable at runtime, because nobody bothered to put this information in at compile/typecheck time. You cannot discern information that simply is not there.
> For example, if I statically define a Ruby object via RBS, I may still do the things you list that are problematic.
Yes, and this is because RBS is not actually a sound typesystem [2] [3]. You can declare whatever fake types and interfaces you want in RBS; there is absolutely nothing stopping me from simply using `#define_method` to overwrite your implementation, destroying your static guarantees, or using other runtime metaprogramming facilities to delete your method, change its signature, or otherwise violate whatever other invariants you assumed you had when you wrote the static headers/type declarations and had them checked by the static verifier.
It doesn't matter if you statically verify the code, when the language offers innumerable opportunities to destroy those static guarantees, after they were established, at runtime.
> Thirdly, you're complaining about runtime issues making things difficult for the IDE while doing a lookup. What language and IDE do you prefer that does this so much better?
I already provided an example of C# ReSharper upthread [4]. C# actually provides the static typing information that the tooling requires in order to navigate the AST with deductive certainty, not loose approximations or heuristics as in RubyMine.
Out of curiosity, did you study computer science formally at a post-secondary institution, or did you learn from a bootcamp?
Just paying it forward. As a visible minority in Canada, I am subjected to this kind of passive aggressive, plausibly deniable ad hominem on a regular basis - and often by the very same Canadian white progressives who claim to have been educated out of such bigotry and racism. When in Rome...
In a Turing complete dynamic language I believe that some properties of the runtime would be undecidable. The advantage of static typing is that many (most?) type systems are sufficiently constrained (i.e. not Turing complete) such that the typecheck procedure can be assured to terminate.
Of course, with sufficiently expressive type systems you end up with Haskell "UndecidableInstances" or Coq dependent types or C++ compile-time tetris, [0] and now you are back to the same problem as with analyzing the runtime. Otherwise you may find it difficult to encode the desired properties or invariants into your type system, for lack of expressive power... tradeoffs abound, and so on.
In a dynamic language where code that produces such a side effect is admitted by the (lack of) compiler/typechecker, sure; however a static checker would probably ensure, before runtime, that said binding indeed refers to a str, now and forever.
But I realize now the point of ancestor's comment is that you don't have such a guarantee in a dynamic language - hence the tendency to lean more on REPL-oriented development, highly interactive live runtime environments, tight TDD feedback loops, etc...
Dunno, if you're using Rails, because of the naming conventions its pretty easy to find what you're looking for by just jumping to a file using grep or something.
Ruby-lsp runs everywhere nowadays, but back in the day, there was all sorts of code completion servers, live coding environments, etc... for Emacs, Vim had completion servers, and if you didn't have any of those, the REPL has always been good too.
It's been a really long time since I last used RubyMine as well, but one of my complaints back then was that it didn't help much when trying to debug code that made heavy use of metaprogramming. Maybe capabilities have improved since then. Despite that limitation, RubyMine still provided a far better debugging experience than what could be achieved through the default ruby debugging tools.
Most of us code in hopes that the thing we make is cool and useful, and it's a good thing if the thing we make catches on and becomes popular. Some might even say if they could make a living off their creation, they'd love that.
Given that this site is what it is, -most- of us have financial ambitions, with code as the means to an end to get us that money.
Back to the free for non commercial use stipulation, I'm just wondering how practical is this model? Is it expected that people do periodic reviews of the success of their projects and make some sort of subjective judgement when they should pay for a license?
Is there room for some other business model to more viably compete with vscode and vscode-forks that are free, while still creating paychecks for JetBrains?
I treat the spirit of these licenses as: "if you have reasonable expectation of making money from your use of it, please buy a license. Otherwise, we appreciate the mindshare."
Practically speaking, the license is probably much closer to "if you are making prodigious amounts of money, and you are using our software, then you had better buy a license to avoid a legal situation."
And if I were making prodigious amounts of money I'd be happy to go back and pay JetBrains the $274.8 a year that RubyMine costs per person for a company license. Aside being the decent thing to do, I'd like to contribute to JetBrains so they continue updating a tool that helped me build my company.
This is awesome. Over the past four years I went from Sublime Text, to VS Code, to a 'dual IDE' setup (neovim and cursor).
I hear rubymine has the best support for documentation and source code lookup capabilities (vitally important).
Curious of its AI capabilities; how much of a step down would it be going from cursor to rubymine? I guess it could be used stand-alone purely for its documentation/source capabilities, but 3 IDEs feels like overkill.
It’s a bit of a step down from cursor and vscode in terms of AI integration, but I still prefer my jetbrains ides (goland and rubymine). GitHub broke most aspects of their extension for jetbrains last week and didn’t seem to notice. That wouldn’t have happened for vscode (they might break it but they’ll also be in a hurry to fix it). I haven’t tried jetbrains own AI though. It might be fantastic for all I know.
It's different, I wouldn't necessarily say it's worse than Copilot, and I have been happy making the switch given my usage is included with the Jetbrains All Products subscription I already pay.
If you're expecting inline completion that reads your comments and shits out a fully formed function like Copilot, you'll be pretty annoyed - but that's been a positive for me as the completion doesn't constantly try to get in my way and suggest things 10 steps ahead of me. I'm much happier with my assistant letting my continue to steer when I'm actively coding, and instead just focusing on reducing keystrokes.
Chat works great, and I have a whole host of models from multiple providers to pick from. If I actually do want to have it generate some garbage for me, do code review, or simple refactors then I'll whip it out and it does the trick. Being better integrated into the IntelliJ Platform, actually applying changes from the chat window works more often than Copilot did in my experience.
And then there's Junie, which also benefits greatly from integration into the IDE. Since the PSI syntax tree you get from native IntelliJ language plugins gives the IDE a lot of data on whether code is actually valid or not (missing references, hallucinated packages or standard library functions, straight up invalid syntax, etc), you're not relying solely on tests to make sure the end result of a task you set the agent off to do is actually correct. I can come back after asking her to do a large-scale refactor, or implement some (part of a) feature, and generally be confident I'm not wandering into a bunch of garbage.
If you already pay for an All Products Pack license you've got JetBrains AI Pro included, if you pay for a single IDE from them and are already at the 3-year continuity discount then the cost of upgrading to the All Products Pack and getting the AI Pro license is a couple USD difference (depending on the specific product, could be cheaper). Really not much for anybody to lose trying it out, at the least.
> Junie, which also benefits greatly from integration into the IDE.
That is very plausible, I really want it to be true as a fan of IntelliJ and Kotlin. I used Cursor at work and tried out Junie on a hobby project. Maybe it's the different niche, maybe I'm more used to Cursor for chat bot workflows, but I got a personal Cursor license after trying out Junie.
It’s a very noticeable step down from cursor in terms of AI integration IMO, but also a huge step up in almost everything else.
For a while I was running both cursor and RubyMine in tandem and switching between as needed, but lately I’ve been using Claude code for most stuff, in a RubyMine terminal and I hardly miss cursor at all.
Depends what your most used part of Cursor is - from my view the only thing Rubymine is missing is the next edit prediction which I've heard they're working on currently
The agent, chat mode and full line completion all work well
I am going to try it. One nice thing about JetBrains IDEs is that they have all the functionality of the DataGrip database IDE built in.
This will be an issue for some users. Further down the page is a section on data collection:
Does my IDE send any data to JetBrains?
The terms of the non-commercial agreement assume that the product may also electronically send JetBrains anonymized statistics (IDE telemetry) related to your usage of the product’s features. This information may include but is not limited to frameworks, file templates used in the product, actions invoked, and other interactions with the product’s features. This information does not contain personal data.
I needed to pick up Ruby for a two year job, and RubyMine made my Ruby learning so much fun. I really appreciated the clever autocomplete and especially the suggestions. It would give recommendations like "this works, but it's not how people do things in Ruby. Try this instead" and the recommendation actually looked so slick and elegant (and Ruby-like, and not Java-like where I come from). I hope in my heart that sometime I'll have to use it again.
I'd like to see a comparison of IDE market share over the past decade or so. My assumption is that VS Code has gained market share exponentially, eating at both Visual Studio's and JetBrains' share significantly, leading JetBrains to start offering their products for free personal use to try to recoup some of that lost user base.
I could be wrong, but that's my observation based on the extreme popularity of VS Code and the abundance of extensions for virtually every language and framework out there.
On the IDE marketshare question, the Stackoverflow Developer Survey asks questions like this and I always jump to that section. Here's my comment on HN summarizing the most recent survey https://news.ycombinator.com/item?id=44725015
I also think your observation about VS Code's rise forcing JetBrains into a corner is spot on.
On a side tangent, I find it odd that the whole VS Code phenomena is under analyzed. Before VS Code, text editors and IDEs were one of the healthiest software categories around, with the market leader hovering around 35%, which is great for competition enforcing quality (DAWs are still like this today). Now text editors have become more like the Adobe suite, where there's in 800 lb gorilla doing whatever it wants and everyone else is competing over scraps (if you say VS Code is actually good though, Photoshop was amazing when it made its rise too). Developers just let this happen to their core tool without anyone really talking about?
I honestly don't understand the popularity of VS Code, at all. If I wanted to cobble together a development environment from scratch, I'd just go use Emacs. Hell, I'd end up with a better product than a bunch of buggy as VS Code plugins that don't constantly act up and regularly break.
While I wouldn't consider my employer a '.Net shop' anymore, it's a fact that it still remains the most used language across the organization. Many of my coworkers have ditched Visual Studio, jumped to VS Code, gotten pissed off at it after a while, tried Rider, and eventually switched.
If anything, I think VS Code is in an incredibly unhealthy state. Sure, Microsoft initially managed to pull a Chrome with it and ate the lunch of a lot of more basic text editors, but many people are getting frustrated with the ecosystem. Really, between Spacemacs and Neovim, actual community-driven projects are coming out with much more polished and better integrated tools than Microsoft - partly thanks to them pushing everyone and their dog to build language servers. I'm sticking to proper IDE's for basically everything but the occasional itch I have to do something in lisp, but hot damn does what you get out of the box thanks to LSP support and tree-sitter make VS Code less appealing to people willing to make the switch.
I’ve been paying for JetBrains for the past 10 years, and I want to keep supporting them. For a long time, I used Vim (about 5 years straight). Then one day, JetBrains introduced IdeaVim (Vim emulation). After that, I tried Neovim, but LazyVim didn’t really click with me. Maybe I’m just getting older and don’t feel like spending so much time fine-tuning my setup anymore.
> Whether you’re learning Ruby and Rails, pushing open-source forward, creating dev content, or building your passion project, we want to make sure you have the tools to enjoy what you do even more… for free.
I don't know why they say this fatuous stuff. Obviously they don't want to do that, or they'd make all their tools available for nothing.
My favorite thing about RubyMine is its ability to search so quickly for the text I'm looking for. I even used it for non-ruby projects just because I love the search functionality and that's what I'm used to. Definitely love that they did this.
Good news, I just wish Ruby had better DX on Vscode across all platforms. The ecosystem now is broken. Things barely work. All I want is syntax highlight, autocomplete and jump to definition without any ai stuff.
I guess RubyMine is the only proper way to use Ruby.
Agreed, I'm not sure how the github/shopify folks are doing their own work these days. I have to keep one archived extension + 2 others to try and cover the basic feature set you expect. I realize Ruby typing means some things aren't possible, but the fragmented toolset means the simple things keep breaking. I think some sort of 'champion' or company push will be needed to tidy things up at this point. Ironically, Shopify owns one of the Ruby extensions but it is feature incomplete.
That's not true: IntelliJ was the first one to come out licensed as Apache 2, and PyCharm (and the python plugin) followed suit. Both of them do have paid versions with more features, but IntelliJ and PyCharm open source builds are still very strong products and unquestionably not "phoning it in" releases
PyCharm lives in the IntelliJ CE repository, both are Apache 2.0 licensed, while the rest of JetBrain's language plugins are proprietary. They are 'unifying' PyCharm and getting rid of the separate PE and CE builds, but the underlying plugins remain developed in the open right there on GitHub.
As far as why only IntelliJ and PyCharm are done this way (excepting additional plugins many developers would end up wanting only coming with a subscription), that's a strategy question you'd have to ask an exec about. If I would hazard a guess, Java, Kotlin, and Python are all pretty big first languages to pick up and have large, active communities. Good products to get people hooked and want to pay to get the extras that aren't available without a subscription.
I am not sure how this contributes to the unfounded idea that ruby is dead—Shopify, Stripe, and GitHub amongst many others would like a word.
RubyMine isn’t the editor of choice for many of my fellow rubyists, but it is for me—IntelliJ’s LSP alone is a godsend when you’re diving deep into debugging weird gems. I have tried ruby-lsp from Shopify and it gets 95% there but that last 5% is what makes me hyper-productive.
Most of the community is on VS Code. We did have a weird, loud Danish guy using TextMate until recently, but I guess he switched to neovim.
Having said, RubyMine was very popular when ruby was on HN as much as AI is today. It hasn’t kept up, just like Sublime has been largely replaced by VS Code.
Yeah I mean Facebook, Wordpress, Wikipedia... but are you going to start a new project in PHP today? I bet all of them wish they weren't using Ruby. (Well probably not because they'll attract devs that love Ruby, but you get the point...)
Anyway in terms of concrete numbers the best thing I've found is to look at Github PRs/projects/stars. This site is really cool: https://madnight.github.io/githut/
Ruby was quite popular at the start of the chart in 2014 when it was more popular than Java! But gradually waned until about 2020 where it seems to have stabilised at "not very popular", just behind PHP.
Go and Typescript seem to have taken its place, which makes sense because they're both much better languages.
I've never heard any entrepreneur say they wish they didn't use Ruby... Nothing I've ever seen gets you from zero to a fully working CRUD website nearly as quickly.
The only people who say such things are the ones who didn't pick it.
I'd take that bet. At scale, (and those 3 are the definition of scale) you can mitigate some of the downsides of Ruby (i.e. speed), but you can't recreate the upsides (i.e. developer satisfaction, learning curve, flexibility) elsewhere.
> Go and Typescript seem to have taken its place, which makes sense because they're both much better languages.
Again: depends on the metrics you're considering. I would certainly consider Go much better than ruby on some metrics, but most definitely not all - and importantly, if I put all of it on a scale (and this is where bias comes in), I still give the edge to Ruby over both of those.
Heh, not the person you were replying to, but I do not find the list of upsides compelling. These products at scale are mature (minus everyone’s list of personal bugs and misfeatures). Who cares how easy it is to pick up the language or developer happiness? A stricter language with more hard guarantees makes it possible to make changes to a big code base without fear.
Sure but at scale the downsides of Ruby become even more significant - performance is more of an issue at scale, as is the lack of static typing.
I don't think Typescript or Go have a worse developer experience or learning curve than Ruby. You can learn Go in a week. They both have better tooling and higher developer satisfaction (admired/desired) scores than Ruby according to Stackoverflow's survey.
I'm weird. I'm still using the RoR Plugins for NetBeans. It still works pretty great (including haml and coffee autocomplete and code highlighting) for maintaining some legacy apps if you don't intend to reinstall it from scratch (which is a nightmare).
Probably more an indication that interest in RubyMine is dying, so they want to increase demand. I would look at development of VS Code extensions for any language to use as indications of demand. (in this case, the best one being ruby-lsp, which is still very active and alive)
It's been a long time since I last used RubyMine, but I always felt that it was the weakest of the JetBrains tools. And not because JetBrains didn't try hard enough, but because Ruby just doesn't offer a lot of opportunities for an IDE to take advantage of.
I ended up cancelling my subscription over some trivial thing (I think it was the fact that I couldn't quite get the IDE to preserve the indentation of a file. It was an all-or-nothing global setting, but I work on codebases that might have a 4-space indent HTML file and a 2-space indent HTML File in the same directory, and the IDE was ignoring the current style of the file and using whatever indent level I had configured).
It might be the weakest of the jetbrains IDEs[0], but for a long time it was simultaneously the best Ruby IDE for my needs. It had reliable jump to definition when nobody else did. That was key for me circa 2015 when I was coming from Java and struggling with my first dynamically typed language since Perl. There are probably better Ruby editors out there now. I stick with RubyMine because I use jetbrains for other languages and like the consistency.
[0] I won’t say the weakest of their tools because youtrack exists.
> [0] I won’t say the weakest of their tools because youtrack exists.
I realized something shocking while nodding along to your observation: they are a dev-tools company, and made their own issue tracker, but I still have to populate every single field, by hand, when reporting a bug against one of their products. But they have total control over the content emitted by RubyMine > About in order to package up the "what, exact, release and platform is the user on". Ironically, I could file that as a YouTrack against the YouTrack product if I enjoy spitting into the wind
Then you realize how this actually discourages interaction with bug reports and feature requests.
I've added "look how active and healthy the bug reporting and feature request systems are" to my checklist for tool evaluation.
Shockingly, there are still no better options out there for Ruby than Rubymine, nothing even comes close.
In general it's impossible to "find usages" or "go to definition" when the language not only fails to equip IDEs and tooling with the static typing information that would grant definitive answers to such questions; but even goes further and allows methods to be redefined or even synthesized and defined, for the first time, at runtime, with no corresponding source location or file. Method lookup and dispatch are fully Turing complete (you can `#send` anything, including fully dynamic method names, and respond to any message with arbitrary logic in `#method_missing`), and you can even redraw the method lookup chain and inheritance hierarchies at runtime (includes, mixins, module prepend, eigenclasses et al).
This is not a failing of JetBrains tooling but rather a pervasive language smell and consequence of Ruby philosophy.
It is infrequent that "find usages" and "go to definition" don't work for me on good sized ruby code bases. Both solargraph and ruby-lsp seem to work fine for me. Occasionally, I'm surprised when they don't work. In my recent mileage, that happens once every couple weeks, and I use find references and go to definition multiple time per-hour.
Metaprogramming has fallen out of fashion in the ruby community for the most part. Rails is a great example of where that shift has happened. ActiveRecord used to have `find_by_<attr-name>(<value>)`, which became `find_by(<attr-name>, <value>)`. Sure devs can still go wild with metaprogramming in ruby, but it is generally discouraged.
They work well enough to a first approximation, but it's far from the certainty one has using other JetBrains products (e.g. C# ReSharper) on a statically typed codebase.
RubyMine will give you "Untyped (potential) usage." That's not good enough if I need to make a breaking API change and be sure that I've fixed all the callsites, such that I don't find out that I've missed a spot when the change breaks in production.
For all this talk about LLMs and AI improving developer productivity - what is one click and a few seconds in ReSharper to "Change Signature" or "Pull Members Up," which is a 100% guaranteed safe refactoring that will not introduce regressions, ends up being anywhere from "a few hours" of playing whack-a-mole with usage sites, to "completely intractable" in 15+ year old 1MLOC+ codebases making heavy use of metaprogramming.
If the Ruby milieu has turned against metaprogramming, I say good riddance; but my understanding is that it is still quite deep in technologies like Rails and RSpec in particular, where it's the fundamental secret sauce that enables convention-over-configuration and fluent, natural-language like DSLs.
Of course it takes some heuristic to jump to the definition of these common Rails idioms
or a Ruby send(:method, arg)But an IDE specialized in Ruby can do it. No idea if RubyMine does it.
Bonus for handling
In general it can only present a menu of choices: all the methods with a name starting with "method_""Find usages" and "Go to definition" work very well in RubyMine in my experience, at least in normal Rails projects - I use them all the time with command-click.
Anecdata that something is effective in 98% of cases is different from provable static verification that works 100% of the time.
> In general it's impossible to "find usages" or "go to definition"
> Anecdata that something is effective in 98% of cases is different from provable static verification that works 100% of the time.
Ruby has its faults. But you're not making sense complaining first about the "in general" situation, then complaining about a 2% situation. And it is a 2% situation, I'll add my anecdata as verifying 98% (or better) it works really well.
Secondly, you're mixing concepts of static typing and metaprogramming by saying "the language not only fails to equip IDEs and tooling with the static typing information that would grant definitive answers to such questions." Static typing is not the solution, or at least not the only solution, to metaprogramming concepts. For example, if I statically define a Ruby object via RBS, I may still do the things you list that are problematic.
Thirdly, you're complaining about runtime issues making things difficult for the IDE while doing a lookup. What language and IDE do you prefer that does this so much better?
Lastly, I doubt this will help but just to make you aware there are specific rules about how this stuff works, for example https://ruby-doc.org/3.4.1/syntax/calling_methods_rdoc.html#...
> But you're not making sense complaining first about the "in general" situation, then complaining about a 2% situation.
The use of "in general" has long established usage in mathematics to refer to properties that hold for all objects in a given collection [0] [1]. Thus, if 2% of those objects fail to satisfy these properties, you cannot say that such properties hold "in general."
> Secondly, you're mixing concepts of static typing and metaprogramming by saying "the language not only fails to equip IDEs and tooling with the static typing information that would grant definitive answers to such questions." Static typing is not the solution, or at least not the only solution, to metaprogramming concepts.
Propose alternate solutions then.
IDEs and tooling (let's leave LLMs and other stochastic methods aside for now) can only inspect the lexical, syntactic, and semantic (types) structure of source code in order to navigate and validate it. Thus, information that is absent from the lexical, syntactic, and semantic structure of the source code, is unavailable to the IDE and static tooling. Ruby, being a dynamically typed language, does not statically encode any structure regarding types, callgraphs/callsites/usages, definitions, or otherwise, in the syntax of the language alone. The behavior of a Ruby program - how its methods are defined, where they are defined, and which runtime objects invoke send what messages to whatever recipients, are only discoverable at runtime, because nobody bothered to put this information in at compile/typecheck time. You cannot discern information that simply is not there.
> For example, if I statically define a Ruby object via RBS, I may still do the things you list that are problematic.
Yes, and this is because RBS is not actually a sound typesystem [2] [3]. You can declare whatever fake types and interfaces you want in RBS; there is absolutely nothing stopping me from simply using `#define_method` to overwrite your implementation, destroying your static guarantees, or using other runtime metaprogramming facilities to delete your method, change its signature, or otherwise violate whatever other invariants you assumed you had when you wrote the static headers/type declarations and had them checked by the static verifier.
It doesn't matter if you statically verify the code, when the language offers innumerable opportunities to destroy those static guarantees, after they were established, at runtime.
> Thirdly, you're complaining about runtime issues making things difficult for the IDE while doing a lookup. What language and IDE do you prefer that does this so much better?
I already provided an example of C# ReSharper upthread [4]. C# actually provides the static typing information that the tooling requires in order to navigate the AST with deductive certainty, not loose approximations or heuristics as in RubyMine.
Out of curiosity, did you study computer science formally at a post-secondary institution, or did you learn from a bootcamp?
[0] https://en.wikipedia.org/wiki/Glossary_of_mathematical_jargo...
[1] https://en.wikipedia.org/wiki/Glossary_of_mathematical_jargo...
[2] https://en.wikipedia.org/wiki/Type_safety
[3] https://www.typescriptlang.org/play/typescript/language/soun...
[4] https://news.ycombinator.com/item?id=45105283
I didn't read your comment -- I'm sure it was insightful and well researched.
The fact that it ended with an elitist ad hominem attack tells me enough.
Just paying it forward. As a visible minority in Canada, I am subjected to this kind of passive aggressive, plausibly deniable ad hominem on a regular basis - and often by the very same Canadian white progressives who claim to have been educated out of such bigotry and racism. When in Rome...
SLIME is a better approach for dynamic languages, IMO. Interrogating the actual runtime is more effective than trying to do static analysis.
In a Turing complete dynamic language I believe that some properties of the runtime would be undecidable. The advantage of static typing is that many (most?) type systems are sufficiently constrained (i.e. not Turing complete) such that the typecheck procedure can be assured to terminate.
Of course, with sufficiently expressive type systems you end up with Haskell "UndecidableInstances" or Coq dependent types or C++ compile-time tetris, [0] and now you are back to the same problem as with analyzing the runtime. Otherwise you may find it difficult to encode the desired properties or invariants into your type system, for lack of expressive power... tradeoffs abound, and so on.
[0] https://news.ycombinator.com/item?id=9813800
Or my favorite alternative to that story: well, it's currently a str ... maybe it'll still be a str in 5 minutes, who knows
In a dynamic language where code that produces such a side effect is admitted by the (lack of) compiler/typechecker, sure; however a static checker would probably ensure, before runtime, that said binding indeed refers to a str, now and forever.
But I realize now the point of ancestor's comment is that you don't have such a guarantee in a dynamic language - hence the tendency to lean more on REPL-oriented development, highly interactive live runtime environments, tight TDD feedback loops, etc...
Yeah, Ruby wasn’t unpleasant to write in the wonderfully simple TextMate back in the day… a full fat IDE feels like extreme overkill.
I might even say that’s a point of attraction for the language. Overwrought IDEs and heavy editors are more optional relative to some languages.
I have worked at several ruby shops and everyone has used heavy IDEs like RubyMine and VSCode, jump to's and language server are far too important.
Dunno, if you're using Rails, because of the naming conventions its pretty easy to find what you're looking for by just jumping to a file using grep or something.
Ruby-lsp runs everywhere nowadays, but back in the day, there was all sorts of code completion servers, live coding environments, etc... for Emacs, Vim had completion servers, and if you didn't have any of those, the REPL has always been good too.
It's been a really long time since I last used RubyMine as well, but one of my complaints back then was that it didn't help much when trying to debug code that made heavy use of metaprogramming. Maybe capabilities have improved since then. Despite that limitation, RubyMine still provided a far better debugging experience than what could be achieved through the default ruby debugging tools.
>Free for non commercial use
I like to recreationally overthink sometimes:
Most of us code in hopes that the thing we make is cool and useful, and it's a good thing if the thing we make catches on and becomes popular. Some might even say if they could make a living off their creation, they'd love that.
Given that this site is what it is, -most- of us have financial ambitions, with code as the means to an end to get us that money.
Back to the free for non commercial use stipulation, I'm just wondering how practical is this model? Is it expected that people do periodic reviews of the success of their projects and make some sort of subjective judgement when they should pay for a license?
Is there room for some other business model to more viably compete with vscode and vscode-forks that are free, while still creating paychecks for JetBrains?
I treat the spirit of these licenses as: "if you have reasonable expectation of making money from your use of it, please buy a license. Otherwise, we appreciate the mindshare."
Practically speaking, the license is probably much closer to "if you are making prodigious amounts of money, and you are using our software, then you had better buy a license to avoid a legal situation."
And if I were making prodigious amounts of money I'd be happy to go back and pay JetBrains the $274.8 a year that RubyMine costs per person for a company license. Aside being the decent thing to do, I'd like to contribute to JetBrains so they continue updating a tool that helped me build my company.
So any VC funded startup should use for free in your opinion?
I'm a huge fan of RubyMine (and all of JetBrains tooling).
I've always found their find by reference and jump to definition better than using a language server.
> It’s important to note that, if you’re using a non-commercial license, you cannot opt out of the collection of anonymous usage statistics.
Important indeed. This is not "free as in freedom"
It never would be. It's free as in beer.
Also, mark my words: Most/All Jetbrains IDEs are going to go this way. They're just pacing it to keep good press rolling.
This is awesome. Over the past four years I went from Sublime Text, to VS Code, to a 'dual IDE' setup (neovim and cursor).
I hear rubymine has the best support for documentation and source code lookup capabilities (vitally important).
Curious of its AI capabilities; how much of a step down would it be going from cursor to rubymine? I guess it could be used stand-alone purely for its documentation/source capabilities, but 3 IDEs feels like overkill.
It’s a bit of a step down from cursor and vscode in terms of AI integration, but I still prefer my jetbrains ides (goland and rubymine). GitHub broke most aspects of their extension for jetbrains last week and didn’t seem to notice. That wouldn’t have happened for vscode (they might break it but they’ll also be in a hurry to fix it). I haven’t tried jetbrains own AI though. It might be fantastic for all I know.
It's different, I wouldn't necessarily say it's worse than Copilot, and I have been happy making the switch given my usage is included with the Jetbrains All Products subscription I already pay.
If you're expecting inline completion that reads your comments and shits out a fully formed function like Copilot, you'll be pretty annoyed - but that's been a positive for me as the completion doesn't constantly try to get in my way and suggest things 10 steps ahead of me. I'm much happier with my assistant letting my continue to steer when I'm actively coding, and instead just focusing on reducing keystrokes.
Chat works great, and I have a whole host of models from multiple providers to pick from. If I actually do want to have it generate some garbage for me, do code review, or simple refactors then I'll whip it out and it does the trick. Being better integrated into the IntelliJ Platform, actually applying changes from the chat window works more often than Copilot did in my experience.
And then there's Junie, which also benefits greatly from integration into the IDE. Since the PSI syntax tree you get from native IntelliJ language plugins gives the IDE a lot of data on whether code is actually valid or not (missing references, hallucinated packages or standard library functions, straight up invalid syntax, etc), you're not relying solely on tests to make sure the end result of a task you set the agent off to do is actually correct. I can come back after asking her to do a large-scale refactor, or implement some (part of a) feature, and generally be confident I'm not wandering into a bunch of garbage.
If you already pay for an All Products Pack license you've got JetBrains AI Pro included, if you pay for a single IDE from them and are already at the 3-year continuity discount then the cost of upgrading to the All Products Pack and getting the AI Pro license is a couple USD difference (depending on the specific product, could be cheaper). Really not much for anybody to lose trying it out, at the least.
> Junie, which also benefits greatly from integration into the IDE.
That is very plausible, I really want it to be true as a fan of IntelliJ and Kotlin. I used Cursor at work and tried out Junie on a hobby project. Maybe it's the different niche, maybe I'm more used to Cursor for chat bot workflows, but I got a personal Cursor license after trying out Junie.
That sounds nice. You’ve talked me into trying it out.
It’s a very noticeable step down from cursor in terms of AI integration IMO, but also a huge step up in almost everything else.
For a while I was running both cursor and RubyMine in tandem and switching between as needed, but lately I’ve been using Claude code for most stuff, in a RubyMine terminal and I hardly miss cursor at all.
Depends what your most used part of Cursor is - from my view the only thing Rubymine is missing is the next edit prediction which I've heard they're working on currently
The agent, chat mode and full line completion all work well
I am going to try it. One nice thing about JetBrains IDEs is that they have all the functionality of the DataGrip database IDE built in.
This will be an issue for some users. Further down the page is a section on data collection:
Does my IDE send any data to JetBrains?
The terms of the non-commercial agreement assume that the product may also electronically send JetBrains anonymized statistics (IDE telemetry) related to your usage of the product’s features. This information may include but is not limited to frameworks, file templates used in the product, actions invoked, and other interactions with the product’s features. This information does not contain personal data.
I needed to pick up Ruby for a two year job, and RubyMine made my Ruby learning so much fun. I really appreciated the clever autocomplete and especially the suggestions. It would give recommendations like "this works, but it's not how people do things in Ruby. Try this instead" and the recommendation actually looked so slick and elegant (and Ruby-like, and not Java-like where I come from). I hope in my heart that sometime I'll have to use it again.
I'd like to see a comparison of IDE market share over the past decade or so. My assumption is that VS Code has gained market share exponentially, eating at both Visual Studio's and JetBrains' share significantly, leading JetBrains to start offering their products for free personal use to try to recoup some of that lost user base.
I could be wrong, but that's my observation based on the extreme popularity of VS Code and the abundance of extensions for virtually every language and framework out there.
On the IDE marketshare question, the Stackoverflow Developer Survey asks questions like this and I always jump to that section. Here's my comment on HN summarizing the most recent survey https://news.ycombinator.com/item?id=44725015
I also wrote about VS Code's early rising with a focus on marketshare here https://blog.robenkleene.com/2020/09/21/the-era-of-visual-st...
I also think your observation about VS Code's rise forcing JetBrains into a corner is spot on.
On a side tangent, I find it odd that the whole VS Code phenomena is under analyzed. Before VS Code, text editors and IDEs were one of the healthiest software categories around, with the market leader hovering around 35%, which is great for competition enforcing quality (DAWs are still like this today). Now text editors have become more like the Adobe suite, where there's in 800 lb gorilla doing whatever it wants and everyone else is competing over scraps (if you say VS Code is actually good though, Photoshop was amazing when it made its rise too). Developers just let this happen to their core tool without anyone really talking about?
I honestly don't understand the popularity of VS Code, at all. If I wanted to cobble together a development environment from scratch, I'd just go use Emacs. Hell, I'd end up with a better product than a bunch of buggy as VS Code plugins that don't constantly act up and regularly break.
While I wouldn't consider my employer a '.Net shop' anymore, it's a fact that it still remains the most used language across the organization. Many of my coworkers have ditched Visual Studio, jumped to VS Code, gotten pissed off at it after a while, tried Rider, and eventually switched.
If anything, I think VS Code is in an incredibly unhealthy state. Sure, Microsoft initially managed to pull a Chrome with it and ate the lunch of a lot of more basic text editors, but many people are getting frustrated with the ecosystem. Really, between Spacemacs and Neovim, actual community-driven projects are coming out with much more polished and better integrated tools than Microsoft - partly thanks to them pushing everyone and their dog to build language servers. I'm sticking to proper IDE's for basically everything but the occasional itch I have to do something in lisp, but hot damn does what you get out of the box thanks to LSP support and tree-sitter make VS Code less appealing to people willing to make the switch.
I’ve been paying for JetBrains for the past 10 years, and I want to keep supporting them. For a long time, I used Vim (about 5 years straight). Then one day, JetBrains introduced IdeaVim (Vim emulation). After that, I tried Neovim, but LazyVim didn’t really click with me. Maybe I’m just getting older and don’t feel like spending so much time fine-tuning my setup anymore.
> Whether you’re learning Ruby and Rails, pushing open-source forward, creating dev content, or building your passion project, we want to make sure you have the tools to enjoy what you do even more… for free.
I don't know why they say this fatuous stuff. Obviously they don't want to do that, or they'd make all their tools available for nothing.
My favorite thing about RubyMine is its ability to search so quickly for the text I'm looking for. I even used it for non-ruby projects just because I love the search functionality and that's what I'm used to. Definitely love that they did this.
Good news, I just wish Ruby had better DX on Vscode across all platforms. The ecosystem now is broken. Things barely work. All I want is syntax highlight, autocomplete and jump to definition without any ai stuff.
I guess RubyMine is the only proper way to use Ruby.
Agreed, I'm not sure how the github/shopify folks are doing their own work these days. I have to keep one archived extension + 2 others to try and cover the basic feature set you expect. I realize Ruby typing means some things aren't possible, but the fragmented toolset means the simple things keep breaking. I think some sort of 'champion' or company push will be needed to tidy things up at this point. Ironically, Shopify owns one of the Ruby extensions but it is feature incomplete.
There is a good talk about this issue if you are interested, https://www.youtube.com/watch?v=pOuy51ZCGEw
This is smart from a business point of view imo. You want as many people on the platform as possible and you don’t forgo enterprize customers.
I don't understand. Of all offerings from Jetbrains, only Pycharm is free for commercial use. Others have restrictions like RubyMine.
That's not true: IntelliJ was the first one to come out licensed as Apache 2, and PyCharm (and the python plugin) followed suit. Both of them do have paid versions with more features, but IntelliJ and PyCharm open source builds are still very strong products and unquestionably not "phoning it in" releases
IntelliJ IDEA Community version is also free for commercial use, it's Apache 2.0 licensed even (mostly).
I would be interested to know the story there. It seems like a strange choice to be the only one free for commercial use.
PyCharm lives in the IntelliJ CE repository, both are Apache 2.0 licensed, while the rest of JetBrain's language plugins are proprietary. They are 'unifying' PyCharm and getting rid of the separate PE and CE builds, but the underlying plugins remain developed in the open right there on GitHub.
As far as why only IntelliJ and PyCharm are done this way (excepting additional plugins many developers would end up wanting only coming with a subscription), that's a strategy question you'd have to ask an exec about. If I would hazard a guess, Java, Kotlin, and Python are all pretty big first languages to pick up and have large, active communities. Good products to get people hooked and want to pay to get the extras that aren't available without a subscription.
Perhaps it has a dependency with a license that forbids those kind of restrictions?
Jetbrains really needs to step up their LLM game. Trying to stay in house is a mistake. I'm glad Claude code integrates well.
great stuff. RubyMine has a great implementation of RBS.
Just another indication that ruby is dead?
I am not sure how this contributes to the unfounded idea that ruby is dead—Shopify, Stripe, and GitHub amongst many others would like a word.
RubyMine isn’t the editor of choice for many of my fellow rubyists, but it is for me—IntelliJ’s LSP alone is a godsend when you’re diving deep into debugging weird gems. I have tried ruby-lsp from Shopify and it gets 95% there but that last 5% is what makes me hyper-productive.
Most of the community is on VS Code. We did have a weird, loud Danish guy using TextMate until recently, but I guess he switched to neovim.
Having said, RubyMine was very popular when ruby was on HN as much as AI is today. It hasn’t kept up, just like Sublime has been largely replaced by VS Code.
> Shopify, Stripe, and GitHub
Yeah I mean Facebook, Wordpress, Wikipedia... but are you going to start a new project in PHP today? I bet all of them wish they weren't using Ruby. (Well probably not because they'll attract devs that love Ruby, but you get the point...)
Anyway in terms of concrete numbers the best thing I've found is to look at Github PRs/projects/stars. This site is really cool: https://madnight.github.io/githut/
Ruby was quite popular at the start of the chart in 2014 when it was more popular than Java! But gradually waned until about 2020 where it seems to have stabilised at "not very popular", just behind PHP.
Go and Typescript seem to have taken its place, which makes sense because they're both much better languages.
> I bet all of them wish they weren't using Ruby.
I've never heard any entrepreneur say they wish they didn't use Ruby... Nothing I've ever seen gets you from zero to a fully working CRUD website nearly as quickly.
The only people who say such things are the ones who didn't pick it.
> I bet all of them wish they weren't using Ruby.
I'd take that bet. At scale, (and those 3 are the definition of scale) you can mitigate some of the downsides of Ruby (i.e. speed), but you can't recreate the upsides (i.e. developer satisfaction, learning curve, flexibility) elsewhere.
> Go and Typescript seem to have taken its place, which makes sense because they're both much better languages.
Again: depends on the metrics you're considering. I would certainly consider Go much better than ruby on some metrics, but most definitely not all - and importantly, if I put all of it on a scale (and this is where bias comes in), I still give the edge to Ruby over both of those.
Heh, not the person you were replying to, but I do not find the list of upsides compelling. These products at scale are mature (minus everyone’s list of personal bugs and misfeatures). Who cares how easy it is to pick up the language or developer happiness? A stricter language with more hard guarantees makes it possible to make changes to a big code base without fear.
Fair! And yep, I too wish Ruby was stricter. I just happen to value it slightly less than some of the things I do get with the language.
> Who cares how easy it is to pick up the language or developer happiness?
Someone who's building a startup. Time to market and not succumbing to the desire to quit is #1 when you're building from the ground up.
You DGAF about making changes to a large codebase when you have no codebase...
Sure but at scale the downsides of Ruby become even more significant - performance is more of an issue at scale, as is the lack of static typing.
I don't think Typescript or Go have a worse developer experience or learning curve than Ruby. You can learn Go in a week. They both have better tooling and higher developer satisfaction (admired/desired) scores than Ruby according to Stackoverflow's survey.
That’s not a good indicator at all. Open source requirements are very different from business application.
I'm weird. I'm still using the RoR Plugins for NetBeans. It still works pretty great (including haml and coffee autocomplete and code highlighting) for maintaining some legacy apps if you don't intend to reinstall it from scratch (which is a nightmare).
>Shopify, Stripe, and GitHub
Outliers do not dictate the mean.
RustRider and WebStorm are also free for non commercial use. I wouldn’t take that as an indication that Rust and the web are dead.
Also CLion
Rust Rover and Rider :)
Thank you. I have no excuse, it was even in my screen when I typed it.
:) Rust Rover or Rider ?
Probably more an indication that interest in RubyMine is dying, so they want to increase demand. I would look at development of VS Code extensions for any language to use as indications of demand. (in this case, the best one being ruby-lsp, which is still very active and alive)
More like since ruby-lsp has taken off, fewer Ruby users care about RubyMine.