solargraph VS falcon

My favorite typing solution so far in ruby is Solargraph https://solargraph.org/.

Solagraph: https://solargraph.org

Yay! For those who don’t know solargraph provides a language server protocol (LSP) for Ruby so that your IDE (like vscode) can know more about the code you’re writing https://solargraph.org/.

If you're looking for IDE-level language assistance, I can't help you, but since you mentioned nvim: I use regular vim with CoC / Conquer of Completion (vim plugin; LSP server, may not strictly be necessary for nvim), Solargraph (Ruby Gem; language server), and Rubocop (also a Gem) for linting. I previously/still use ALE (vim plugin; Asynchronous Lint Engine) because I haven't gotten CoC+Solargraph to play nice with Rubocop, probably due to something silly.

https://github.com/neoclide/coc.nvim

https://solargraph.org/

https://rubocop.org/

https://github.com/dense-analysis/ale

My impression with all of this running under MacVim... it's plenty responsive. It can take a while for Solargraph to index everything on startup if you're working in a big project; once it loads, it's snappy. (There's probably a way to cache that startup scan.)

I am trying to use lsp-mode for ruby via solargraph and for Rails era templates using web-mode via lsp-tailwindcss and both seems to kinda sorta work but neither one is really giving me all the features that I see that others have.

https://github.com/castwide/solargraph Seems to be the most mature/developed one. Slow on my system, bad documentation. Language docs are shipped as "cores" you imperatively download that float around in your home directory; this is messy and prone to failure. Doesn't have any docs for versions of ruby past 2.7.

I have recently installed Solargraph and can see that when I open a Ruby file that the LSP is attached to my buffer via `LspInfo`. However whenever I am trying to do some very basic completions or see what kind of methods are available for an object, literally nothing happens. What I am aiming for is something like on the official Solargraph website: https://solargraph.org/

If you use Vim or Neovim, you can display RuboCop's diagnostics through coc.nvim. You need to install the Solargraph language server (gem install solargraph), followed by the coc-solargraph extension (:CocInstall coc-solargraph). Afterwards, configure your coc-settings.json file as shown below:

The builtin LSP works well with solargraph to provide autocompletion.

Sorbet and/or RBS seems like they may be the future given how popular typescript is with JS programmers these days. There are some other projects that assist programmers without relying on formal type definitions in the source or shadow typing files:

Solargraph combines inference and insight from YARD docs (standard for many gems, plus Castwide has written more YARD for the standard library) to make some pretty good guesses. Crucially it has plugins that add the insights from popular gems with static analysis (e.g. reek, rubocop). I maintain solargraph-rails, which parses your Ruby to make guesses about (surprise) Rails.

The typeprof gem can help IDE plugins make typing guesses based on your tests. This project is interesting to me because it's going into Ruby 3.1 so I think it reflects awareness from the core ruby team that many programmers are not ready to add types to their code.

solargraph: https://github.com/castwide/solargraph

Could you command on any projects within Shopify that are helping Ruby's concurrency story? I'm aware of Ractors (https://docs.ruby-lang.org/en/master/ractor_md.html) and Fibers, but it's unclear to how feasible these primitives currently are to build the necessary abstractions on top of them that would make Rails more concurrent.

https://github.com/socketry/falcon is an interesting project, but again, it's not clear how difficult it would be deploying a Rails app on top of this.

There's a lot of really great projects happening and plenty to be hopeful about, but when that stuff will land or the changes the rest of the community and ecosystem should think about making still isn't clear.

HOWEVER HAD, not all of these problems (in Java) are due to some corporation going bulldozer-mode. Several problems seem to come primarily from bad technical decisions. The import-situation annoys me in Java. I think it is really bad that I can not easily require add-ons or files, without being forced into a specific, nonsensical directory structure. In ruby I just do require, or load (I could do require_relative but this is a pretty pointless addition; It even leads to bugs such as the author of https://github.com/socketry/falcon assuming that everyone uses a hardcoded filesystem, so code such as https://github.com/socketry/falcon/blob/main/bin/falcon at: require_relative '../lib/falcon/command' not working unless the assumption that the directory BELOW the bin/ one must contain a lib/ which is not always the case. I am not sure he understood the problem domain though. If he would have simply used require instead, that would not be an issue, but no, he thinks one has to use hardcoded path assumptions into require_relative, which means it'll break when you relocatethe bin/ executable file there. It's trivial to fix of course, just replace the require_relative with require, but I think he did not understand the explanation so ...)

This doesn't have much to do with Rails, more with the web server that serves the Rails app. Take a look at Falcon.

You can use the Async gem and the Falcon web server to take advantage of this capability. And starting in Ruby 3.0, async I/O is even more automatic because inside the Ruby runtime, all socket operations will automatically yield the current fiber by default. It’s fully transparent to the developer. Your I/O calls appear to be blocking so they are easy to understand, consistent with Ruby’s “programmer happiness” philosophy.

There seem to a lot of ruby pieces falling into place for Rails 7.

The Achilles Heel of Hotwire apps has previously been the low number of supported websocket connections and high memory usage when using ActionCable and Puma but I have high hopes that Falcon[1] will take care of that.

That along with Github's View Components[2] and Tailwind make me really please with the way Rails is heading right now.

1. https://github.com/socketry/falcon

2. https://github.com/github/view_component

This is all new to me as well, but the project mentioned the Falcon web server(https://github.com/socketry/falcon).

The documentation for Falcon mentions using it with rails: https://socketry.github.io/falcon/guides/rails-integration/i...

I imagine something more "native" to rails will happen eventually though. But would need to be after this makes its way into core ruby(which has not happened yet apparently).

Welcome back.

It's still the best choice in the Ruby world, well maintained, responsive and new features added. Shopify and github use it, you might want to look at the Rails 6 annoucements what these companies added for scalability features. There've been changes to the asset pipeline since version 3 but you'll still recognize it. You can run Rails as API-only and there's subprojects/tutorials for combining a frontend-heavy React,Vue with a Rails backend. You can still ignore the webpack based asset setup unless you use React,Vue I think. Ruby-3 works fine though I'm still waiting for some less-maintained gems to finally merge PRs, maybe you want to use Ruby-2.7 first.

I use https://puma.io/ , that scales well enough for me. https://github.com/socketry/falcon#readme is faster with build-in HTTP/2 support but harder to setup in my opinion, e.g. requires SSL certificate even on localhost.