Live data from Hacker News

An Ode to Ruby

blog.yboulkaid.com

141–150 of 204 posts

Re: An Ode to Ruby

#141
post #65

Earlier quoted context omitted.

FWIW It seems to me your comment about Rails is a more general comment re: frameworks. Learning a language/runtime takes some effort but much less, IMHO, than learning a framework. Doesn't matter if that is Rails, Django, Ember, Angular, iOS SDK, Android SDK, React+Redux+???, and so on.

I don't think so out of your list I've used the Android SDK along with a react and redux stack and I didn't get the name kind of feeling. With those you start out with a mainly clean project and everything makes more sense to me how it works.

The Android SDK is huge. If you view learning that framework as significantly easier than learning Rails, you're a better programmer than I.

Re: An Ode to Ruby

#142
post #37
post #36

Earlier quoted context omitted.

Ok, that's a nicer result (obviously I don't write Python lol) but still seems inconsistent to me (putting the function before the array) considering Python is an OO language and most people are going to be writing methods for classes where you call methods with dot. I just remember list comprehensions from Coffee-script and not going to lie, I hate them. It's like reading backwards.

Python is a multi-paradigm language, of which OO is one paradigm it supports.

Not really. Python 3 is all OO under the hood including what appear to be procedural functions. It's just not as elegant as Ruby's OO.

Re: An Ode to Ruby

#143
post #80

Earlier quoted context omitted.

I also took a while to get used to the typing in Crystal but once you do get it, it's worth the effort IMO. I occasionally still fire up Ruby but if I have anything more to do than a quick command-line command, I use Crystal, so many less problems.

I think I'd be more interested in Crystal if it was easier to integrate into existing ruby code bases via something like the FFI. As it is from Ruby 3.0 we have built in optional static typing and with interesting projects like Sorbet Compiler[1] we have the option to statically compile making use of that. It's still WIP I believe but it's giving ruby devs some cool options. 1. https://sorbet.org/blog/2021/07/30/open…

> I think I'd be more interested in Crystal if it was easier to integrate into existing ruby code bases via something like the FFI.

That would be very nice, I agree, though I've always found the FFI interface an under-documented pain so I'd probably end up just using Crystal or using some other way to interoperate, like pipes or HTTP.

On Sorbet, I just hate the look of it. I know it's subjective (possibly that's Ruby's own fault for being so delightful to look at, I'm spoiled!) but I can't abide the syntax. Crystal's is much nicer, and has some extra sugar sprinkled on top for the moments you're most likely to be using it (like external names in method signatures[1] or providing init args) that win out for me.

Sorry about the formatting, I can't work out HN's markdown :/

  # Ruby

  # from the Sorbet intro
  extend T::Sig

  sig {params(name: String).returns(Integer)}
  def main(name)
   puts "Hello, #{name}!"
   name.length
  end


  # Crystal

  def main(name : String) : Int
   puts "Hello, #{name}!"
   name.size
  end

  puts main "you"

That's so much nicer to my eyes, and you don't need most of it as it will be inferred.

Initialisation is nicer, too, (unless Ruby has been updated in this regard too? As I wrote, I use it much less now)

  # Crystal

  class A
   getter name : String
   def initialize(*, @name); end
  end

  a = A.new name: "Hacker News"
  puts a.name
or without the getter and keyword arg:

  # Crystal

  class A
   getter name 
   def initialize(@name : String); end
  end

  a = A.new "Hacker News"
  puts a.name
Whatever suits.

  # Crystal

  # Example of external names

  def increment(value, by)
   # OK, but reads odd
   value + by
  end

  def increment(value : Int, by amount : Int) : Int
   # Better
   value + amount
  end

  puts increment 1, 2

but those types are easily inferred so it's actually:

  # Crystal

  def increment(value, by amount)
   # Even better
   value + amount
  end

I could go on because now I'm comfortable with it, it looks much better. I feel the way moving from Perl and C# to Ruby felt.

[1] https://crystal-lang.org/reference/1.3/syntax_and_semantics/...

Edit: formatting, of course

Re: An Ode to Ruby

#144
post #37

Earlier quoted context omitted.

Python is a multi-paradigm language, of which OO is one paradigm it supports.

Ruby is a strongly OO language, which arguably also has better support for functional programming than Python.

Yes, that's the Zen of Ruby and why I love it.

Re: An Ode to Ruby

#145
post #57
post #33

Earlier quoted context omitted.

To be fair, you almost never should use the map builtin instead of the pythonic equivalent, list comprehensions. `print([x + 1 for x in [1, 2, 3])` I agree that the ruby approach is better in terms of consistency, but most developers will be aware of the conventions python uses.

Python, I think, has n number of ways of doing the same thing while Ruby's everything is object approach forces you down a single approach. So while reading ruby code, you usually don't have to shift your mental model from OOP to procedural/list comprehension etc. If Ruby gets a good machine learning library on par with something like Pytorch, I am sure many folks will shift to it and we might see new DSL emerge.

How I wish that was a possibility. Unfortunately Python's dominance of ML and AI is a fait accompli. If anything is going to replace Python in this domain it won't be another scripting language with similar performance.

Re: An Ode to Ruby

#147
post #28

Earlier quoted context omitted.

Nope. Can't stand that Python uses built-in functions for basic things like list, map, fold, etc... instead of methods on base classes. Here's a super basic example. Add one to an array [1,2,3] and print results. Python: print(list(map(lambda x: x + 1, [1,2,3]))) Ruby: print [1,2,3].map {|x| x + 1} So much more readable, easy to write, etc... Ruby keeps it consistent by making pretty much everything an object and you…

For me it's annotations. Looked at from a distance, what appears to have happened is that the implementation hit a certain level of complexity before class methods got implemented, and it ended up being easier to do them with "@classmethod" than with "def self.foo", or to fix whatever reason it is that makes "def foo(a,b,c)" not act like a class method if "a" isn't "self".

For me it's crippled lambda and __dunders__.

Re: An Ode to Ruby

#148

Earlier quoted context omitted.

I also took a while to get used to the typing in Crystal but once you do get it, it's worth the effort IMO. I occasionally still fire up Ruby but if I have anything more to do than a quick command-line command, I use Crystal, so many less problems.

Crystal was overall a pleasant experience, which I cannot say for Rust. Although it was probably my fault: 1) for being "rusty" as a programmer myself, and 2) having zero experience with Rust. I want to believe that once you get over the learning curve in Rust development speed becomes much higher. Surprisingly, Crystal seems to be much leaner in runtime size than Rust, with similar performance (although the use case…

I also gave Rust a go (last year? Hard to keep track since the pandemic) but the book I was using was geared to C programmers so I quickly lost interest, though I would like to understand what the hype is about.

I think the bit about productivity may certainly be true if you have to use libraries, obviously Ruby has many more available now (maybe forever), but I certainly feel more productive in Crystal now, maybe for things other than the language itself, admittedly. For example, producing a binary makes installation a breeze, and I don't worry about which version I'm running as I point the right compiler at the code; no Bundler now, library installs are sane (at last!); and socially I find the lack of "rockstars" in the main team refreshing, I have no fear of being dissed or dismissed, it makes contributing easier.

Re: An Ode to Ruby

#149

One of my goals for 2022 is to write my first real web app. I want to understand things like authentication, creating an API, and security. My initial impression is that the JS/Node world is miserable. Rails looks 1000 times more pleasant.

Language elegance is not the reason Node is chosen over Ruby. Async and performance is. If I want my app to call a couple of services without using a ton of memory Node is the better option.

Re: An Ode to Ruby

#150
post #55

One of my goals for 2022 is to write my first real web app. I want to understand things like authentication, creating an API, and security. My initial impression is that the JS/Node world is miserable. Rails looks 1000 times more pleasant.

> My initial impression is that the JS/Node world is miserable. Rails looks 1000 times more pleasant. God, yes. Especially with Hotwire [1], which advertises being able to do modern web apps with a minimum of JS. I've played around with it, and for me it completely eliminates the need for AngularJS/React/whatever. [1] https://hotwired.dev

Yes but Node's built-in async will scale a lot better especially if you're calling 3rd party services.
Post reply on HN