Live data from Hacker News

RubyMine is now free for non-commercial use

blog.jetbrains.com

71–80 of 83 posts

Re: RubyMine is now free for non-commercial use

#71
post #5

Earlier quoted context omitted.

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

> 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.githu…

That’s not a good indicator at all. Open source requirements are very different from business application.

Re: RubyMine is now free for non-commercial use

#72

Earlier quoted context omitted.

> 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…

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.

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

Re: RubyMine is now free for non-commercial use

#73

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…

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 la…

Shockingly, there are still no better options out there for Ruby than Rubymine, nothing even comes close.

Re: RubyMine is now free for non-commercial use

#76
post #40

Earlier quoted context omitted.

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 i…

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

Re: RubyMine is now free for non-commercial use

#77
post #61
post #59

Earlier quoted context omitted.

> 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 wo…

> 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…

SLIME is a better approach for dynamic languages, IMO. Interrogating the actual runtime is more effective than trying to do static analysis.

Re: RubyMine is now free for non-commercial use

#78
post #61

Earlier quoted context omitted.

> 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…

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

Re: RubyMine is now free for non-commercial use

#79
post #78

Earlier quoted context omitted.

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++…

[deleted]

Re: RubyMine is now free for non-commercial use

#80
post #78

Earlier quoted context omitted.

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++…

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
Post reply on HN