A decent VS Code and Ruby on Rails setup

https://railsnotes.xyz/blog/vscode-rails-setup

by amalinovic • 2 years ago

71 53 2 years ago

gvkhna• 2 years ago

Here for standardrb, it’s the only one i use. I would recommend it and don’t deal with rubocop or anything else anymore.

I understand OPs points about ERB it seems to be a wasteland of development. I switched to liquid templates which took a decent bit of effort to implement, but well worth it for shopifys amazing liquid extension/support, which is quite configurable too for custom handlers.

firecall3• 2 years ago

I use HAML these days.

Recent releases are technically faster than ERB, and I really appreciate the compact structure of the markup!

xipho• 2 years ago

But can OP please share their settings.yml? Vim plus plugins I've been using for over a decade are still faster for me than what I've been able to get setup in VS Code, it has been frustrating. Some of the promising plugins have failed to update hot-key setups, etc.

rattray3• 2 years ago

No mention of Sorbet. Is anyone (outside of Stripe, Shopify, etc) using it?

danielheath• 2 years ago

We gave it a good shot at work. It really struggled with common dynamic idioms in rails, like “find” being able to return either an array or a single value.

The combination of verbose type definitions and limited support for the kind of types rails often uses made it a poor ROI for us, but it did find some bugs.

mportela• 2 years ago

I use it at Justworks and love it! Packwerk [1] is another personal favorite

[1] https://github.com/Shopify/packwerk

kamikaz1k• 2 years ago

Used at Instacart; its a very polarizing topic.

Personally don't like it, but I also don't like mypy. I do like TypeScript though, mostly.

chihuahua5• 2 years ago

We're using it (300 engineers, 50k .rb files). It sucks, like everything else related to Ruby. It's ugly and hard to read. It would be better to use a real language that has types built in.

When you're hacking together an MVP as quickly as possible, it may seem like a brilliant idea to not have types. Then you have a real company and a larger team and you find out that not having types causes lots of problems. Then you graft an ugly hack like Sorbet onto your code base. It's more work and more error-prone than having a real language with types.

The official Ruby motto should be "penny-wise, pound foolish". Everything about the language is a disadvantage when you have a large code base.

pftg4• 2 years ago

find out that not having types causes lots of problems

Yeah, it's hard to find a decent team, so we work with less experienced guys who need a lot of safeguards like static types ;)

Ruby solves this problem: you do not need big teams, so you are more comfortable finding better developers. Ruby allows to reduce team 5x.

lloeki4• 2 years ago

Nor of RBS and Steep, the latter which has a LSP.

drwl• 2 years ago

Gusto adopted it when I was there (I left at the end of 2022). Like other comments, it's a bit polarizing but I found it to be useful when working in large codebases because you one didn't have to reason about return types and could just read them from function signatures.

Getting it to play nicely with Rails and other gems that did metaprogramming magic was a constant pain in the butt though.

hamandcheese• 2 years ago

Flexport (no longer employed there) adopted it in a 1M+ loc ruby app, and achieved relatively high type coverage surprisingly fast. Can't remember the exact numbers but it felt most code I touched was strongly typed.

I would say it was immensely worth it. It caught bugs for me before runtime on a daily basis, and enabled refactors that would have been so much more difficult without it.

It was far from painless, and there were plenty of outstanding issues even when I left. But I consider it an invaluable and essential tool for any large ruby codebase.

I was particularly impressed at how fast sorbet was. Way faster than typescript on a comparably sized codebase.

pftg4• 2 years ago

No, it's an additional tool only for big legacy projects! TDD is much simpler and safer.

hbroadbent3• 2 years ago

Author here, thanks for sharing!

I'm really excited for where some of the extensions in the article are going - the RubyLSP has been improving slowly and steadily and I'm hoping that this is the year it gets _really good_. Other extensions like the StimulusLSP are niche, but awesome, and on the Twitter thread for this article (https://twitter.com/hrrsnbbnt/status/1759900961760477681) someone even pointed me to a new ERB formatter that looks promising.

TLDR; Rails is alive and well! Ruby has never been a first-class citizen of VS Code, but there's still some awesome extensions out there to give you a decent experience. And it's getting better!

jmg_• 2 years ago

Mind linking the ERB recommendation? Can’t see the replies without an account.

hbroadbent3• 2 years ago

Sure - https://marketplace.visualstudio.com/items?itemName=elia.erb...

lloeki4• 2 years ago

I saw no mention of RBS+Steep, the latter providing a LSP. I use it a lot and very much like it, although it's still young and needs love, but it's making good, steady progress! I've been very pleasantly surprised by some of the crazy things Steep can catch, completely statically!

You appear to be working on projects with Sorbet (which I tried to like but found it fell short in practice, notably outside of the app use case i.e it's mostly useless when authoring a gem) so it may be a tall order to try on those. Maybe you can give RBS+Steep a shot on some small project?

RBS: https://github.com/ruby/rbs

RBS collection (for those gems that don't ship RBS signatures in `sig`, integrates with bundler): https://github.com/ruby/gem_rbs_collection

Steep: https://github.com/soutaro/steep

VS Code: https://github.com/soutaro/steep-vscode

Sublime Text: https://github.com/sublimelsp/LSP

Vim (I'm working on it): https://github.com/dense-analysis/ale/pull/4671

rattray3• 2 years ago

Nice! Does the Steep LSP for VS Code give you nice intellisense even if you don't have rbs files? How's the speed?

aaronbrethorst• 2 years ago

My VSCode setup required me to spend probably 10-15 hours reading medium blog posts, fighting with settings, working around bugs in extensions, and then finally paying for RubyMine.

firecall3• 2 years ago

For me it’s Sublime Text.

I really don’t get the VS Code love.

It’s fine as a free editor.

But laggy and cluttered. It’s like the Las Vegas of editors.

I always feel compelled to come and hang out on these threads as I really don’t understand the VS Code love, but I try to as surely I’m missing something…..

ColonelPhantom• 2 years ago

How is VSCode cluttered? It's not perfect, but the UI is pretty well organized between the titlebar, sidebar(s) and status bar.

I think the UI is way cleaner than e.g. the old JetBrains UI. The new JB UI is on the other hand pretty comparable to VSC.

strzibny• 2 years ago

I completely feel you + the 'browser' vibes

mplewis• 2 years ago

What do you find cluttered?

devjab• 2 years ago

It’s probably because it isn’t laggy or cluttered for many of us. I do think its usefulness depends a lot on which tools you’re working with and what sort of VSC plugins are available for them.

One or the things we really like about VSC is how “easy” you can “enforce” opinionated coding styles and tool setups through sharing the .vscode configurations directly in your repositories. We’re not too fascist about it. The opinions are semi-democratically decided and you’re free to override them to some degree. But because our deployment pipelines are in fact fascists, it’s very helpful to have those “global” settings at times. Like when we’re onboarding new developers, or when we’re using external consultants. Because it lets anyone just jump in and build code the way everyone else does.

Now, from the sound of things getting your VSC groove on with Ruby isn’t as easy as it is with something like Typescript. Which leads me back to the thing about tooling. Because VSC is certainly better for some things. Even something like C# which is getting good in VSC, is still “better” in VS. You’re probably very likely to use VSC for C# as VS sort of sucks, in our team only one person is still clinging on to VS as an example, but it all comes down to support.

Now, my VSC isn’t slow or laggy, but it can be. I have a couple of extensions that are just horrible for performance, but I tend to turn them off any time I’m not using them to avoid this. Similarly you’re going to need to know your way around the settings to get it to really fit your needs and you’re probably not going to have a good time if you sort of “google” configure your VSC because many of the guides are absolute trash. As it is with many things, it’s very hard to tell the trash from the gold, so the only way will often involve reading the manual. You can get away with not doing that for most usage with common languages, but for power use you’re eventually likely to have to dig into Microsoft’s horrible documentation.

block_dagger• 2 years ago

It’s the ubiquity and plugin community.

AndyJames• 2 years ago

I dropped Sublime after they pushed upgrade to 4 without asking and without (at least initially) allowing for cheap upgrade. So suddenly from having paid version I became user of trial without easy way of going back to 3. The fun part is that I would probably move to 4 at some point in time but I was forced and I didn't liked it.

fbdab1032• 2 years ago

I would not say I love it, but it is free, and does what is needed out of the box.

The real selling point is the plugins, notably the Remote Development extension. This lets you locally run the IDE while the code runs/lives on a remote (SSH/Docker) host which could be beefier or specific hardware. Complete game changer that I now find impossible to do without.

If you want, I could give a list of inexcusable grievances that are maintained to this day. My favorite would be this: https://github.com/microsoft/vscode/issues/40233 . From the outside, would only take a handful of lines to read two configuration files instead of one. Open for six years.

_s• 2 years ago

Also my personal opinion / thoughts:

If you predominantly work in TypeScript, for the web, there's no better editor.

It's faster & "lighter" than any JetBrains product, but has excellent "auto-complete" that's fairly intelligent / context aware, while still being almost as fast / lightweight as Sublime. Use with ESLint + Prettier, with format on save enabled and you tend to fly through typing TypeScript.

It does pretty well for React Native too, it's reasonably good for JavaScript, and pretty poorly for anything else (Go, Ruby, PHP, Java / Kotlin, Swift / Objective-C), C/C++/C#.

pizza234• 2 years ago

I switched from ST to VSC due to a few omissions and bugs in ST (don't know if they're still there).

VSC is not a speed demon but it's fast enough (I think there is a certain audience who loves to hate this; JetBrains products are measurably slow, but nobody ever complains about it). I have the suspicion that plugins may impact the experience.

The main layout is very simple (besides the status bar, but that takes very little) and almost anything can be bound to a key combination, so one can reach everything very efficiently (for example, even if the sidebar changes to something undesired, it's possible to switch to Explorer via key binding).

The major problems I've found with Ruby on VSC are:

1. VSC's built-in support for Ruby is just terrible - indentation is broken, and based on the bug tracker, they have no interesst in fixing it.

2. Solargraph is unusable for projects of even moderate complexity - it's extremely slow and inefficient, to the point of hanging in some cases.

sosodev• 2 years ago

+1 for RubyMine. It works perfectly out of the box.

replygirl• 2 years ago

almost 10 years in--maybe it's time to stop trying

chihuahua5• 2 years ago

All the Ruby tools are so bad. It's all crap. I started a new job where I have to use Ruby. The company has about 300 engineers, and it seems that no one has a good setup. Some people use VSCode, but no one has a set of extensions that really works well. Debugging by attaching to a running process doesn't work. Some people use RubyMine, but it's also somewhat broken - for example, it formats the code in a way that RuboCop doesn't like. The debugger works every other week.

A lot of people set debugger breakpoints by inserting "debugger" or "binding.pry" manually. That also sucks because you can't easily disable a breakpoint after you've reached it. And of course it's an idiotic way of inserting breakpoints, because you can't just detach the debugger - you have to delete every breakpoint if you want the the server to just run.

The language itself is also badly designed. A single-line block uses { }, but when it's multiple lines, it has to be changed to "do" and "end" - why? Do/end is dumb for the other constructs - VSCode can easily jump to a matching paren/bracket/brace, but not to the matching do/end. Who thought |x| was a good idea? Look at C# to see how this should be done. That's just scratching the surface, there are so many shitty features in this language.

Then on top of this, you have Sorbet - grafting type checking onto the code, but outside the language. It's about 100 times uglier than just having typing built into the language. Today I learned that you can't provide a Sorbet sig for a module_function - Rubocop doesn't understand it. Rubocop runs as part of "git commit", so you can't do anything that Rubocop doesn't like.

All of this is so shitty and amateur and primitive and backwards. Right now is not a good time for finding a new job as a software engineer, otherwise I'd be out of here looking for a job where I can use a real language with real tools that work and improve productivity rather than killing productivity like the Ruby circus.

Rails has some nice features, but for every bit of productivity gain that it gives you, there's about 10x as much negative impact on productivity.

NegativeLatency• 2 years ago

I find I’m very productive with rails and like so many things there’s plenty of room for personal taste.

execat• 2 years ago

A single-line block uses { }, but when it's multiple lines, it has to be changed to "do" and "end" - why?

It doesn't have to be changed. {} work fine on multi-line blocks also. It's probably your linter that's forcing you to change them to do... end blocks: https://try.ruby-lang.org/playground/#code=3.times+%7B%0A++p...

neonsunset2• 2 years ago

I'm very sorry to hear this. Switching from C# to most things is painful, because of an uncloseable rift with its tooling, features and standard library. In particular with Ruby, that HN insists on loving to its own detriment, which is by far one of the worst offenders - it is slow, brittle and stuck in the past, just like you described.

Some developers will claim "it's a preference" or mistakenly assume it can be compared side by side with other back-end stack. This just stems from critical gap in required software engineering knowledge - Ruby does not and cannot compete with other stacks. I tend to be critical of Go, but I would pick it every time over Ruby if the circumstances would not let me use something better.

(seriously, friends don't let friends deploy new projects in Ruby, use C# or Kotlin or any other compiled language that strikes your fancy)

elevaet• 2 years ago

I'd love it if you could elaborate!

I just randomly started learning Ruby for shits and giggles over this last week, so I'd love to hear more of why not to go down this path (not that I necessarily would hit the brakes)

I've also been dabbling in Go over the last year or so and really enjoyed playing around with it, but I do find it a bit verbose. On the other hand, its performance is really impressive.

vlz• 2 years ago

I remember feeling similar a few years back when a scripting language was thrust upon me (python in this case) coming then from a few years in statically compiled languages. It felt clumsy and unproductive for an astonishingly long time. I complained endlessly about this and that. At some point though it somehow clicked and I felt at home in the language.

Ruby is really not easy to get into with its n ways of doing things and supposed "magic" methods. I think it can be worth it. Rails (7) feels very productive right now.

(Never had to deal with sorbet/rubocop though and guilty of just writing "debugger", Rubymine has normal breakpoints as well though.)

firecall3• 2 years ago

The best VS Code and Ruby on Rails setup is Sublime Text!

Or Ruby Mine.

Anything but VSCode for me!

pftg4• 2 years ago

Yep! RubyMine is like Ubuntu, and VSCode is Arch Linux!

pftg4• 2 years ago

Using VS Code as a Ruby on Rails editor shouldn't be so hard!

However, I personally prefer RubyMine since it comes with everything out of the box.

I only use VS Code as a text editor replacement.

hakunin• 2 years ago

Zed is a great contender for Ruby. I'm considering it, coming from Sublime Text, only needs a few small additions. Much better first impressions than VSCode.

A decent VS Code and Ruby on Rails setup

Related Stories