RubyMine is now free for non-commercial use(blog.jetbrains.com) |
RubyMine is now free for non-commercial use(blog.jetbrains.com) |
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).
[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
This is not a failing of JetBrains tooling but rather a pervasive language smell and consequence of Ruby philosophy.
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.
belongs_to :customer # class Customer
after_save :do_something # method
validate :custom_validation # method
But an IDE specialized in Ruby can do it. No idea if RubyMine does it.
Bonus for handling
send("method_#{var}".to_sym, arg)
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 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?
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."
I've always found their find by reference and jump to definition better than using a language server.
Important indeed. This is not "free as in freedom"
Also, mark my words: Most/All Jetbrains IDEs are going to go this way. They're just pacing it to keep good press rolling.
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.
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 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.
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.
I guess RubyMine is the only proper way to use Ruby.
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.
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.
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.
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.
On the other hand - properly used Claude Code is very nice. Long story short: I am thinking about reducing AI usage to the CC only and attempt to use it as a chat assistant too. Plus maybe subscribing to minimal package from Jetbrains or Copilot for some nice commit generations and occasional chats with other models.
The agent, chat mode and full line completion all work well
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?
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.
Outliers do not dictate the mean.
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.
I've added "look how active and healthy the bug reporting and feature request systems are" to my checklist for tool evaluation.
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.
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.
> 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#...
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...
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.
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...
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.
The fact that it ended with an elitist ad hominem attack tells me enough.
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.
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...