Hacker News Reader

Comment by Mikeb85 | Hacker News Reader

It's too bad Ruby isn't seen as 'cool' anymore, it's just so easy to be productive in it. And now MJIT, YJIT and TruffleRuby are making some very impressive performance gains. Rails is also better than ever and I still can't think of a better language for scripting.

View on HN

I love the fact that Ruby is no longer cool anymore and has finally matured enough that one can build a stable system on top of it. It now has been battle tested and powers some of the biggest platforms on the web.

I couldn't be happier with the direction that Ruby 3.0 and Rails 7.0 are taking at the moment. We have businesses to run and Ruby allows just for that. It's boring, it's stable and will deliver results.

I wouldn't pick it to build the next Discord though.. One must use the right tool for the job.

What was cool was Rails, IMHO, and Ruby was the surprise inside it.

I've had my own personal Advent of Code these holidays, coding a small API for a personal need. Ruby (Sinatra) took one morning to full deployment in Heroku. Then I tried Crystal (Kemal) and it took me a couple of days to figure out how to map JSON to Crystal data structures. Then I rewrote it again in Rust (Rocket). Two weeks till I figured out, well, almost everything.

My opinion: they will take dynamic typing from my dead cold hands.

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 is so simple that even good old Ruby is fast enough).

But then again, I feel you cannot beat Ruby in terms of dev productivity.

I've heard it described that Rust allows you to write programs in a specific way. If you try to write them in any other way, you're going to have a very, very bad time, and fight the borrow checker every step of the way. But if you embrace that way of writing programs, it makes it pretty easy, you get really good error messages, and as a cherry on top your program will be provably sound in a way pretty much no other language can guarantee. So it all comes down to whether you're interested in learning that specific way of structuring programs.

That's true, but then it is not "allowing" or "enabling" me, it is "forcing" me to do it that way. Of course, the Rust compiler is catching a gazillion bugs beforehand, so this is cool: you finally feel like your program will have no bugs once you manage to compile it.

Error management through Option values, the borrowing checker... they are cool technologies for a C-like language, but they are not palatable at the beginning (maybe they are an acquired taste like beer?). I am tempted to stretch it a little bit more and see how productive I can become writing Rust code, but also not so sure about the effort.

The real cherry on top is that you can put "written in Rust. Modern. Fast" on your project description.

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.

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-sourcing-sorbet-comp...

> 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

Crystal is also my go-to for writing a quick script to do something.

I've had so many problems in the past, even on my own machine, writing quick scripts for Ruby that then fail because of clashing versions etc. Being able to produce a binary is nice, or even just using `crystal run`.

Btw, I took a look around your Github and found some really interesting projects (yours and others), thanks for replying!

The "you should be using Crystal" post is mandatory in any ruby thread. If everyone saying "yes, Crystal" were actually using Crystal, then:

a) they would see how far from "better ruby" is Crystal and

b) The Crystal community would be huge.

> they would see how far from "better ruby" is Crystal

Are you accusing us both of lying? How strange.

would you mind to post your github/gitlab repositories with your Crystal projects? Looking here I couldn't find anyone https://github.com/yb66?tab=repositories&q=&type=source&lang...

So you are accusing me of lying, how lovely of you!

Let's see if your accusations can hold up to Socratic questioning:

- If I haven't open sourced any Crystal projects does that mean I haven't written any?

- I have published several Ruby gems[0], when was the last commit or version bump for any of them? You're more interested that I am, tell me. I really should archive them, thanks for reminding me.

- You missed off my Gitlab, what was the last public contribution I made there? (hint[1])

- What's the last gem I created? I reckon it's this one that I didn't publish[2] because the Rack team changed a public API in such a dumb way that I'd have to rewrite it and then mucked me around with a pull request to Rack that one of the core team copy and pasted in as their own commit while arguing against the pull. Weird, but lovely people, like yourself. Meanwhile, your cookies lack security. Yes, I want to continue working within this language and ecosystem… Does the sarcasm come through in my writing?

- Why did you not check the Crystal repo?[3][4] Github has a search facility. Put my username in, and pick `commits` on the left.

- How did you miss the forks of Docopt.cr[5] and Fancyline[6]? They're right there in my public activity log. Did you not see the merges into Fancyline of my code?[7] I have more to give, just trying to find the time.

- Did you not see forks with commits such as xattr.cr[8], xdg.cr[9], and Pope.cr[10]

- You didn't see I'd provided a project[11] for Mint so it can be run easier with Docker Compose?

- Aside from that I have a whole host of changes to migrate.cr[12] still to push up. You can't know that but you might've guessed that I was at least working with that - and all the other forks of Crystal projects I have.

That is all public and not the half of the Crystal code I look at.

Should I expect an apology? If you were too cowardly to be straightforward with your accusations then I find it stretches credulity far beyond breaking that you could be big enough to provide one. We'll see, like you, I've been very wrong about people in the past.

[0] https://rubygems.org/profiles/yb66

[1] https://gitlab.com/arctic-fox/spectator/-/merge_requests/34

[2] https://gitlab.com/yb66/aes-gcm

[3] https://github.com/crystal-lang/crystal/pull/11201

[4] https://github.com/crystal-lang/crystal/blob/1.1.0/CHANGELOG...

[5] https://github.com/yb66/docopt.cr

[6] https://github.com/yb66/fancyline

[7] https://github.com/Papierkorb/fancyline/pulls?q=is%3Apr+yb66

[8] https://github.com/ettomatic/xattr/pulls

[9] https://github.com/dscottboggs/xdg.cr/pull/1

[10] https://github.com/yb66/pope.cr/commits/master

[11] https://github.com/yb66/Mint-Docker-Compose

[12] https://github.com/yb66/migrate.cr

Sorry, looking through the forks, they are all in sync with master, and most your contributions are small. It is great, nothing against it. The only thing that I wanted to say is that as soon as you start to work in a real project with Crystal you realize that it is not just a better ruby and it comes with it's own set of problems, patterns and etc. So I don't see a point to cite Crystal as option to ruby in every thread about ruby. That's my point.

> Sorry, looking through the forks, they are all in sync with master

I don't think you understand how Git works, which probably explains why you missed all the repos I needed to point out to you.

> , and most your contributions are small

What have you ever contributed? Show me.

> The only thing that I wanted to say is that as soon as you start to work in a real project with Crystal you realize that it is not just a better ruby and it comes with it's own set of problems, patterns and etc.

How would you know? Please share the repo in which you found this out. What is a "real" project?

> So I don't see a point to cite Crystal as option to ruby in every thread about ruby.

You've contributed nothing of worth, not even a specific criticism of Crystal, let alone anything worth knowing about Ruby.

> That's my point.

Great point.

> I don't think you understand how Git works, which probably explains why you missed all the repos I needed to point out to you.

LOL, you forked many repositories and didn't push any code. You just proved my point. Just people without experience in Crystal comes to ruby related threads to say "Dude, use Crystal". Happy learning <3

> LOL, you forked many repositories and didn't push any code.

Well, firstly that isn't true, and secondly even if it were true it's a good idea to fork repos you use. So, not only are you:

- childish ("LOL", really? This is HN)

- lying (always the sign of a strong argument)

- unable to search Github effectively

You also show bad development practices. Did you not see what happened this week with Colors.js[1]?

> You just proved my point.

Quite the opposite.

> Just people without experience in Crystal comes to ruby related threads to say "Dude, use Crystal".

Where is your repo showing your experience in Crystal? Or Ruby for that matter. Money where mouth is time, do you even have a single commit to a project in either language?

[1] https://github.com/Marak/colors.js/commit/074a0f8ed0c31c35d1...

> You've contributed nothing of worth, not even a specific criticism of Crystal, let alone anything worth knowing about Ruby.

There is nothing in the text about Crystal. Why should I talk about Crystal?

> Where is your repo showing your experience in Crystal? Or Ruby for that matter.

I don't have too. That's not about Crystal, but about ruby :)

That's not about me and my code, not either about your little unknown rubygems, but the desire from people like to you to recommend Crystal as "drop-in" replacement for ruby, which is not.. Typical "I'm vegan" comment when people are talking about barbecue.

Happy learning <3

If you know nothing about Crystal, and seem unable to provide any evidence that you have anything of note to add about Ruby, then you have no way of knowing if Crystal can be a drop-in replacement for Ruby, and why you’re using quotes around “drop-in” when you’re the only person on the entire page to have used that word is telling.

Mendacious to the last. If you find a way to make a substantive or informed observation then do let me know, otherwise, please save it for your friends on Reddit.

> they would see how far from "better ruby" is Crystal Are you accusing us both of lying? How strange.

now that I read "accusing us both of lying".. how could you interpret it like that? What I can see by your code, you are ruby developer trying to learn Crystal. See you in the next ruby thread ;)

> What I can see by your code, you are ruby developer trying to learn Crystal.

I don't value your opinion in this matter, you're simply trolling now.

> See you in the next ruby thread ;)

I doubt we'll interact again.

Surprised you didn't try Elixir? What about Sorbet?

Well, I did a little bit of research on Elixir a couple of years ago, so I felt like I had that covered. Using Kotlin + Ktor was also tempting.

it's way different now. I've actually never deployed elixir on a deployment service till last week (either: "was R&D and never deployed to prod", "I ran elixir on-prem inside a DC", "my prod environments have been managed by ops team"). It was surprisingly easy, had my first deploy (including installing the service provider's tool) in about... 3 hours?

I would love to try elixir, but JetBrains still does not have an IDE for it. I'm addicted to their IDEs.

I did try the community made plug-in for elixir, but had trouble getting the debugger to work which was a show stopper for me.

You probably don't want to use an ide-driven debugger for elixir, you'll want to use :dbg which has a different "conceptual model" than what you are used to and doesn't map well onto Conventional debuggers.

It's simply not the same due to the extreme high degree of concurrency in the beam VM

Well, no I actually do want that in my local environment where the only request is my own.

The fact that you are telling me that I don't want something, is why people some people find the Elixir community off-putting.

> the only request is my own

Literally, elixir doesn't work like that. There is a bunch of other stuff running around in the VM, even if you don't ask for it. It's like an operating system.

> is why people some people find the Elixir community off-putting

I mean ok. Note that I said "you probably". I'm just coming from a lot more experience than you have. But sure, keep giving yourself excuses to be closed minded. It really sounds like you went into the whole thing with the "let me find a reason to hate elixir" mindset, and not the "let me see what people are raving about mindset". Anyways, you're the one missing out.

> Literally, elixir doesn't work like that. There is a bunch of other stuff running around in the VM, even if you don't ask for it. It's like an operating system.

And yet, it does. Here's proof that you're wrong, a screenshot of the community Elixir plugin paused on a breakpoint, all the variables inspectable/modifiable and you can even jump around the stack: https://raw.githubusercontent.com/KronicDeth/intellij-elixir...

The problem was that I could not get the plugin to work consistently, but when it did work it was great.

> I'm just coming from a lot more experience than you have... giving yourself excuses to be closed minded....Anyways, you're the one missing out.

Ah huh, I'm sure...

Sorry I had to intervene here. I had the same sentiment about IDE support for Elixir from using the mediocre IntelliJ Plugin.

However... after dabbling a bit I discovered VS Code + Remote Containers Plugin (because of Docker) + ElixirLS + other minor Elixir plugins that have turned my Elixir development experience into pure bliss. I haven't used the debugger in the IDE yet but I am 99% sure it's gonna work out of the box. Happy to try and share the setup if you want to try it out.

Hot take: I'd love to see JSON die and get replaced with something more strongly typed and safer to work with. What, I'm not sure, but it is, as you say, a major pain point no matter what language you're in. Either it's easy to work with, but insecure, or it's difficult to work with.

I moved to gRPC and protobufs for this exact reason. It’s so nice to work with.

Apparently Rails is the killer application for Ruby just like Unix/Linux is a killer application for C. What Ruby enabled is something that was not feasible to be done by Java, PHP, Perl and Python (top four most popular languages for web at the beginning of Rails). For better perspective on the matter please check an excellent article by Patrick Lee, the author of the new Stanza language.

[1]Stop designing languages. Write libraries instead:

https://jaxenter.com/stop-designing-languages-write-librarie...

"I still can't think of a better language for scripting."

Python I find equally if not more simple. Would you agree?

Equally maybe. Simpler? I'm not sure, I don't know Python very well.

A couple of things I found surprising about Python was having to do the whole `re.compile` thing instead of just `//` in Ruby. Also, no one will ever convince me that a list comprehension is simpler than `map` and related functions. Also, it's hard to beat the convenience of libs that let you do `1.day.ago`.

Ruby gets complicated when people start throwing around metaprogramming where they shouldn't.

I do like Python's file == module. Python seems like it would be a good functional programming language but it goes and only allows for single line lambdas.

Again, I don't know Python very well.

> Ruby gets complicated when people start throwing around metaprogramming where they shouldn't.

This is true. Thankfully it appears that the broader Ruby community has recognized this as well, and has moved away from metaprogramming to a large extent. It's still there, but you don't see it utilized nearly as frequently as you once did.

I'm fine with it for libraries. In fact, its use in libraries is a lot of makes ruby great! It goes too far when people start sprinkling it in business logic making it impossible to find where anything is defined. I'd say you'd either have to go full-lisp and create an entire DSL for your domain (and document it) or keep it completely out of business logic (which, as you say, the community as a whole has pretty much figured this out).

I am not a Python or a Ruby dev.

The Ruby devs I know are overall great devs

The Python people are second-rate.

Ruby produced tons of good software as a framework base besides Rails.

Python? Eh.

I'm a Python dev. The python devs I know are average on average. I have never met a Ruby dev. But I'm sure I'm first rate!

It's not about simplicity, It's about expressivity.

> Python I find equally if not more simple. Would you agree?

Simple, yes. But when I want to write a script as fast as possible with the least amount of effort I don't want simple. I want convenient and powerful. Many things which in Python take multiple lines in Ruby are simple one liners.

There's a certain dichotomy between Ruby and Python that I also see in many other pairs of languages. One language is simple, easy to learn and easy to read (Python), but is not as powerful or convenient to write. The other language is more complex, harder to learn and harder to read (Ruby), but is more powerful and convenient to write.

It seems like most people prefer the first category, which I think is why languages like Python or Go are so popular. There's nothing wrong with that as it's a tradeoff, but I personally prefer the second category, which is the reason why I do all of my scripting in Ruby and not in Python like everybody else.

Simply put I don't really mind the extra complexity since it is essentially mostly a one time cost, so I always pick whichever tool will make me more efficient in the long run. And out of the two (Python and Ruby) that's Ruby. (With a few exceptions like, e.g. machine learning, where you don't really have a choice.)

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 just call methods. Even Haskell has dot notation to chain functions since it's just so much easier to read and write...

print([x + 1 for x in [1,2,3]])

This really goes to the heart of the problem with modern Python. It's lost the simplicity of the language which was the whole point of it in the first place. OO and functional paradigms were bolted on to varying degrees of success, but an outsider can no longer look at average Python code and understand it at a glance.

List comprehensions were added to Python in version 2.0, which was released 21 years ago. That was about six years after Python 1.0 was released. Are you seriously pining for the simplicity of Python 1.x? (Most of the "outsiders" you're talking about were in elementary school at the time, I don't think they were reading a lot of Python!)

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.

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.

Ruby has map, filter, reduce and a bunch of other functional methods. It's more about the consistency of wondering what's a function versus what's a method and then things like list comprehensions and for loops. Python also doesn't have a lot of the goodies of a real functional language, it encourages for loops and seems to be even more procedural than Ruby but less OO?

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.

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.

> still seems inconsistent to me (putting the function before the array)

I'm experienced in ruby, and learning python for a project. I don't think I'll ever not wince when using python's ternary;

ruby: size = (waist > 30) ? 'large' : 'small'

python: size = 'large' if (waist > 30) else 'small'

I've always assumed this was to maintain syntactic consistency with comprehensions like [x for x in arr if x > 2].

You're splitting hairs about what the op said. How about len() ?

[1,2,3].__len__()

Yes, Python is all OO under the hood just like Ruby but ugly as sin.

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.

Which is ironic, given that "There should be one-- and preferably only one --obvious way to do it" is in PEP 20.

The vast majority of Python code that I have had to interact with professionally seems to ignore the fact that PEP even exists.

I agree. This has always driven me crazy. Python is supposed to be “there’s one way to do it” but I find it quite inconsistent!

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.

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__.

> Even Haskell has dot notation to chain functions since it's just so much easier to read and write...

Are you referring to function composition?

This is what really put me off Python as somebody who learned Ruby as their first proper (professional 9-5 usage) programming language.

There are other things too, like how print used to be written like a keyword not a function for some reason, and enforced indentation instead of braces or "end" keywords, all just really bugged me. It felt like somebody made YAML Turing complete...

Really depends on what you mean by "simple". "Simple" is one of those descriptors that gets tossed around a lot in programming by rarely with a clear definition.

Python is a "simpler" language with its preference for "one obvious way", and it does tend to support fewer paradigms than Ruby. Ruby is a more complex language, supporting many approaches. But if you are familiar with the various approaches, that can be "simpler" if it allows you to choose the most fitting approach for whatever problem you have at hand.

To put it another way, "simple" can mean "the language is small/has an obvious way it wants you to do things", or "simple" can mean "the language is flexible enough to be used to model your problem in the most appropriate way". Python is the first kind of simple, Ruby is the second.

IMHO Ruby is much more expressive than Python, and the stdlib is better designed and less crufty. Ruby really has one of the best stdlibs around, I think, and a lot of languages could learn a lot from it - particularly the design of `Enumerable`.

So I prefer Ruby when I have the choice. Part of that is probably just familiarity, but I've been a full time dev on both Ruby & Python projects for long stretches of time so I think I'm in a decent position to compare them. My personal preferences/taste is another aspect, of course, and there's no objective accounting for that.

The case where I often will prefer Python is if I'm scripting something that needs some degree of portability. If you pick a random Linux box it's much more likely to have some version of Python installed than Ruby, so if I'm writing something that should be easy to copy to a box and use without additional setup, I'm more likely to pick Python.

Personally I think writing Python is like writing maths, writing Ruby is like writing English.

Depends which one you prefer.

Whether or not it is true, that would certainly explain why I prefer Ruby so strongly over Python.

Having done both professionally, I'll take Python any day of the week. The "Expressivity" lauded by Ruby fans translates into a lack of readability. But the things that drives me crazy is the optional/alternative syntax of ruby.

Ruby is a lot like spoken language in that regard. When the many ways in which to do things are chosen well, Ruby reads like pure poetry. For that I will always enjoy Ruby.

Moreover, the choice of which idiom to use conveys the intent and mindset of the author.

But like any complex language, it's also possible to write very unpoetically, and like any complex language, readability is a function of familiarity with the language's syntax and idioms.

Ruby has the ability to automatically download required gems in single-file scripts via bundler. I don't know of any equally convenient alternative for my python scripts.

e.g. https://gist.github.com/destiny-index/2a2e7e586bb9cd6e5c3000...

They are surprisingly different.

Ruby has a focus on developer joy and productivity. In some cases this comes to the detriment of language simplicity, and existing features can complicate language evolution.

Surprisingly with this complexity Ruby has had a bit more success with optimized implementations than Python, such as Truffle Ruby.

Ruby is a bit more multi-paradigm than Python IMHO, and has been jokingly called a "language for connecting adults". One can monkey-patch override division to return fractions, with the person maintaining the project deciding if this is a good idea or not. This can potentially make projects with a large number of dependencies harder to debug, which interestingly seems to have created some push-back on importing lots of arbitrary dependencies.

With both Python and Ruby, you wind up having divisions between dependencies because of the poor mismatch between different paradigms - for instance, libraries built to work with Python Twisted or Ruby EventMachine for I/O, or libraries built to work generically or to integrate into say Django on Python's side or Rails on Ruby's side.

Interestingly the communities seem to have different key focus areas - Ruby has historically been very focused on testing (cucumber and selenium for instance) while Python has had a lot of focus on documentation (pydoc and sphinx). Oddly, neither really has had a noticeable literate programming push.

Is "language for connecting adults" an autocorrect of "language for consenting adults"?

Hah yes it was

Python forces you to wrestle with its'/Guido's idiosyncracies. It wears them on its sleeve almost like a badge of honor. You may enjoy them, but I don't. Lack of Tail Call Optimization is a huge red mark for me, personally.

Ruby, on the other hand, is literally meant to delight you with its choices/options/expressiveness and I find that it absolutely delivers on that promise.

Python is entirely unreadable to me. Not in the sense that I can't but in the sense that I have to put effort into it in a way I don't have to with Ruby. Part of it is undoubtedly that I'm very picky about syntax and formatting and Python has made a lot of choices that are pretty much the opposite of what I want, but I just can't get used to reading Python code.

i write python for a living (and have done so for the last five years) but i still find ruby fits my brain better, and it's what i reach for when i want to write a quick script for some personal use.

Even if you would rate the languages themselves equal to one another. The ecosystem of Python is several orders of magnitude larger. Anything you want to do has a python module or an example. I think the real question is, is it really worth giving up all that for two minor improvements in syntax.

As a Rails dev it's extremely rare for me to need some functionality that Ruby doesn't cover. If you're doing standard web development most likely you're gonna be fine with Ruby. I've been doing this with Ruby for around 8 years so I bumped into quite a few use cases...there are gems for all the standard things.

But yes outside web - data science, web crawlers etc...Python has the clear advantage.

I'm having a blast nowadays with Laravel. After many years of building microservices and SPAs, I just can't believe how easy and refreshing everything is coming back to a "monolith". Yes, there's some spaghetti some times on certains parts, but I can just refactor stuff, create a PR, and easily improve the situation for me and my coworkers.

At my previous company you could only "touch" your own service, so once there was any kind of "architecture spaghetti"... good luck fixing that across 3 ~ 4 different services... and good luck aligning 3 ~ 4 teams priorities to fix it.

Reply on news.ycombinator.com