5 ms·

I think that people get too used to their environment. You mentioned build tools. Ruby's build tools are still inferior to Java's Maven. Granted, few build too

I think that people get too used to their environment. You mentioned build tools. Ruby's build tools are still inferior to Java's Maven. Granted, few build tools are as good as Maven. This is coupled with something you haven't mentioned, which is the native libraries that Ruby also depends on, plus the management of Ruby versions (e.g., rbenv, rvm), something that Java, for example, seldom has to deal with, i.e., Java dependencies are mostly pure Java, and the latest Java can still work with JARs compiled for Java 1.x. This backwards compatibility, which makes the latest version good enough for most projects, is also shared by Node. The latest Node LTS is usually just fine. Ruby's situation is not as bad as Python's in this regard, but many times you still get the sense that, in order to get a reproducible build, it's wise to just build inside a Docker image. The problem I see with Rake, or Bundler/gemfiles is that the syntax is just Ruby code. It's a DSL described by Ruby, the language being good for it, but it's Ruby code nonetheless, which makes tooling more complicated than it needs be. Rake is cool and all, but `make` is available everywhere, and that basically kills any potential that Rake might have for non-Ruby projects. I'm glad to see that RuboCop exists, or the LSP situation improving. The problem that Ruby will always have is that it's a dynamic language that's not JavaScript, hence anything related to static analysis is subpar. This is something you may be able to live with, due to the very playful way people tend to work with in Ruby (or other dynamic languages), but tooling will always be subpar compared to static languages. And granted, many other languages have bad tooling, too.

ativzzz 3y ago
> The problem I see with Rake, or Bundler/gemfiles is that the syntax is just Ruby code. It's a DSL described by Ruby, the language being good for it, but it's Ruby code nonetheless, which makes tooling more complicated than it needs be. Rake is cool and all, but `make` is available everywhere, and that basically kills any potential that Rake might have for non-Ruby projects. I see this as a plus. A tool for ruby, using ruby to configure it. Yea you won't use it outside ruby projects, but that's totally fine.
- RangerScience 3y ago
  Yep. Use Rake tasks for things that benefit or require "the rest" of the code (looking at you, Rails tasks)... ...and then call them from Make ;)
RangerScience 3y ago
It sounds like you're expecting something that "solves the same problems", but, those problems don't exist. Take "build tools". Java needs build tools because it's got to be compiled. Ruby isn't compiled, so you don't need build tools - you only need dependency management, and Bundler is a best-in-class for that. Trying to say "Ruby's build tools are inferior to Maven" is like saying ""fish bicycles aren't as good as human bicycles". > Docker Eh. RVM was good enough it got cloned (NVM); between that and `bundler exec`, you didn't really need anything else; Docker is nice because those two don't cover everything, but again - I think you're looking for solutions to problems Ruby largely doesn't have, and then judging the tooling for not existing. > Rake Uhhh hate to tell you this but 1) you don't need to use Rake for things you can do in Make and 2) you can't use Make for things you can do in Rake. Rake is mostly used for things that need the rest of your ruby code; aka, Rails. Sure, you can write a Ruby script that does all that and invoke it from Make... and then you've just recreated Rake, only without the bells and whistles. (What you do is just invoke the Rake tasks from Make) > Rubocop... LSP... static analysis Sure. There's some pretty cool new / on the horizon stuff around this (RBS and related, plus a new unified parser - https://rubyconf-2023.sessionize.com/session/531482 https://rubyconf-2023.sessionize.com/session/531482)... but, and I realize this, in particular, is super subjective: you just don't have the same problems. Ruby programming tends to only use a few types (basic scalars, basic collections, and ORM models), and then testing. There just isn't the same need for static analysis, and it's because of everything from overall simpler code & parameters to tests covering the same need. TL;DR - Yeah, if you try to program Ruby like it's Java you're gonna feel the "missing"tools, but largely (and subjectively) if you probram Ruby like it's Ruby you just don't have the problems that those tools exist to solve. (This is also why something like 75% of the Gang of Four patterns just don't show up in Ruby - they exist to solve issues that only occur in Java / languages like Java) Edit: One place I do miss "better tooling" - sometimes! - is the debugger. Pry is amazing and gets you 90% of the way, but it's not quite as nice as an IDE-integrated breakpoint and the like. But, again, it's just not as needed - not when I can pop into the console and invoke the code manually. Edit 2: Oh also autocomplete. Definitely miss type-aware autocomplete... but it sounds like RBS is making headway there.
- lloeki 3y ago
  > debugger Check out the latest IRB on 3.3, it finally gives Pry a run for its money, especially when jumping into the debugger! https://github.com/ruby/irb#debugging-with-irb https://github.com/ruby/irb#debugging-with-irb $ ruby test.rb From: test.rb @ line 7 : 1: def foo 2: 10.times do |i| 3: p i 4: end 5: end 6: => 7: binding.irb 8: 9: foo irb(main):001> break 9 (rdbg:irb) break 9 #0 BP - Line /Users/loic.nageleisen/test.rb:9 (line) irb:rdbg(main):002> break 3 #1 BP - Line /Users/loic.nageleisen/test.rb:3 (line) irb:rdbg(main):003> continue [4, 9] in test.rb 4| end 5| end 6| 7| binding.irb 8| => 9| foo =>#0 <main> at test.rb:9 Stop by #0 BP - Line /Users/loic.nageleisen/test.rb:9 (line) irb:rdbg(main):004> continue [1, 9] in test.rb 1| def foo 2| 10.times do |i| => 3| p i 4| end 5| end 6| 7| binding.irb 8| 9| foo =>#0 block {|i=0|} in foo at test.rb:3 #1 Integer#times at <internal:numeric>:237 # and 2 frames (use `bt' command for all frames) Stop by #1 BP - Line /Users/loic.nageleisen/test.rb:3 (line) irb:rdbg(main):005> bt =>#0 block {|i=0|} in foo at test.rb:3 #1 Integer#times at <internal:numeric>:237 #2 Object#foo at test.rb:2 #3 <main> at test.rb:9 irb:rdbg(main):006> See also the debug gem by itself: - https://github.com/ruby/debug#debug-command-on-the-debug-console https://github.com/ruby/debug#debug-command-on-the-debug-con... - https://github.com/ruby/debug#remote-debugging https://github.com/ruby/debug#remote-debugging - https://marketplace.visualstudio.com/items?itemName=KoichiSasada.vscode-rdbg https://marketplace.visualstudio.com/items?itemName=KoichiSa...

ativzzz 3y ago

> The problem I see with Rake, or Bundler/gemfiles is that the syntax is just Ruby code. It's a DSL described by Ruby, the language being good for it, but it's Ruby code nonetheless, which makes tooling more complicated than it needs be. Rake is cool and all, but `make` is available everywhere, and that basically kills any potential that Rake might have for non-Ruby projects. I see this as a plus. A tool for ruby, using ruby to configure it. Yea you won't use it outside ruby projects, but that's totally fine.

RangerScience 3y ago
Yep. Use Rake tasks for things that benefit or require "the rest" of the code (looking at you, Rails tasks)... ...and then call them from Make ;)

RangerScience 3y ago

It sounds like you're expecting something that "solves the same problems", but, those problems don't exist. Take "build tools". Java needs build tools because it's got to be compiled. Ruby isn't compiled, so you don't need build tools - you only need dependency management, and Bundler is a best-in-class for that. Trying to say "Ruby's build tools are inferior to Maven" is like saying ""fish bicycles aren't as good as human bicycles". > Docker Eh. RVM was good enough it got cloned (NVM); between that and `bundler exec`, you didn't really need anything else; Docker is nice because those two don't cover everything, but again - I think you're looking for solutions to problems Ruby largely doesn't have, and then judging the tooling for not existing. > Rake Uhhh hate to tell you this but 1) you don't need to use Rake for things you can do in Make and 2) you can't use Make for things you can do in Rake. Rake is mostly used for things that need the rest of your ruby code; aka, Rails. Sure, you can write a Ruby script that does all that and invoke it from Make... and then you've just recreated Rake, only without the bells and whistles. (What you do is just invoke the Rake tasks from Make) > Rubocop... LSP... static analysis Sure. There's some pretty cool new / on the horizon stuff around this (RBS and related, plus a new unified parser - https://rubyconf-2023.sessionize.com/session/531482 https://rubyconf-2023.sessionize.com/session/531482)... but, and I realize this, in particular, is super subjective: you just don't have the same problems. Ruby programming tends to only use a few types (basic scalars, basic collections, and ORM models), and then testing. There just isn't the same need for static analysis, and it's because of everything from overall simpler code & parameters to tests covering the same need. TL;DR - Yeah, if you try to program Ruby like it's Java you're gonna feel the "missing"tools, but largely (and subjectively) if you probram Ruby like it's Ruby you just don't have the problems that those tools exist to solve. (This is also why something like 75% of the Gang of Four patterns just don't show up in Ruby - they exist to solve issues that only occur in Java / languages like Java) Edit: One place I do miss "better tooling" - sometimes! - is the debugger. Pry is amazing and gets you 90% of the way, but it's not quite as nice as an IDE-integrated breakpoint and the like. But, again, it's just not as needed - not when I can pop into the console and invoke the code manually. Edit 2: Oh also autocomplete. Definitely miss type-aware autocomplete... but it sounds like RBS is making headway there.

lloeki 3y ago
> debugger Check out the latest IRB on 3.3, it finally gives Pry a run for its money, especially when jumping into the debugger! https://github.com/ruby/irb#debugging-with-irb https://github.com/ruby/irb#debugging-with-irb $ ruby test.rb From: test.rb @ line 7 : 1: def foo 2: 10.times do |i| 3: p i 4: end 5: end 6: => 7: binding.irb 8: 9: foo irb(main):001> break 9 (rdbg:irb) break 9 #0 BP - Line /Users/loic.nageleisen/test.rb:9 (line) irb:rdbg(main):002> break 3 #1 BP - Line /Users/loic.nageleisen/test.rb:3 (line) irb:rdbg(main):003> continue [4, 9] in test.rb 4| end 5| end 6| 7| binding.irb 8| => 9| foo =>#0 <main> at test.rb:9 Stop by #0 BP - Line /Users/loic.nageleisen/test.rb:9 (line) irb:rdbg(main):004> continue [1, 9] in test.rb 1| def foo 2| 10.times do |i| => 3| p i 4| end 5| end 6| 7| binding.irb 8| 9| foo =>#0 block {|i=0|} in foo at test.rb:3 #1 Integer#times at <internal:numeric>:237 # and 2 frames (use `bt' command for all frames) Stop by #1 BP - Line /Users/loic.nageleisen/test.rb:3 (line) irb:rdbg(main):005> bt =>#0 block {|i=0|} in foo at test.rb:3 #1 Integer#times at <internal:numeric>:237 #2 Object#foo at test.rb:2 #3 <main> at test.rb:9 irb:rdbg(main):006> See also the debug gem by itself: - https://github.com/ruby/debug#debug-command-on-the-debug-console https://github.com/ruby/debug#debug-command-on-the-debug-con... - https://github.com/ruby/debug#remote-debugging https://github.com/ruby/debug#remote-debugging - https://marketplace.visualstudio.com/items?itemName=KoichiSasada.vscode-rdbg https://marketplace.visualstudio.com/items?itemName=KoichiSa...