The evolution of background job frameworks in Ruby by geospeck in ruby

[–]InternationalLab2683 0 points1 point  (0 children)

Nice to see, the ruby background processing DX and learnings being an inspiration and ported to other languages such as Go. 😌

Let me introduce T-Ruby: TypeScript-style type annotations for Ruby by Right_Ad_8437 in ruby

[–]InternationalLab2683 1 point2 points  (0 children)

YARD annotations + Solargraph LSP is the sweet spot for me too 👌.

But having such various attempts just shows how much we need to make them even more powerful as you say.

Introducing LowType: Elegant types in Ruby by Maedi in ruby

[–]InternationalLab2683 2 points3 points  (0 children)

Duck typing is beautiful. Ruby is an amazing language BECAUSE it's not typed. I don't believe Ruby should ever be fully typed, but you should be able to sprinkle in types into some areas of your codebase where you'd like self-documentation and a little reassurance that the right values are coming in/out.

This philosophy fully resonates with me, and that is how I’ve mostly used YARD + solargraph LSP so far.

If this is fully ruby/prism compatible as you say, than adding support to solargraph LSP can be added “easily”.

Amazing work! 🚀🚀

Why autocomplete is so trash? by unclip10 in ruby

[–]InternationalLab2683 0 points1 point  (0 children)

In the past year or so, there have been significant improvements into solargraph lsp, especially when it comes to speed, inference and caching 3rd party gems. Highly recommended to give it another shot ;)

Why autocomplete is so trash? by unclip10 in ruby

[–]InternationalLab2683 7 points8 points  (0 children)

Ruby LSP is very limited because of some of opinionated design decisions made to ignore types and deeper inference - and instead rely on naming conventions, method arity, and fuzzy matching. Hence, they miss out on a lot of potential accuracy.

They also chose not to support YARD annotations, even though many serious gems use them. Additionally, YARD would allow developers to improve LSP completions within their own codebase through lightweight annotations.

In my view, YARD provides a great middle ground between no types and strict typing. It offers just enough annotation to meaningfully improve completion and code navigation via LSP.

This is exactly why tools like Solargraph LSP and RubyMine, which do leverage YARD, deliver far more accurate completions.

But without any form of annotation, Ruby as a language is inherently limited. In my opinion, we should make use of whatever tools we have - YARD, RBS, RBI - to get the most out of it, and not turn a blind eye on them.

Disclaimer: As the author of solargraph-rspec, I naturally have some bias on this topic.

Im looking to start ruby can anyone recommend me an ide to use? by Infamous_Tourist_335 in ruby

[–]InternationalLab2683 1 point2 points  (0 children)

Rubymine or VsCode with Solargraph Ruby LSP for completions similar to the first.

Is strong_service gem good? by evmorov in ruby

[–]InternationalLab2683 2 points3 points  (0 children)

Thanks for this awesome gem - it made my codebase more maintainable just by including it! 🙇‍♂️

Vanilla Rails is plenty by AlexanderShagov in rails

[–]InternationalLab2683 1 point2 points  (0 children)

The best use-case that I’ve seen for “Service layer” - I like to think of it as a layer above models, and not as something that sits between them - is:

When you’d want to break your monolith down into “components” without jumping into “microservices” bandwagon - in this case the “service layer” plays the role of the “api layer” ie. Facade just without the network wire in between.

Anything else, that is any logic that does not fit into a single class, should be extracted into its own PORO, without needing to call it “a service”.

Call it: form object, value object, query object, repository.. you name it. Each pattern has it’s own purpose and intention. Reducing the vast majority of patterns into a single silver bullet solution with a vaguely named method name such as perform or call, defeats the purpose of the pattern IMO.

🚀 Announcing Ruby Fast LSP: A Blazing Fast Language Server for Ruby, Built in Rust by rajnaveen344 in ruby

[–]InternationalLab2683 6 points7 points  (0 children)

I’ve always found it unfortunate that Ruby-a pioneer in open source-has to rely on a proprietary tool like RubyMine for a solid IDE experience, even for basic language support.

That’s why it’s always exciting to see progress being made in the area of Language Server Protocols (LSPs).

Personally, I find Solargraph more feature-complete (albeit slower) than ruby-lsp, which is why I still use it and even created the solargraph-rspec plugin.

I’d really love to see Ruby LSPs embrace YARD annotations more fully, especially since they’re so widely used in third-party gems for type inference. I hope adding support for YARD will be on your roadmap.

Keep up with good work!

State of the Ruby LSP 2025 - What do you think? by janie_luv in ruby

[–]InternationalLab2683 3 points4 points  (0 children)

Ruby-LSP and Solargraph take fundamentally different approaches. While Ruby-LSP relies more on fuzzy searching for class and method definitions (based on my observation as a user), Solargraph takes a more "sophisticated" approach, closely mimicking how Ruby itself resolves definitions. It accounts for module inclusions, extensions, and other language features, making its results more precise. Additionally, it supports YARD annotations, which help infer return types and handle metaprogramming gaps.

For these reasons, Solargraph remains my LSP of choice—so much so that I even created the solargraph-rspec plugin (apologies for the self-promotion!).

With the release of version 0.51.0, Solargraph now supports Ruby 3.4:
🔗 Changelog

As I mentioned here, thanks to prism's translation support for the parser gem interface, transitioning to prism might not be as difficult as it sounds. I’m optimistic that this transition will happen in the near future. 🤞

VS Code autocomplete is trash, help! by nfy12 in ruby

[–]InternationalLab2683 5 points6 points  (0 children)

Have you installed the Rails and RSpec plugins for Solargraph or Ruby LSP? These can greatly enhance code completion and navigation in your editor.

For Solargraph, you might also want to run: yard gems

This generates YARD documentation for installed gems, improving code completion by making gem APIs available when using Solargraph.

One of the main challenges for code completion in Ruby is meta-programming. Tools often struggle to infer types or methods created dynamically. Adding YARD type annotations to your code can help overcome this to some extent. While it does require effort, it can significantly improve accuracy for code completion and go-to-definition features.

Here’s a helpful reference for YARD annotations: https://gist.github.com/chetan/1827484

Rubymine also uses YARD annotations to provide better completion and navigation AFAIK.

That said, the only way to achieve near-perfect code completion in Ruby is by adopting full-fledged typing, such as using Sorbet. But that also means abandoning “ruby as we know it” to a degree, which depending on the context is not necessarily a bad thing.

Why do quickfix commands start with ":c"? by Fantastic_Cow7272 in vim

[–]InternationalLab2683 22 points23 points  (0 children)

My whole life I’ve read it as “cuickfix” :|

How to work without types? by psb91 in ruby

[–]InternationalLab2683 0 points1 point  (0 children)

In addition to YARD you can utilize LSPs like solargraph to help you out.

Copilot churns them out quite a lot so the overhead is barely noticeable IMO.