4 ms·

> Anyway, Ruby was designed to make programmers happy, and it is a big success at that. I switched to golang from ruby and I definitely don't miss the ctrl+f h

• jshen 4y ago
  I find most things by jumping into pry at a break point and inspecting it. Works really well, but isn’t something that’s common in other languages so people don’t think to do it.
  • itake 4y ago
    Debugging with pry is annoying for complex inputs (api param with lots of Json or lots of state). You end up making a complex scratch page notes trying to collect all of the inputs to just test the function call. When the code causing issues is within a gem (and outside of your VSCode project directory) it’s also annoying to find the gem path and source code. Solvable, but time consuming.
    • izietto 4y ago
      bundle show gem-name bundle open gem-name Fix the last one
      • itake 4y ago
        yep, gotta run a bunch of terminal commands to get to the file path. And then have to modify the gem's source code to add debugging lines. When you're done, you gotta re-install the gem in case you didn't revert all of your debug tweaks.
        • jshen 4y ago
          Isn’t that more or less true when looking for a bug in a third part library in any language?
    • rco8786 4y ago
      > Debugging with pry is annoying for complex inputs Debugging for complex inputs is always hard, but I’ve yet to see a language do it better than Ruby/pry. Write a test that sets up your complex input, slap a pry in it, use the repl to debug/explore/iterate, then leave the test in place when you’re done.
      • itake 4y ago
        Go forces you to use dependency injection, which makes it much easier to have simple structs (objects). With Ruby (and specifically Rails), so much state is tacked onto ActiveRecord that its difficult to mock/debug apis. For example, calling `#find()` creates a new object or trying to stub out `User::ActiveRecord_Relation` in tests is frustrating.
        • rco8786 4y ago
          Ah yea, ActiveRecord has some cruft like that for sure. That’s probably why it’s so common to use an actual database for testing and mocking data. Which has its own set of benefits/drawbacks.
• jkogara 4y ago
  I use ctags that are rebuilt in the background on each commit or pull, makes find source code of definitions trivial.
  • itake 4y ago
    Does ctags work for inspecting source code of gems? Does it work with dynamic method definitions? ‘define_method(“#{req.id}_log”)’
• msbarnett 4y ago
  If anyone very finds themselves hunting around for a method definition like this, method(:blah_changed?).source_location is your new best friend.
  • itake 4y ago
    True, but then you have to run the program and figure out how to call whatever the calling function is.
    • rco8786 4y ago
      Also true, but worth noting that this is generally a trivial thing to do for Ruby codebases I switched from Ruby to java/kotlin and am consistently frustrated how hard to impossible it is to start a jvm app locally. But also realize that doing so is fairly useless since there’s no interactive repl anyway. It’s just a different way of programming I suppose.
      • itake 4y ago
        Yes, its easy to run, but I found that re-creating 'production' input parameters annoying. In rails, that might be setting the request state (set current user, gen a jwt tokens, etc.) which is required for debugging views or controller code. I also found ruby made me worse at leetcode problems, since my default debugging taught me to run the code, instead of think through program state.
        • rco8786 4y ago
          > re-creating 'production' input parameters annoying Just curious, annoying relative to what language/pattern that does it better?
          • itake 4y ago
            With Ruby, there is more state stored in the classes than more functional languages (e.g. go-lang or python). Setting that state with ruby in rspec tests is annoying since its not always clear what types and mocks you need without running the code. Since golang is typed and uses dependency injection, its very easy to know what inputs you need or mocking out values.
• weatherlite 4y ago
  It's not like Golang doesn't come with its own set of frustration. Several things I miss from Ruby/Rails 1) An interactive shell. It's sometimes super convenient to run Rails c and just call whatever worker or model method you want...not really doable in Go. 2) Ruby's Enumerable. Even with Generics, manipulating and finding elements or sorting collections in Go is much harder and more verbose than Ruby. In web apps we do only this most of the time. 3) Rails. I just miss one big batteries included framework. No such thing in Go afaik. 4) Expressiveness. There is no ternary operator in Go for example, as the philosophy of Go is to reduce language keywords as much as possible. As a result you generally have more code and are less expressive. While there are pros to this I personally see this as more of a con.
  • itake 4y ago
    1) true. The unit tests tend to fill that gap for me thought. 2) +1 3) There are a lot of Go frameworks that replicate rails framework. At my job, we use Go-kit. 4) yep. Go is too simple.
    • weatherlite 4y ago
      I looked around at Go-kit just now, not really getting it, it looks like a list of resources and there's a bunch of frameworks listed. Doesn't look opinionated or am I wrong?
• rco8786 4y ago
  This is my least favorite part of Ruby (coming from a Ruby fanboy) and I actively avoid patterns that make methods hard to find when writing it. Though I think I’m probably in the minority here.