20 ms·

To Ruby from Python

210 points by mariuz 4y ago

nixpulvis 4y ago
> The usual-style comments on the line(s) above things (instead of docstrings below them) are used for generating docs. This is another thing about Python that I find very unsettling and wrong.
boberoni 4y ago
> Unlike Python, in Ruby… There are a number of shortcuts that, although give you more to remember, you quickly learn. They tend to make Ruby fun and very productive. I use Python, but have never tried Ruby. The ecosystem for Python packaging is so chaotic that I’ve considered switching. Any Pythonistas/Rubyists here that could point out some Ruby shortcuts that make you more productive?
- z9znz 4y ago
  Here's a rough list of benefits of Ruby compared to Python. It's not well organized and the examples are difficult to show in a comment box, but I have pages of notes of why Python is frankly a horrible language compared to Ruby. Every expression returns a value, so you can assign the result of an if/else or switch statement to a variable. Within your conditional clauses, you don't have to repeat assignments or return values. If the logic goes down that branch, then the last value in that block is the return value. This also means you don't have to have explicit 'return' statements in functions. Whatever the last value of the last expression is, that's your function return value. You can use an explicit return if you want to exit the function early, however. Ruby has a switch (case/when) statement. Python finally has this in 3.11 I believe, but it took forever to get. Hash.dig(). If you have nested hashes (dicts), you can myhash.dig(:top_key, :lower_key, :even_lower_key) In objects, you can control which attributes can be read/written via attr_reader, attr_writer, attr_accessor. So you can make an attribute have a default getter if you use attr_reader :some_attribute, and then you can write your own setter if you want to control how it gets assigned to. You can even simply not have a setter, so you can effectively make an attribute read-only. Clean, simple hash initializers: h = Hash.new { |h, k| h[k] = { age: 0, nickname: k } }. So now you can just start assigning to values in h like h["bob"][:attr1] = 28, and now h["bob"] refers to a hash with age 28 and nickname "bob". Yes Python has defaultdict, but it's an extra thing you have to use, and it's clumsy compared to the Ruby approach. Hash (dict) merging: It's a mess in Python. In ruby it's just h1.merge(h2), or even h1.merge(key_to_update: 123). And you get a new hash as the result. Or you can merge in place with merge!(), changing the original. Function names with ! and ? greatly simplify function naming (and improve readability). So instead of is_foo(), you just have foo?(). And if you want to indicate that you are doing something destructive, you name it foo!(). This is a common pattern in Ruby libraries, and you often have functions which return a new value and functions with the same name followed by ! which modify the input value. String.strip() returns a new string without leading/trailing whitespace, while strip!() modifies the input string to the same effect. Python's list comprehensions are arguably ugly and messy and harder to visually parse when reading. Ruby has consistent ways of doing operations on collections. This would take a full page to show examples. Copying and pasting code in Python often results in new code which is indented wrong (in the wrong scope), and which you must manually fix. This is not a problem in Ruby, since there are actual 'end' statements. Editors know how to properly indent what you paste. Safe navigation. myobj&.someattr&.foo will give you the value of foo or nil if myobj or someattr don't exist. You have to use ifs to do this in Python. Array flattening. nested_arrays.flatten(). But in python, you have to use something like list(itertools.chain(*arr)), but that fails if the first element of the list is an int (not an iterable). Gettings hash/dict keys. In Ruby, you just do myhash.keys and you're done. But in Python there are several ways to get the keys, none of which is as simple and obvious as just keys(). Not allowing typos to silently fail. With Python, you can take an object and assign a value to a non-existent attribute. You might do this accidentally if you have a typo when trying to set an actual attribute: myobj.first_Name = "bob". Python will happily do that, and you'll later debug and wonder why myobj.first_name == "" (and then notice that you have this similarly named attribute now called first_Name). Duh. I guess you could say it's convenient to be able to do this, but it's more a footgun. Ruby will bark at you if you try this. List sorting in Python is in-place, so you can't non-destructively sort and get the sorted list returned. In Ruby you have a choice. sort() is non destructive, and sort!() is in-place. I've got more, but this is enough.
  - maligree 4y ago
    Using the sorted() built-in returns a new sorted array. Getting keys from a dictionary is literally just calling dict.keys(). Sorry, but I don't think you've used Python enough to offer lists like these.
    - z9znz 4y ago
      I stand corrected on the mylist.sort() vs sorted(mylist). But really, such a mistake is more likely with two very different ways of doing the same kind of operation. In ruby you would just mylist.sort() for a new sorted list (although parens are optional if no arguments, but I show them), or mylist.sort!() to sort mylist in place. You don't have to know two very different things. Plus it's obvious with the ! > Getting keys from a dictionary is literally just calling dict.keys() Nope. Unless your definition of "keys" is a 'dict_keys' class. Chances are really good that what you wanted was a list of keys, not some object which does not behave exactly like a list. If you want to access the keys by index, you can't do it like mydict.keys()[0] because dict_keys does not have an index method. Oddly, if you want a list of keys of a dict in Python, you just do list(mydict). But you can also do [*mydict], which gives you a list of keys but is something special you have to learn. Here's a fun one. Give me the first key of a dict. Ruby: mydict.keys.first Python: (several ways) next(iter(mydict)) # which makes no sense at all... asking for the next value of something when you're actually asking for the first. list(mydict)[0] [*mydict][0] What if you want the values of the dict? Well, no surprise, Python gives you a dict_values object when you do mydict.values(). Likewise, you can't do listy things with that because it's not a list. You have to convert it to a list with list(mydict.values()). Or you can do the [*mydict.values()] thing. Python is full of so many inconsistencies, the cognitive overhead is much higher than it needs to be. I would argue that it makes people dumber, because they have to waste mental energy learning weird things for special cases. But what about the rest of my previous post list? Here's one I left out. The return-early pattern is common in imperative programming. We like to exit a function as soon as we know things aren't going a certain way. In Ruby: x = fetch_object("bob") or return "bob not found" In Python you need 2 or 3 lines (2 if you're using the walrus := operator). if (x := fetch_object("bob") is None): return "bob not found" How about setting a value for a variable if it is unset? This is a common thing done when you have variable arguments Ruby: x ||= "default" Python: x = x or "default" # not only does it look stupid setting a thing to itself, but it will fail if x is zero. Edit: fixed asterisks.
- batiste 4y ago
  It really doesn't... After years using Ruby my mind never managed to parse its complicated grammar.
  - travbrack 4y ago
    Any examples? I always found it easy to grok but I'm not at a very high level so I'm curious where it gets hairy.
    - cycomachead 4y ago
      There's a bunch of things to pay attention to in Ruby. I wouldn't say these get too hairy, but they trip students up for very understandable reasons. * `a ||= b` is not just `a = a || b`, but `a || a = b` * The distinction between defaults arguments and hash arguments in functional signatures has many edge cases -- but it's much much better in Ruby 3. * There are still 2 pieces of syntax for hashes (`{a: 1}` and `{:a => 1}`) They are the same. * Curly bases show up a fair bit for a language that's not a braces language. :) They're in hashes, blocks, and % strings. e.g. `%w{a b c}` is the same as `%w|a b c|`. They're also used in string interpolation, e.g. `"Hello, #{name}"`. * There are sometimes many ways to do the same thing. There's Procs, blocks, and lambdas. % strings work with many characters. * `unless` for `if not...` and get wonky. * Overusing "surprise if" e.g. `do_thing if other_thing` can be hard to read. * It's so easy to monkey-patch and extend primitive classes, you might not realize when libraries do it. All of these are features that I actually find nice to use in the right contexts. But they can pop up when you don't expect, and they can definitely make Ruby a challenge to learn. That said with a little discipline (or just a linter ;)), I find a lot of Ruby code a joy to read and write.
      - IshKebab 4y ago
        > `do_thing if other_thing` Yeah I don't get why you would deliberately make the flow control confusing and backwards like that. Python list comprehensions are the same. They make the information flow backwards. This also has the effect of making nesting really confusing.
- Hamuko 4y ago
  You should probably try some 10-minute Ruby tutorial to see if the syntax doesn't completely scare you off.
  - Gordonjcp 4y ago
    When I looked at Ruby (admittedly a long time ago now) everything was 10 minute videos. Is there any actual useful material on it now?
    - regularfry 4y ago
      The default guide for a long time was the Pickaxe book, which solidly pre-dates the availability of 10-minute videos by several years. There are a fair few links here that you might find useful: https://www.ruby-lang.org/en/documentation/ https://www.ruby-lang.org/en/documentation/
    - nomilk 4y ago
      There's ~50 short exercises/lessons here: https://learnrubythehardway.org/book/ https://learnrubythehardway.org/book/ I did them when I started out, and occasionally revisit as a refresher. It doesn't teach everything in ruby, but it absolutely gives enough to do just about anything you could want.
- cycomachead 4y ago
  More productive is really hard to say... But I personally prefer Ruby to Python. For smallish scripts, I really like Ruby's backticks for easily executing shell commands. And I find the metaprogramming support in Ruby great for some tasks. I'm not sure if that's what you're getting at. But especially with "modern" Python features like f-strings and the walrus operator there's not tons of differences that really stand out as "productivity". One thing to just remember: Ruby is not just the Ruby on Rails community. Rails is a dominate space, but it's not the only thing out there. At the same time, when it comes to scientific computing, ML, etc. the Python ecosystem is incredibly robust. There's plenty of awesome Ruby tools for these things too, but it is not the same. Ruby and Python are the two languages I primarily teach courses in, and used professionally. Ruby is my cup of tea personally, but they're both modern dynamic interpreted languages.
  - ptx 4y ago
    > For smallish scripts, I really like Ruby's backticks for easily executing shell commands. Executing external commands is pretty convenient in Python these days, now that we have subprocess.run [1], and passing the command as a list rather than through the shell seems a lot safer. Doesn't backticks open up the classic command injection issues (i.e. the same kind problem as SQL injection with non-parameterized queries) unless you're extremely careful to manually apply proper quoting in every single case? [1] https://docs.python.org/3/library/subprocess.html#subprocess.run https://docs.python.org/3/library/subprocess.html#subprocess...
    - noirbot 4y ago
      It would, but most of the time when I'm using backticks, it's because I'm writing myself/my team a little helper script that will never get "injected" with anything. Backticks (and the other more featured ways of doing shell commands in ruby) make it really easy to write what amounts to a Bash script, but with a little more features and readability, or pull in some relevant libraries for some more complex task that would be annoying to do in pure Bash.
      - ptx 4y ago
- oezi 4y ago
  I think with "shortcuts" they mean things such as $1 (first match group of a regex) or =~ (regex match operator). I general I rarely feel like I am unproductive in Ruby (or bogged down in boilerplate typing).
  - cycomachead 4y ago
    In that case -- I definitely agree Ruby usually gets out of way. It's often my go to for hacking on something, unless it's data science-y. I'll mention: implicit returns, return if, and safe navigation, the &. operator. Ruby's newer pattern matching features are really cool[1], especially for things like JSON structures, but I've only use started using them. Classes are also super easy to extend. Many of these things are also incredibly easy to abuse - but they have their places. [1]: https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rdoc.html https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rd...
- transfire 4y ago
  I’m not sure what “shortcuts” the author is referring, but perhaps… x = y || z # if y is falsy x = z x = f ? y : z # ternary operator %w{one two three} # array of words And so on.
  - endorphine 4y ago
    Also: x ||= 1 x &&= 1 and the various built-in methods from Array, Hash, Enumerable, String etc.
  - intuxikated 4y ago
    These all exist in python, though you use or/and instead x = y or z x = f and y or z you can also use inline if/else x = y if f else z 3rd one just seems like an array of strings? ["One", "two", "three"] Not needing quotes for single words saves some typing tho.
    - deleted 4y ago
      [deleted]
- pmontra 4y ago
  I loathe most shortcuts: too many things to remember and usually cryptic syntax. Maybe that's because I have to be a polyglot developer (Elixir, JavaScript, Ruby, Python) and I can't remember all the tiny details of each language. If you want to give a try to Ruby, get to understand blocks quickly. Instead of for item in list: work_on(item) which would work (with a closing end and no : ), the idiomatic way is list.each do |item| work_on(item) end or the one liner list.each {|item| work_on(item)} Check also map, select, each_with_index, each_with_object, etc. Blocks are fundamental to Ruby for reason that only practice can tell.
  - greenpeas 4y ago
    Or with numbered parameters (since ruby 3.0) list.each { work_on(_1) }
    - pmontra 4y ago
      Which is exactly the kind of shortcut I loathe.
      - greenpeas 4y ago
        you're not alone :) https://bugs.ruby-lang.org/issues/15723 https://bugs.ruby-lang.org/issues/15723 This syntax looks ugly, but it's really nice when writing short scripts. Combined with one line function declarations: `def foo(n)= bar`, it can make an irb session much faster/shorter.
    - BiteCode_dev 4y ago
      Swift has this as well, and it's really nice. Doing map(lambda x: x + 1, stuff) or [x + 1 for x in stuff] adds nothing of value for those very simple cases. I wish we had map($1 + 1, stuff), or ever better, stuff |> $1 + 1. Python does a lot of things right, but for a language with a strong emphasis on the iterator design pattern, I wish it would provide more expressive primitives. However, it comes with the FP territory, which Python is not well suited for, and it would also imply a higher cost of entry to beginners.
    - 4y ago
- shaicoleman 4y ago
  There are thousands of little things that make Ruby nice. They all add up to a more enjoyable experience. I'll give you one tiny example: Python: from datetime import date if date.today().weekday() == 5: print("It's Saturday") Ruby: require 'date' puts "It's Saturday" if Date.today.saturday?
  - ouija 4y ago
    I prefer the Python code here. The import is explicit, so if you want to know where "date" comes from, that's easy. In a modern IDE I don't write imports manually anyway. You could write it as a one-liner in Python as well, but I would prefer not to. print("It's Saturday") if date.today().weekday() == 5 else None That the Python library doesn't define constants for days is unfortunate, but not a limitation of the language.
    - petepete 4y ago
      Why do I need to remember that Saturday is 5?
      - greenpeas 4y ago
        S looks like 5 if you squint. not hard to remember
        jjgreen 4y ago
        So Sunday?
        greenpeas 4y ago
        No! Sunday is 6 because "Sunday" has 6 letters.
        jjgreen 4y ago
        That's it, I'm switching to Python!
- bsaul 4y ago
  From what i've seen ruby is definitely on the downward slope regarding adoption and python has become a defacto standard in some fields. Its ecosystem is much better in pretty much every domain, so i don't think there's any point switching at the moment, honestly.
  - jillesvangurp 4y ago
    I've used both. I slightly prefer python over ruby. But I haven't used either recently. Ruby's strength is internal DSLs. Python's strength is that it's simple to pick up for people. There's a large community of people that are not primarily programmers that use it. The reason for this is that it is a very easy language to get started with. Both share the same problem: they are weakly typed scripting languages. Both have in common that type annotations have been retrofitted to the language. But it's an uncomfortable and awkward retrofit in both cases and their respective communities seem to regard using types as an optional and inconvenient thing. Ruby with types of course exists. E.g. Crystal is nice apparently. But I've not really seen that used in the wild. Python is enormously popular; ruby's popularity seems to have declined a lot. I know a lot of former Ruby programmers that have moved to different languages and only a handful that still use it. It's not an obvious language to pick up for younger programmers. There are so many other languages to choose instead. IMHO the key innovation in language design in recent years has been type inference. This has lead to a new breed of languages that keep most of what made python and ruby popular: the ability to write code with a minimum of verbosity but without sacrificing type safety. Whether you use Kotlin, Typescript, C#, or even Java: they have type inference now and it reduces the verbosity that comes with having types. Scripting vs. compiled languages is much murkier these days where scripting languages have compilers or transpilers and linters and compiled languages have REPLs and all languages can now run in a browser via WASM anyway. The distinction is just not that relevant anymore. I write a lot of Kotlin, have dabbled a bit with typescript and I don't think I'll ever use languages without proper types again. Just not worth it for me. I don't see the value of not having a good typing system. Kotlin is interesting to me because internal DSLs are a thing with it; just like they were a thing with Ruby. And it can use javascript as a compilation target. Ruby has a slightly nicer syntax for DSLs than Kotlin for internal DSLs. But I don't mind curly braces and having strong typing enables a lot of good stuff. Like proper IDEs with refactoring, autocompletion, auto-fixes, etc. which are all very nice things to have in a DSL. I use Kotlin DSLs for writing CSS, HTML components (we use kotlin-js), writing elasticsearch queries (I maintain the multi-platform kt-search library), gradle build files (which uses kotlin script), and quite a few more things. IMHO, it could do a lot of things that python is popular for as well.
- davidthewatson 4y ago
  I've been using python for two decades and ruby exactly one decade ago for a couple years. Your comment on packaging is interesting. My perspective is that packaging on ruby was in nearly the same state ten years ago as python is now. My team switched ruby package managers several times during the ruby work and none of them ever worked reliably and was a regular root cause of fragility in our builds. I hope that ruby packaging has settled in that time while python has the same kind of cultural noise that afflicted ruby during that period. Popularity has downsides. Political packaging wars is one of them. I'm old school enough that I stick with tried and true pip, venv, and .env and its ilk. There was a long battle in downstream packaging for a while that I just didn't want to be involved in having seen the same thing in ruby. FWIW, if I were you I'd look at crystal, elixir, or nim. I was very productive in ruby but the near constant battle of wrestling with DSL's that are not concomitant with their parent is, IMHO, to be avoided. I've seen more than one team fall prey to that trap. Caveat emptor - pick your DSL's carefully.
  - kawsper 4y ago
    What do you mean by switching packaging managers? Ruby uses Rubygems and Bundler to manage packages. Are you referring to Ruby version managers that manages different versions of Ruby (rbenv, rvm, asdf, etc.)?
    - ByteJockey 4y ago
      They mention doing this a decade ago. They were probably using utilities to manage downloads from the ruby application archive (which would have still been around at the time) and automate running `setup.rb`
      - davidthewatson 4y ago
        Yes, all of the above. Sorry for the unclear language. At the time, I recall it being very distracting when the team was focused on shipping well-tested code. We had a world class devops guy, but we all ran into these build issues frequently enough that it was a regular complaint at retrospectives no matter what tooling we were using at the time or who was using it. It was not long after this that I read Daniel Greenfeld's book on Django that introduced the notion of "vanilla django" and that resonated with me, precisely because our rails tooling was decidedly not vanilla. My take now is that rails can have the same problems with regard to being "off the rails" WRT the aforementioned DSL's and such. I don't think the root cause is ruby as much as there are pockets of rails that are far from what DHH describes.
- nickjj 4y ago
  > Any Pythonistas/Rubyists here that could point out some Ruby shortcuts that make you more productive? It depends on what you want to do. If it's building web apps there's Ruby on Rails, which is written in Ruby. In my opinion there's no alternative to this in Python. Sure there's Django but it's not the same even though both are considered batteries included web frameworks. One nice thing is you'll find both Python and Ruby SDKs for a ton of third party services (like Stripe, etc.). That goes a long ways for building things quickly and with confidence. Ruby's package manager is also a lot better IMO. It supports proper lock files out of the box and everyone uses gems with bundler. In Python it's a mix of pip, pipenv, poetry, etc. all of which have their own unique issues. With Ruby I never felt like I had to battle this aspect of the language. You just bundle install what you want and creating gems is the same process.
  - lloeki 4y ago
    If one wants to get into Ruby, please stay away from Rails as a first step into Ruby-land. Look into Rack and Sinatra first, then Rails. Even if it's a short trip it's going to be worth it.
    - Lio 4y ago
      This is personal opinion but these days I'd probably swap Sinatra for Roda[1] for small API services. It's generally faster, uses less memory and is a really good example of well written ruby code, IMHO. I also really like Jeremy Evans' book, Polished Ruby. 1. http://roda.jeremyevans.net/index.html http://roda.jeremyevans.net/index.html 2. https://www.packtpub.com/product/polished-ruby-programming/9781801072724 https://www.packtpub.com/product/polished-ruby-programming/9...
  - MatthiasPortzel 4y ago
    > Sure there's Django but it's not the same Could you elaborate on this? I’ve used both Django and Rails and in my mind they’re direct parallels to each other. For example: in Rails you write migrations and then it generates a schema.rb, and in Django you update your model schema and then it generates migrations. They have very different philosophies, sure (reading the Rails manifesto made that clear), but from a technical standpoint they have pretty good feature parity.
- AnthonBerg 4y ago
  I like the RubyMine IDE a lot. The code intelligence is very good – it’s so good that it tends to teach you Ruby as you use it. Code intelligence as in code navigation, easy access to documentation on the fly, refactoring, code style suggestions. The same goes for the tooling integration. It works with most of the development tools you’d use with Ruby and captures the integration pretty well in a UI and associated workflow. Link for your convenience: https://www.jetbrains.com/ruby/ https://www.jetbrains.com/ruby/ (No affilition except being a paying user.)
  - gls2ro 4y ago
    I am using both Vim and RubyMine and I strongly recommend RubyMine for anyone starting with Ruby. Having the possibility to have a Go to definition for almost any method is great and most of the gems have great code comments with a lot of nice examples. When I teach people to learn Ruby (I do this sometimes) among the first things I do is I explain to them how to open a gem, look at the source code, read it and then try to use it. I cannot thank enough the maintainers of the most popular gems for doing such a great job in having great ruby code and good in-file documentation.
scotty79 4y ago
For me there wasn't ever question of "How?" only "Why?". One time I landed on Ruby project and I didn't have any trouble fixing bugs and implementing minor functionalities without really learning Ruby only knowing some Python.
- cortesoft 4y ago
  I feel similarly about python. I use ruby all the time, but can do things in Python just fine, especially if I have an existing code base that I am working on.
  - scotty79 4y ago
    Tensorflow? Numpy? No idea what else might be the reasons to learn Python when you know Ruby.
    - cortesoft 4y ago
      Because there is a lot of Python code at my work.
deleted 4y ago
[deleted]
ptx 4y ago
> You can read docs on the command line (with the ri command instead of pydoc). I've been using Python for a long time, but somehow I never learned about pydoc. It looks like a pretty handy tool!
helge9210 4y ago
On the surface, Ruby and Python are mostly equivalent languages. Internally, memory management is done differently, for example. Now add a magic of Ruby on Rails and ActiveSupport to one side and machine learning toolsets to the other.
- viraptor 4y ago
  Not just on the surface. See the ruby to python bytecode compiler: https://github.com/whymirror/unholy https://github.com/whymirror/unholy
DonHopkins 4y ago
“Python is bash for mathematicians.” -Michael Slavitch
- BiteCode_dev 4y ago
  Python is used for Web dev (Django), geography (all SIG), system components (part of Unix), pen testing (E.G: scapy), 3d modeling (Blender), sysadmin (ansible), etc. I've been coded mostly in Python for 15 years and using the scientific stack is a very small parts of what people pay me of, if they ever do.
  - DonHopkins 4y ago
    You're misinterpreting that quote as criticism of Python instead of praise. He's not saying that's the ONLY thing that Python is good for. I've also been programming in Python extensively for at least 20 years, including web application servers like Zope and TurboGears, embedding and extending apps and tools with the Python/C API and SWIG like SimCity, Gnu Radio, Big World MMPORG, robotics, simulations, Blender, Houdini, user interfaces like Tkinter and PyGTK and Sugar, XML processing, OLE integration, BeautifulSoup web page scraping, image processing, character animation, speech synthesis, system administration, infrastructure as code, machine learning, etc. Python is of my primary programming languages, and I love it. It's a GOOD thing that mathematicians use Python instead of Bash!
    - BiteCode_dev 4y ago
      Mathematicians never used bash. Most of them didn't even touched the command line 10 years ago. I'm not the one misinterpreting.
      - DonHopkins 4y ago
        It's pretty clear and not subject to interpretation that I never claimed mathematicians ever used bash, but just the opposite: they use Python instead. Bash is an easy way to plug other code together, but it's terrible for math. Python is a much better way to plug other code together, and it's much better at math.
zem 4y ago
as someone who has used ruby for years, and more recently got a job working in python, I think the most significant difference between the two languages is how they handle imports. in python every file is also a module, and all imported symbols are namespaced within that module (unless you deliberately use "import *" to bring them into the current module's namespace). so you can define function foo in module bar and use it via "import bar; foo.bar()". in ruby, modules/namespaces and files are two entirely orthogonal concepts; you define a module by enclosing code in a "module Foo; ...; end" block, and any file can open up the same module and add stuff to it. when you import a file it adds everything within it to the current global namespace, which makes it really hard to read a piece of ruby code and see where everything within it was defined. for the most part where ruby and python differ I prefer the ruby way, but I feel like automatically namespaced imports is something python got right, and was a really big miss for ruby.
- typeofhuman 4y ago
  > so you can define function foo in module bar and use it via "import bar; foo.bar()". Wouldn't this be "import bar; bar.foo()"?
  - 86J8oyZv 4y ago
    In Ruby it’s “require” rather than “import.” But it would be more like “require bar; foo()”. However, Ruby does have auto-loading conventions. So you could define “module Baz{ module Bar { def foo end; } }” in “baz/bar.rb” from the root of your project. You should then be able to call “Baz::Bar::foo()” from any other file in your project structure without a “require” at all. This is not standard Ruby IIRC, but Rails and other frameworks use it.
    - gls2ro 4y ago
      There is a gem that does that used by Rails and multiple other gems: https://github.com/fxn/zeitwerk https://github.com/fxn/zeitwerk It is pretty easy to set it up in any Ruby project.
    - 4y ago
vault 4y ago
deleted
- greenpeas 4y ago
  What do you mean? > When tested for truth, only false and nil evaluate to a false value. Everything else is true (including 0, 0.0, "", and []). In ruby only `false` and `nil` evaluate to false values. 0, [], "" all evaluate to true when used in `if` statements. In python (just like in C and JS) many things evaluate to false (including 0, 0.0, "", and []).
  - vault 4y ago
    Ah sorry I read "Unlike Ruby, in Python" instead of "Unlike Python, in Ruby"
thih9 4y ago
This page is old [1], is there any reason or context regarding why it is interesting now? [1]: Archived in 2006: https://web.archive.org/web/20060925032432/https://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-python/ https://web.archive.org/web/20060925032432/https://www.ruby-...
- Kwpolska 4y ago
  The page has been slightly changed since then, but it is still quite outdated. Python 3.6 (2016) has formatted strings, and new/old-style classes thing isn’t relevant at all since Python 3, but wasn’t that much of a deal with Python 2 at the end of its lifetime (~everything was new-style by then).
  - sitkack 4y ago
    Ruby is a neat language that I don’t know very well. Blocks are nice. The pattern matching in Python 3.10 compels me to stay.
    - weaksauce 4y ago
      ruby has some nice pattern matching too https://rubyreferences.github.io/rubyref/language/pattern-matching.html https://rubyreferences.github.io/rubyref/language/pattern-ma... not sure if python has better matching though but the ruby stuff is pretty compelling.
wodenokoto 4y ago
> There’s only one kind of list container (an Array), and it’s mutable. What are the other kinds of list containers in Python? I only know of `list()`/`[]`, but maybe I just don’t realize that some other thing I use is also a list container.
- uranusjr 4y ago
  I’m guessing they’re implying tuple, it’s pretty common to consider that type as “immutable list” (although personally I very much dislike this categorisation)
  - masklinn 4y ago
    > although personally I very much dislike this categorisation It’s not a categorisation, it’s literally the nature of the thing in Python. And while I agree that it’s distasteful the error was in the original introduction. As things are, python tuples are immutable sequences with all that implies. They are iterable, indexable, sliceable, …
    - baq 4y ago
      Immutability crucially allows for hashability, so you can use (some) tuples as dict keys.
- kevin_thibedeau 4y ago
  array.array
- zbentley 4y ago
  array.array, as another commenter mentioned; numpy.array is popular for performance-oriented code (but not in the stdlib); collections.deque; queue.Queue; tuple; struct (though it's a bit of a pain to make one behave in an array-like way and is usually better to use array.array); heapq; and multiprocessing.shared_memory.ShareableList. Out in pypi there are many additional esoteric list-like data structures: bitarray is one of my favorites, and there's also awkward-array, cyarray, tinyarray, fixedlist, blist, bigarray, sortedcontainers, and many many more.
mahathu 4y ago
I love Python and use it pretty much anywhere I can, especially as it's ubiquitous in scientific computing. Is there a good reason to switch to Ruby except to try something new?
- nixpulvis 4y ago
  I would claim that Ruby as a language is much nicer to use, however it has less support for data science and other things which Python is much more well known for. If you ported over some libraries, you might find you like Ruby more in the end.
  - doix 4y ago
    My biggest gripe with Ruby is how much syntax is optional and the "accepted" conventions by the community are to leave out a lot of optional syntax. The worst offender (in my opinion of course) is leaving out of empty parentheses on method calls. It makes it impossible to know if something is a property or a function. The argument is that it doesn't matter if it's a property or a function, but I feel like it makes it very difficult to reason about performance. If I know something is a function, I'll look at the function and see what the performance implications are. Where as if something is a property, I assume it's "free" to access. This doesn't hold when reading Ruby code, and I basically have to look up everything all the time. Just my opinion as someone that had to switch between python/ruby/perl to maintain tools written during different decades.
    - nixpulvis 4y ago
      Always use parens. That's my rule.
    - floodedchip 4y ago
      What do you mean by “property or function”, though? There are no properties or functions in my view—only messages. object.message sends message to object, which object may or may respond to.
      - 4y ago
winstonsmith 4y ago
>[In Ruby] There is good support for functional programming with first-class functions, anonymous functions, and closures. This seems like a blatantly false claim to me since as a Python programmer forced to use Ruby for Sketchup, I have been frustrated by the lack of first-class functions in Ruby.
- tomstuart 4y ago
  I’m interested to learn what “first-class functions” means to you. Ruby has both `Proc` and `Method` which would appear to qualify. Is your frustration that you can’t `def foo … end` and then use bare `foo` to refer to it as a value (vs invoking it)?
  - winstonsmith 4y ago
    My frustration is that you can't pass foo as an argument to another function.
    - tomstuart 4y ago
      Right, I see, because you have to say `method(:foo)` or `-> { foo }` or whatever. To me this is an acceptable syntactic trade-off in exchange for being able to invoke the method with bare `foo` (i.e. variable reads and method calls look the same) but I can see from other comments here that some people dislike that ability anyway. Vive la différence!
    - chrisseaton 4y ago
      But you can. Method objects, proc objects, lambda objects, blocks, you've got a wealth of options here in Ruby.
sinsterizme 4y ago
This is very good timing for me, I just left my python dev job and am starting a job where they use Ruby. I’m very excited to be using Ruby again, it’s a much nicer language to use for a variety of reasons I can’t possibly enumerate. Ruby’s stdlib and surrounding documentation is pristine, I vividly remember being appalled when trying Python for the first time and thinking where the rest of it was. The major issue I find with Ruby (and that I saw mentioned elsewhere in this thread) are imports / requires, which is much too magical in Ruby; Python’s import is way saner
- fny 4y ago
  Ruby's imports aren't magical by default. Autoloading frameworks make them so.
  - khaledh 4y ago
    The fact that ruby makes this possible means the community will take advantage of it, to the point of abusing it sometimes. This hurts understandability of the code base. Too many times I would open a ruby code base and spend significant amount of time tracing where things are defined (mostly relying on suboptimal searching) because of the lack of explicit imports/requires.
    - ysavir 4y ago
      An easy way to do that is to use the Pry gem. If you're in a pry console, you can use `show-method Thing.foo` and it will show you the method, which file and line it's defined in, etc. Pry is a great tool and this feature makes is a blessing.
    - Spivak 4y ago
      Python can do this magic too and the community hasn’t abused it. Every part of modules and module loading is swappble, mutable to the point where modules can be arbitrary classes if you want. It would be 2/10 difficulty to add transparent module autoloading to Python because you can just hook into module loading and arbitrarily modify or replace the module objects. You wouldn’t even need a courtesy import because the main module is still a module.
lloeki 4y ago
For some reason it reminded me of _why's unholy: https://github.com/devyn/unholy/blob/master/README https://github.com/devyn/unholy/blob/master/README > You know, it's crazy that Python and Ruby fans find themselves battling so much. While syntax is different, this exercise proves how close they are to each other! And, yes, I like Ruby's syntax and can think much better in it, but it would be nice to share libs with Python folk and not have to wait forever for a mythical VM that runs all possible languages.
- tomc1985 4y ago
  That's funny. In a previous job I was the biggest Ruby supporter on a team of Pythonistas. To show them how similar the language was I translated a couple of their scripts from Python to Ruby... it was surprisingly easy and the linecount was about the same
  - teddyh 4y ago
    That is all good and well, but which was easier to read and debug?
    - tomc1985 4y ago
      That really depends on your background... I find Python harder to read than Ruby
      - ShamelessC 4y ago
        > On a team of Pythonistas
mark_l_watson 4y ago
I loved coding in Ruby. I also wrote a Ruby book for Apress, my last book for a major publisher before starting to self publish on leanpub.com/u/markwatson Two factors made me leave Ruby behind: I am somewhat known for Common Lisp, and so CL jobs would come my way. Also, in the last 8 years, a huge amount of my work has been in deep learning and Python wins there. Anyway, Ruby was designed to make programmers happy, and it is a big success at that.
- deleted 4y ago
  [deleted]
- Hackbraten 4y ago
  I tried for many years to be happy with Ruby. Ended up leaving it behind because more often than not, when I revisited a Ruby codebase after a while, Bundler would complain and tell me that I’m supposed to run `bundle install` something, and sure enough, doing just that sent me into a rabbit hole of errors.
  - Taikonerd 4y ago
    If you switched to Python, then you probably traded your `bundle install` errors for `pip install` errors ;-)
    - fny 4y ago
      Pip doesn't do dependency resolution either... I spent a day trying to pin down issues migrating a project from pipenv to poetry because poetry did not agree with pipenvs resolution.
      - neeleshs 4y ago
        AFAIK, pip does dependency resolution, you can disable it via --no-deps https://pip.pypa.io/en/stable/topics/dependency-resolution/ https://pip.pypa.io/en/stable/topics/dependency-resolution/
mountainriver 4y ago
Really the only reason to use Python is ML, but that is the future of everything so….
- goatlover 4y ago
  > Really the only reason to use Python is ML Not the other scientific and statistical libraries? > but that is the future of everything so…. So is fusion and flying cars. Maybe one day AGI will be here, but I doubt we humans will be using Python ML libraries at that point.
  - mountainriver 4y ago
    In the next 5-10 years, ML will likely write most of our code and that will almost certainly come from Python
- x86x87 4y ago
  nah. ML is not the future of everything. in fact I believe that as things are going to evolve ML as we see it today is going to be only a tiny fraction of what is going to be used
  - mountainriver 4y ago
    yeah but the ML of tomorrow will write all of the code
revskill 4y ago
Ruby eventually failed in term of quantity of developers, means OOP will eventually died. It's not Ruby's fault, it's just the failure of OOP in general. My prediction, in about 4 years or more, OOP is just an abandon concept for all programmers.
- tomc1985 4y ago
  So, C++ and Java have just a couple of years of life left?
  - damagednoob 4y ago
    Not too mention C#, Python and for some, Javascript.
    - mypalmike 4y ago
      All doomed. Google and Amazon, for example, will rewrite their many millions of lines of Java and C++ in Haskell by 2026.
- gls2ro 4y ago
  Mind you that (let's say) the modern concept of OOP was invented around second part of 60s (with Simula I think) and I think functional a bit earlier maybe in the beginning of 50s (with LISP I think). Both paradigms have a lot of years of practice and saying that anyone of them will die in 4 years is I think a bit of exaggeration. Why do you think that in 4 years OOP will be abandoned by programmers? What is the basis for your assertion? I think it is more probable that we will have a kind of cross-pollination between these two paradigms with maybe newer languages (or evolving existing languages) to borrow concepts and best practices while still providing the core way to design solutions. This is already happening in smaller scale in multiple languages as far as I see it.
- goatlover 4y ago
  Uh huh. And static typing will replace dynamic for all programmers, functional will replace all uses of imperative, nobody will use whitespace indentation, and all emacs users will switch to vim. Also, every programmer will abandon Windows and macOS for Linux.
by_the_bay 4y ago
One of my biggest complaints about Ruby is that that it’s so much harder to drop into a debugger. In python it’s as easy as import pdb; pdb.set_trace(), but for ruby (at least the versions on our build systems), you need to figure out how to add the dependency for pry/byebug first which is non trivial.
- tomstuart 4y ago
  A fair complaint, but FYI it’s outdated as of Ruby 3.0 (released in 2020) which includes the `debug` gem [0]. So in Ruby 3.0 onwards it’s as easy as `require 'debug'; debugger` just like you want. Hopefully your build systems will upgrade to a newer Ruby before too long. [0] https://stdgems.org/debug/ https://stdgems.org/debug/
bamboozled 4y ago
Forget all of it and use Go :)
- entropie 4y ago
  Probably not a bad advice. Most of the ruby enthusiasts I know from the old days took a deeper dive into go.
  - goatlover 4y ago
    I would think Elixir or Crystal would have been the more natural transistion for Rubyists. Or even Common Lisp. Go's philosophy is very much at odds with Ruby's.
- jonnytran 4y ago
  The only thing I disliked more than moving from Ruby to Python was moving to Go. All the things I love about Ruby are the antithesis of Go.
- x86x87 4y ago
amerine 4y ago
Ruby seems to have cemented itself in my head as one of my favorites. I’ve built a career from it and am eternally grateful.
RomanPushkin 4y ago
If you're learning Ruby, there is a free copy of my book available (CC BY 4.0 license): https://leanpub.com/rubyisforfun/ https://leanpub.com/rubyisforfun/ - English https://leanpub.com/rubyisforfun_ru/ https://leanpub.com/rubyisforfun_ru/ - По-русски (if you found typos, you can update the manuscipt https://github.com/ro31337/rubyisforfun https://github.com/ro31337/rubyisforfun)
jbverschoor 4y ago
I'm missing the best part - In ruby we have an intuitive and extensive standard library
- aendruk 4y ago
  Of all measures to compare by that seems a particularly ill choice. One of the few things I know about Python is its longstanding reputation for having batteries included. (But yes, you can pry Enumerable from my cold, dead hands.)
hawkeyedan 4y ago
Arguments about the “superiority” of Python vs Ruby always sound a bit like arguments about the “superiority” of Italian vs Spanish. If you squint a bit they’re basically the same. (By that simile, Lisp would be Sanskrit?)
- thebigspacefuck 4y ago
  True, but 85 million Italian speakers vs 500 million Spanish speakers so that tells you something. Sure the Roman Empire was big back in the day but the time has passed.
  - hawkeyedan 4y ago
    And yet I can only read Dante’s original work in Italian!
submeta 4y ago
Ruby is a beautiful language, but it lost the race against Python long ago. - When I first looked into both some ten years ago, I was undecided what to choose. But even back then googling problems led to much more professionally written blogs / articles about Python. Articles about Ruby were not as profound. That’s when I decided to go with Python. And it was the right choice. ## Edit What I miss in Python: Ruby always returns a value and does not change structures in place. For instance `data.sort()` in Python will return `None` and change the order in `data`. Ruby won‘t do that and will return a sorted copy. Like Scheme (a Lisp dialect). In Scheme methods changing data have an exclamation mark as suffix: `(sort! data)` vs `(sort data)`, and it will always return a value. Unlike Python.
- msbarnett 4y ago
  What “lost”? They’re both Top 10 most used languages with tens of thousands of open positions currently available for someone competent in either. Python’s the more frequently used of the two industry-wide, but it seems like they both won, just with different crowds.
  - disgruntledphd2 4y ago
    As a professional data scientist, I kinda wish ruby had won for this area, as it's much closer to R conceptually. Python is fine, the metaobject model is pretty nice, and I've stopped noticing the double underscores ;)
  - dehrmann 4y ago
    I think it's that Ruby has mostly been relegated to Rails, while Python sees use in backend systems, data science, scripts, and as a popular first language.
- tomstuart 4y ago
  You may be making a point about what happens by default (and perhaps Ruby’s similarity to Scheme?), but in Ruby you can also say `data.sort!` if you want the `data` array modified in-place. It’s still returned, though.

210 points by mariuz 4y ago

> The usual-style comments on the line(s) above things (instead of docstrings below them) are used for generating docs. This is another thing about Python that I find very unsettling and wrong.

boberoni 4y ago

> Unlike Python, in Ruby… There are a number of shortcuts that, although give you more to remember, you quickly learn. They tend to make Ruby fun and very productive. I use Python, but have never tried Ruby. The ecosystem for Python packaging is so chaotic that I’ve considered switching. Any Pythonistas/Rubyists here that could point out some Ruby shortcuts that make you more productive?

z9znz 4y ago
Here's a rough list of benefits of Ruby compared to Python. It's not well organized and the examples are difficult to show in a comment box, but I have pages of notes of why Python is frankly a horrible language compared to Ruby. Every expression returns a value, so you can assign the result of an if/else or switch statement to a variable. Within your conditional clauses, you don't have to repeat assignments or return values. If the logic goes down that branch, then the last value in that block is the return value. This also means you don't have to have explicit 'return' statements in functions. Whatever the last value of the last expression is, that's your function return value. You can use an explicit return if you want to exit the function early, however. Ruby has a switch (case/when) statement. Python finally has this in 3.11 I believe, but it took forever to get. Hash.dig(). If you have nested hashes (dicts), you can myhash.dig(:top_key, :lower_key, :even_lower_key) In objects, you can control which attributes can be read/written via attr_reader, attr_writer, attr_accessor. So you can make an attribute have a default getter if you use attr_reader :some_attribute, and then you can write your own setter if you want to control how it gets assigned to. You can even simply not have a setter, so you can effectively make an attribute read-only. Clean, simple hash initializers: h = Hash.new { |h, k| h[k] = { age: 0, nickname: k } }. So now you can just start assigning to values in h like h["bob"][:attr1] = 28, and now h["bob"] refers to a hash with age 28 and nickname "bob". Yes Python has defaultdict, but it's an extra thing you have to use, and it's clumsy compared to the Ruby approach. Hash (dict) merging: It's a mess in Python. In ruby it's just h1.merge(h2), or even h1.merge(key_to_update: 123). And you get a new hash as the result. Or you can merge in place with merge!(), changing the original. Function names with ! and ? greatly simplify function naming (and improve readability). So instead of is_foo(), you just have foo?(). And if you want to indicate that you are doing something destructive, you name it foo!(). This is a common pattern in Ruby libraries, and you often have functions which return a new value and functions with the same name followed by ! which modify the input value. String.strip() returns a new string without leading/trailing whitespace, while strip!() modifies the input string to the same effect. Python's list comprehensions are arguably ugly and messy and harder to visually parse when reading. Ruby has consistent ways of doing operations on collections. This would take a full page to show examples. Copying and pasting code in Python often results in new code which is indented wrong (in the wrong scope), and which you must manually fix. This is not a problem in Ruby, since there are actual 'end' statements. Editors know how to properly indent what you paste. Safe navigation. myobj&.someattr&.foo will give you the value of foo or nil if myobj or someattr don't exist. You have to use ifs to do this in Python. Array flattening. nested_arrays.flatten(). But in python, you have to use something like list(itertools.chain(*arr)), but that fails if the first element of the list is an int (not an iterable). Gettings hash/dict keys. In Ruby, you just do myhash.keys and you're done. But in Python there are several ways to get the keys, none of which is as simple and obvious as just keys(). Not allowing typos to silently fail. With Python, you can take an object and assign a value to a non-existent attribute. You might do this accidentally if you have a typo when trying to set an actual attribute: myobj.first_Name = "bob". Python will happily do that, and you'll later debug and wonder why myobj.first_name == "" (and then notice that you have this similarly named attribute now called first_Name). Duh. I guess you could say it's convenient to be able to do this, but it's more a footgun. Ruby will bark at you if you try this. List sorting in Python is in-place, so you can't non-destructively sort and get the sorted list returned. In Ruby you have a choice. sort() is non destructive, and sort!() is in-place. I've got more, but this is enough.
- maligree 4y ago
  Using the sorted() built-in returns a new sorted array. Getting keys from a dictionary is literally just calling dict.keys(). Sorry, but I don't think you've used Python enough to offer lists like these.
  - z9znz 4y ago
    I stand corrected on the mylist.sort() vs sorted(mylist). But really, such a mistake is more likely with two very different ways of doing the same kind of operation. In ruby you would just mylist.sort() for a new sorted list (although parens are optional if no arguments, but I show them), or mylist.sort!() to sort mylist in place. You don't have to know two very different things. Plus it's obvious with the ! > Getting keys from a dictionary is literally just calling dict.keys() Nope. Unless your definition of "keys" is a 'dict_keys' class. Chances are really good that what you wanted was a list of keys, not some object which does not behave exactly like a list. If you want to access the keys by index, you can't do it like mydict.keys()[0] because dict_keys does not have an index method. Oddly, if you want a list of keys of a dict in Python, you just do list(mydict). But you can also do [*mydict], which gives you a list of keys but is something special you have to learn. Here's a fun one. Give me the first key of a dict. Ruby: mydict.keys.first Python: (several ways) next(iter(mydict)) # which makes no sense at all... asking for the next value of something when you're actually asking for the first. list(mydict)[0] [*mydict][0] What if you want the values of the dict? Well, no surprise, Python gives you a dict_values object when you do mydict.values(). Likewise, you can't do listy things with that because it's not a list. You have to convert it to a list with list(mydict.values()). Or you can do the [*mydict.values()] thing. Python is full of so many inconsistencies, the cognitive overhead is much higher than it needs to be. I would argue that it makes people dumber, because they have to waste mental energy learning weird things for special cases. But what about the rest of my previous post list? Here's one I left out. The return-early pattern is common in imperative programming. We like to exit a function as soon as we know things aren't going a certain way. In Ruby: x = fetch_object("bob") or return "bob not found" In Python you need 2 or 3 lines (2 if you're using the walrus := operator). if (x := fetch_object("bob") is None): return "bob not found" How about setting a value for a variable if it is unset? This is a common thing done when you have variable arguments Ruby: x ||= "default" Python: x = x or "default" # not only does it look stupid setting a thing to itself, but it will fail if x is zero. Edit: fixed asterisks.
batiste 4y ago
It really doesn't... After years using Ruby my mind never managed to parse its complicated grammar.
- travbrack 4y ago
  Any examples? I always found it easy to grok but I'm not at a very high level so I'm curious where it gets hairy.
  - cycomachead 4y ago
    There's a bunch of things to pay attention to in Ruby. I wouldn't say these get too hairy, but they trip students up for very understandable reasons. * `a ||= b` is not just `a = a || b`, but `a || a = b` * The distinction between defaults arguments and hash arguments in functional signatures has many edge cases -- but it's much much better in Ruby 3. * There are still 2 pieces of syntax for hashes (`{a: 1}` and `{:a => 1}`) They are the same. * Curly bases show up a fair bit for a language that's not a braces language. :) They're in hashes, blocks, and % strings. e.g. `%w{a b c}` is the same as `%w|a b c|`. They're also used in string interpolation, e.g. `"Hello, #{name}"`. * There are sometimes many ways to do the same thing. There's Procs, blocks, and lambdas. % strings work with many characters. * `unless` for `if not...` and get wonky. * Overusing "surprise if" e.g. `do_thing if other_thing` can be hard to read. * It's so easy to monkey-patch and extend primitive classes, you might not realize when libraries do it. All of these are features that I actually find nice to use in the right contexts. But they can pop up when you don't expect, and they can definitely make Ruby a challenge to learn. That said with a little discipline (or just a linter ;)), I find a lot of Ruby code a joy to read and write.
    - IshKebab 4y ago
      > `do_thing if other_thing` Yeah I don't get why you would deliberately make the flow control confusing and backwards like that. Python list comprehensions are the same. They make the information flow backwards. This also has the effect of making nesting really confusing.
Hamuko 4y ago
You should probably try some 10-minute Ruby tutorial to see if the syntax doesn't completely scare you off.
- Gordonjcp 4y ago
  When I looked at Ruby (admittedly a long time ago now) everything was 10 minute videos. Is there any actual useful material on it now?
  - regularfry 4y ago
    The default guide for a long time was the Pickaxe book, which solidly pre-dates the availability of 10-minute videos by several years. There are a fair few links here that you might find useful: https://www.ruby-lang.org/en/documentation/ https://www.ruby-lang.org/en/documentation/
  - nomilk 4y ago
    There's ~50 short exercises/lessons here: https://learnrubythehardway.org/book/ https://learnrubythehardway.org/book/ I did them when I started out, and occasionally revisit as a refresher. It doesn't teach everything in ruby, but it absolutely gives enough to do just about anything you could want.
cycomachead 4y ago
More productive is really hard to say... But I personally prefer Ruby to Python. For smallish scripts, I really like Ruby's backticks for easily executing shell commands. And I find the metaprogramming support in Ruby great for some tasks. I'm not sure if that's what you're getting at. But especially with "modern" Python features like f-strings and the walrus operator there's not tons of differences that really stand out as "productivity". One thing to just remember: Ruby is not just the Ruby on Rails community. Rails is a dominate space, but it's not the only thing out there. At the same time, when it comes to scientific computing, ML, etc. the Python ecosystem is incredibly robust. There's plenty of awesome Ruby tools for these things too, but it is not the same. Ruby and Python are the two languages I primarily teach courses in, and used professionally. Ruby is my cup of tea personally, but they're both modern dynamic interpreted languages.
- ptx 4y ago
  > For smallish scripts, I really like Ruby's backticks for easily executing shell commands. Executing external commands is pretty convenient in Python these days, now that we have subprocess.run [1], and passing the command as a list rather than through the shell seems a lot safer. Doesn't backticks open up the classic command injection issues (i.e. the same kind problem as SQL injection with non-parameterized queries) unless you're extremely careful to manually apply proper quoting in every single case? [1] https://docs.python.org/3/library/subprocess.html#subprocess.run https://docs.python.org/3/library/subprocess.html#subprocess...
  - noirbot 4y ago
    It would, but most of the time when I'm using backticks, it's because I'm writing myself/my team a little helper script that will never get "injected" with anything. Backticks (and the other more featured ways of doing shell commands in ruby) make it really easy to write what amounts to a Bash script, but with a little more features and readability, or pull in some relevant libraries for some more complex task that would be annoying to do in pure Bash.
    - ptx 4y ago
oezi 4y ago
I think with "shortcuts" they mean things such as $1 (first match group of a regex) or =~ (regex match operator). I general I rarely feel like I am unproductive in Ruby (or bogged down in boilerplate typing).
- cycomachead 4y ago
  In that case -- I definitely agree Ruby usually gets out of way. It's often my go to for hacking on something, unless it's data science-y. I'll mention: implicit returns, return if, and safe navigation, the &. operator. Ruby's newer pattern matching features are really cool[1], especially for things like JSON structures, but I've only use started using them. Classes are also super easy to extend. Many of these things are also incredibly easy to abuse - but they have their places. [1]: https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rdoc.html https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rd...
transfire 4y ago
I’m not sure what “shortcuts” the author is referring, but perhaps… x = y || z # if y is falsy x = z x = f ? y : z # ternary operator %w{one two three} # array of words And so on.
- endorphine 4y ago
  Also: x ||= 1 x &&= 1 and the various built-in methods from Array, Hash, Enumerable, String etc.
- intuxikated 4y ago
  These all exist in python, though you use or/and instead x = y or z x = f and y or z you can also use inline if/else x = y if f else z 3rd one just seems like an array of strings? ["One", "two", "three"] Not needing quotes for single words saves some typing tho.
  - deleted 4y ago
    [deleted]
pmontra 4y ago
I loathe most shortcuts: too many things to remember and usually cryptic syntax. Maybe that's because I have to be a polyglot developer (Elixir, JavaScript, Ruby, Python) and I can't remember all the tiny details of each language. If you want to give a try to Ruby, get to understand blocks quickly. Instead of for item in list: work_on(item) which would work (with a closing end and no : ), the idiomatic way is list.each do |item| work_on(item) end or the one liner list.each {|item| work_on(item)} Check also map, select, each_with_index, each_with_object, etc. Blocks are fundamental to Ruby for reason that only practice can tell.
- greenpeas 4y ago
  Or with numbered parameters (since ruby 3.0) list.each { work_on(_1) }
  - pmontra 4y ago
    Which is exactly the kind of shortcut I loathe.
    - greenpeas 4y ago
      you're not alone :) https://bugs.ruby-lang.org/issues/15723 https://bugs.ruby-lang.org/issues/15723 This syntax looks ugly, but it's really nice when writing short scripts. Combined with one line function declarations: `def foo(n)= bar`, it can make an irb session much faster/shorter.
  - BiteCode_dev 4y ago
    Swift has this as well, and it's really nice. Doing map(lambda x: x + 1, stuff) or [x + 1 for x in stuff] adds nothing of value for those very simple cases. I wish we had map($1 + 1, stuff), or ever better, stuff |> $1 + 1. Python does a lot of things right, but for a language with a strong emphasis on the iterator design pattern, I wish it would provide more expressive primitives. However, it comes with the FP territory, which Python is not well suited for, and it would also imply a higher cost of entry to beginners.
  - 4y ago
shaicoleman 4y ago
There are thousands of little things that make Ruby nice. They all add up to a more enjoyable experience. I'll give you one tiny example: Python: from datetime import date if date.today().weekday() == 5: print("It's Saturday") Ruby: require 'date' puts "It's Saturday" if Date.today.saturday?
- ouija 4y ago
  I prefer the Python code here. The import is explicit, so if you want to know where "date" comes from, that's easy. In a modern IDE I don't write imports manually anyway. You could write it as a one-liner in Python as well, but I would prefer not to. print("It's Saturday") if date.today().weekday() == 5 else None That the Python library doesn't define constants for days is unfortunate, but not a limitation of the language.
  - petepete 4y ago
    Why do I need to remember that Saturday is 5?
    - greenpeas 4y ago
      S looks like 5 if you squint. not hard to remember
      - jjgreen 4y ago
        So Sunday?
        greenpeas 4y ago
        No! Sunday is 6 because "Sunday" has 6 letters.
        jjgreen 4y ago
        That's it, I'm switching to Python!
bsaul 4y ago
From what i've seen ruby is definitely on the downward slope regarding adoption and python has become a defacto standard in some fields. Its ecosystem is much better in pretty much every domain, so i don't think there's any point switching at the moment, honestly.
- jillesvangurp 4y ago
  I've used both. I slightly prefer python over ruby. But I haven't used either recently. Ruby's strength is internal DSLs. Python's strength is that it's simple to pick up for people. There's a large community of people that are not primarily programmers that use it. The reason for this is that it is a very easy language to get started with. Both share the same problem: they are weakly typed scripting languages. Both have in common that type annotations have been retrofitted to the language. But it's an uncomfortable and awkward retrofit in both cases and their respective communities seem to regard using types as an optional and inconvenient thing. Ruby with types of course exists. E.g. Crystal is nice apparently. But I've not really seen that used in the wild. Python is enormously popular; ruby's popularity seems to have declined a lot. I know a lot of former Ruby programmers that have moved to different languages and only a handful that still use it. It's not an obvious language to pick up for younger programmers. There are so many other languages to choose instead. IMHO the key innovation in language design in recent years has been type inference. This has lead to a new breed of languages that keep most of what made python and ruby popular: the ability to write code with a minimum of verbosity but without sacrificing type safety. Whether you use Kotlin, Typescript, C#, or even Java: they have type inference now and it reduces the verbosity that comes with having types. Scripting vs. compiled languages is much murkier these days where scripting languages have compilers or transpilers and linters and compiled languages have REPLs and all languages can now run in a browser via WASM anyway. The distinction is just not that relevant anymore. I write a lot of Kotlin, have dabbled a bit with typescript and I don't think I'll ever use languages without proper types again. Just not worth it for me. I don't see the value of not having a good typing system. Kotlin is interesting to me because internal DSLs are a thing with it; just like they were a thing with Ruby. And it can use javascript as a compilation target. Ruby has a slightly nicer syntax for DSLs than Kotlin for internal DSLs. But I don't mind curly braces and having strong typing enables a lot of good stuff. Like proper IDEs with refactoring, autocompletion, auto-fixes, etc. which are all very nice things to have in a DSL. I use Kotlin DSLs for writing CSS, HTML components (we use kotlin-js), writing elasticsearch queries (I maintain the multi-platform kt-search library), gradle build files (which uses kotlin script), and quite a few more things. IMHO, it could do a lot of things that python is popular for as well.
davidthewatson 4y ago
I've been using python for two decades and ruby exactly one decade ago for a couple years. Your comment on packaging is interesting. My perspective is that packaging on ruby was in nearly the same state ten years ago as python is now. My team switched ruby package managers several times during the ruby work and none of them ever worked reliably and was a regular root cause of fragility in our builds. I hope that ruby packaging has settled in that time while python has the same kind of cultural noise that afflicted ruby during that period. Popularity has downsides. Political packaging wars is one of them. I'm old school enough that I stick with tried and true pip, venv, and .env and its ilk. There was a long battle in downstream packaging for a while that I just didn't want to be involved in having seen the same thing in ruby. FWIW, if I were you I'd look at crystal, elixir, or nim. I was very productive in ruby but the near constant battle of wrestling with DSL's that are not concomitant with their parent is, IMHO, to be avoided. I've seen more than one team fall prey to that trap. Caveat emptor - pick your DSL's carefully.
- kawsper 4y ago
  What do you mean by switching packaging managers? Ruby uses Rubygems and Bundler to manage packages. Are you referring to Ruby version managers that manages different versions of Ruby (rbenv, rvm, asdf, etc.)?
  - ByteJockey 4y ago
    They mention doing this a decade ago. They were probably using utilities to manage downloads from the ruby application archive (which would have still been around at the time) and automate running `setup.rb`
    - davidthewatson 4y ago
      Yes, all of the above. Sorry for the unclear language. At the time, I recall it being very distracting when the team was focused on shipping well-tested code. We had a world class devops guy, but we all ran into these build issues frequently enough that it was a regular complaint at retrospectives no matter what tooling we were using at the time or who was using it. It was not long after this that I read Daniel Greenfeld's book on Django that introduced the notion of "vanilla django" and that resonated with me, precisely because our rails tooling was decidedly not vanilla. My take now is that rails can have the same problems with regard to being "off the rails" WRT the aforementioned DSL's and such. I don't think the root cause is ruby as much as there are pockets of rails that are far from what DHH describes.
nickjj 4y ago
> Any Pythonistas/Rubyists here that could point out some Ruby shortcuts that make you more productive? It depends on what you want to do. If it's building web apps there's Ruby on Rails, which is written in Ruby. In my opinion there's no alternative to this in Python. Sure there's Django but it's not the same even though both are considered batteries included web frameworks. One nice thing is you'll find both Python and Ruby SDKs for a ton of third party services (like Stripe, etc.). That goes a long ways for building things quickly and with confidence. Ruby's package manager is also a lot better IMO. It supports proper lock files out of the box and everyone uses gems with bundler. In Python it's a mix of pip, pipenv, poetry, etc. all of which have their own unique issues. With Ruby I never felt like I had to battle this aspect of the language. You just bundle install what you want and creating gems is the same process.
- lloeki 4y ago
  If one wants to get into Ruby, please stay away from Rails as a first step into Ruby-land. Look into Rack and Sinatra first, then Rails. Even if it's a short trip it's going to be worth it.
  - Lio 4y ago
    This is personal opinion but these days I'd probably swap Sinatra for Roda[1] for small API services. It's generally faster, uses less memory and is a really good example of well written ruby code, IMHO. I also really like Jeremy Evans' book, Polished Ruby. 1. http://roda.jeremyevans.net/index.html http://roda.jeremyevans.net/index.html 2. https://www.packtpub.com/product/polished-ruby-programming/9781801072724 https://www.packtpub.com/product/polished-ruby-programming/9...
- MatthiasPortzel 4y ago
  > Sure there's Django but it's not the same Could you elaborate on this? I’ve used both Django and Rails and in my mind they’re direct parallels to each other. For example: in Rails you write migrations and then it generates a schema.rb, and in Django you update your model schema and then it generates migrations. They have very different philosophies, sure (reading the Rails manifesto made that clear), but from a technical standpoint they have pretty good feature parity.
AnthonBerg 4y ago
I like the RubyMine IDE a lot. The code intelligence is very good – it’s so good that it tends to teach you Ruby as you use it. Code intelligence as in code navigation, easy access to documentation on the fly, refactoring, code style suggestions. The same goes for the tooling integration. It works with most of the development tools you’d use with Ruby and captures the integration pretty well in a UI and associated workflow. Link for your convenience: https://www.jetbrains.com/ruby/ https://www.jetbrains.com/ruby/ (No affilition except being a paying user.)
- gls2ro 4y ago
  I am using both Vim and RubyMine and I strongly recommend RubyMine for anyone starting with Ruby. Having the possibility to have a Go to definition for almost any method is great and most of the gems have great code comments with a lot of nice examples. When I teach people to learn Ruby (I do this sometimes) among the first things I do is I explain to them how to open a gem, look at the source code, read it and then try to use it. I cannot thank enough the maintainers of the most popular gems for doing such a great job in having great ruby code and good in-file documentation.

scotty79 4y ago

For me there wasn't ever question of "How?" only "Why?". One time I landed on Ruby project and I didn't have any trouble fixing bugs and implementing minor functionalities without really learning Ruby only knowing some Python.

cortesoft 4y ago
I feel similarly about python. I use ruby all the time, but can do things in Python just fine, especially if I have an existing code base that I am working on.
- scotty79 4y ago
  Tensorflow? Numpy? No idea what else might be the reasons to learn Python when you know Ruby.
  - cortesoft 4y ago
    Because there is a lot of Python code at my work.

deleted 4y ago

[deleted]

ptx 4y ago

> You can read docs on the command line (with the ri command instead of pydoc). I've been using Python for a long time, but somehow I never learned about pydoc. It looks like a pretty handy tool!

helge9210 4y ago

On the surface, Ruby and Python are mostly equivalent languages. Internally, memory management is done differently, for example. Now add a magic of Ruby on Rails and ActiveSupport to one side and machine learning toolsets to the other.

viraptor 4y ago
Not just on the surface. See the ruby to python bytecode compiler: https://github.com/whymirror/unholy https://github.com/whymirror/unholy

DonHopkins 4y ago

“Python is bash for mathematicians.” -Michael Slavitch

BiteCode_dev 4y ago
Python is used for Web dev (Django), geography (all SIG), system components (part of Unix), pen testing (E.G: scapy), 3d modeling (Blender), sysadmin (ansible), etc. I've been coded mostly in Python for 15 years and using the scientific stack is a very small parts of what people pay me of, if they ever do.
- DonHopkins 4y ago
  You're misinterpreting that quote as criticism of Python instead of praise. He's not saying that's the ONLY thing that Python is good for. I've also been programming in Python extensively for at least 20 years, including web application servers like Zope and TurboGears, embedding and extending apps and tools with the Python/C API and SWIG like SimCity, Gnu Radio, Big World MMPORG, robotics, simulations, Blender, Houdini, user interfaces like Tkinter and PyGTK and Sugar, XML processing, OLE integration, BeautifulSoup web page scraping, image processing, character animation, speech synthesis, system administration, infrastructure as code, machine learning, etc. Python is of my primary programming languages, and I love it. It's a GOOD thing that mathematicians use Python instead of Bash!
  - BiteCode_dev 4y ago
    Mathematicians never used bash. Most of them didn't even touched the command line 10 years ago. I'm not the one misinterpreting.
    - DonHopkins 4y ago
      It's pretty clear and not subject to interpretation that I never claimed mathematicians ever used bash, but just the opposite: they use Python instead. Bash is an easy way to plug other code together, but it's terrible for math. Python is a much better way to plug other code together, and it's much better at math.

zem 4y ago

as someone who has used ruby for years, and more recently got a job working in python, I think the most significant difference between the two languages is how they handle imports. in python every file is also a module, and all imported symbols are namespaced within that module (unless you deliberately use "import *" to bring them into the current module's namespace). so you can define function foo in module bar and use it via "import bar; foo.bar()". in ruby, modules/namespaces and files are two entirely orthogonal concepts; you define a module by enclosing code in a "module Foo; ...; end" block, and any file can open up the same module and add stuff to it. when you import a file it adds everything within it to the current global namespace, which makes it really hard to read a piece of ruby code and see where everything within it was defined. for the most part where ruby and python differ I prefer the ruby way, but I feel like automatically namespaced imports is something python got right, and was a really big miss for ruby.

typeofhuman 4y ago
> so you can define function foo in module bar and use it via "import bar; foo.bar()". Wouldn't this be "import bar; bar.foo()"?
- 86J8oyZv 4y ago
  In Ruby it’s “require” rather than “import.” But it would be more like “require bar; foo()”. However, Ruby does have auto-loading conventions. So you could define “module Baz{ module Bar { def foo end; } }” in “baz/bar.rb” from the root of your project. You should then be able to call “Baz::Bar::foo()” from any other file in your project structure without a “require” at all. This is not standard Ruby IIRC, but Rails and other frameworks use it.
  - gls2ro 4y ago
    There is a gem that does that used by Rails and multiple other gems: https://github.com/fxn/zeitwerk https://github.com/fxn/zeitwerk It is pretty easy to set it up in any Ruby project.
  - 4y ago

vault 4y ago

deleted

greenpeas 4y ago
What do you mean? > When tested for truth, only false and nil evaluate to a false value. Everything else is true (including 0, 0.0, "", and []). In ruby only `false` and `nil` evaluate to false values. 0, [], "" all evaluate to true when used in `if` statements. In python (just like in C and JS) many things evaluate to false (including 0, 0.0, "", and []).
- vault 4y ago
  Ah sorry I read "Unlike Ruby, in Python" instead of "Unlike Python, in Ruby"

thih9 4y ago

This page is old [1], is there any reason or context regarding why it is interesting now? [1]: Archived in 2006: https://web.archive.org/web/20060925032432/https://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-python/ https://web.archive.org/web/20060925032432/https://www.ruby-...

Kwpolska 4y ago
The page has been slightly changed since then, but it is still quite outdated. Python 3.6 (2016) has formatted strings, and new/old-style classes thing isn’t relevant at all since Python 3, but wasn’t that much of a deal with Python 2 at the end of its lifetime (~everything was new-style by then).
- sitkack 4y ago
  Ruby is a neat language that I don’t know very well. Blocks are nice. The pattern matching in Python 3.10 compels me to stay.
  - weaksauce 4y ago
    ruby has some nice pattern matching too https://rubyreferences.github.io/rubyref/language/pattern-matching.html https://rubyreferences.github.io/rubyref/language/pattern-ma... not sure if python has better matching though but the ruby stuff is pretty compelling.

wodenokoto 4y ago

> There’s only one kind of list container (an Array), and it’s mutable. What are the other kinds of list containers in Python? I only know of `list()`/`[]`, but maybe I just don’t realize that some other thing I use is also a list container.

uranusjr 4y ago
I’m guessing they’re implying tuple, it’s pretty common to consider that type as “immutable list” (although personally I very much dislike this categorisation)
- masklinn 4y ago
  > although personally I very much dislike this categorisation It’s not a categorisation, it’s literally the nature of the thing in Python. And while I agree that it’s distasteful the error was in the original introduction. As things are, python tuples are immutable sequences with all that implies. They are iterable, indexable, sliceable, …
  - baq 4y ago
    Immutability crucially allows for hashability, so you can use (some) tuples as dict keys.
kevin_thibedeau 4y ago
array.array
zbentley 4y ago
array.array, as another commenter mentioned; numpy.array is popular for performance-oriented code (but not in the stdlib); collections.deque; queue.Queue; tuple; struct (though it's a bit of a pain to make one behave in an array-like way and is usually better to use array.array); heapq; and multiprocessing.shared_memory.ShareableList. Out in pypi there are many additional esoteric list-like data structures: bitarray is one of my favorites, and there's also awkward-array, cyarray, tinyarray, fixedlist, blist, bigarray, sortedcontainers, and many many more.

mahathu 4y ago

I love Python and use it pretty much anywhere I can, especially as it's ubiquitous in scientific computing. Is there a good reason to switch to Ruby except to try something new?

nixpulvis 4y ago
I would claim that Ruby as a language is much nicer to use, however it has less support for data science and other things which Python is much more well known for. If you ported over some libraries, you might find you like Ruby more in the end.
- doix 4y ago
  My biggest gripe with Ruby is how much syntax is optional and the "accepted" conventions by the community are to leave out a lot of optional syntax. The worst offender (in my opinion of course) is leaving out of empty parentheses on method calls. It makes it impossible to know if something is a property or a function. The argument is that it doesn't matter if it's a property or a function, but I feel like it makes it very difficult to reason about performance. If I know something is a function, I'll look at the function and see what the performance implications are. Where as if something is a property, I assume it's "free" to access. This doesn't hold when reading Ruby code, and I basically have to look up everything all the time. Just my opinion as someone that had to switch between python/ruby/perl to maintain tools written during different decades.
  - nixpulvis 4y ago
    Always use parens. That's my rule.
  - floodedchip 4y ago
    What do you mean by “property or function”, though? There are no properties or functions in my view—only messages. object.message sends message to object, which object may or may respond to.
    - 4y ago

winstonsmith 4y ago

>[In Ruby] There is good support for functional programming with first-class functions, anonymous functions, and closures. This seems like a blatantly false claim to me since as a Python programmer forced to use Ruby for Sketchup, I have been frustrated by the lack of first-class functions in Ruby.

tomstuart 4y ago
I’m interested to learn what “first-class functions” means to you. Ruby has both `Proc` and `Method` which would appear to qualify. Is your frustration that you can’t `def foo … end` and then use bare `foo` to refer to it as a value (vs invoking it)?
- winstonsmith 4y ago
  My frustration is that you can't pass foo as an argument to another function.
  - tomstuart 4y ago
    Right, I see, because you have to say `method(:foo)` or `-> { foo }` or whatever. To me this is an acceptable syntactic trade-off in exchange for being able to invoke the method with bare `foo` (i.e. variable reads and method calls look the same) but I can see from other comments here that some people dislike that ability anyway. Vive la différence!
  - chrisseaton 4y ago
    But you can. Method objects, proc objects, lambda objects, blocks, you've got a wealth of options here in Ruby.

sinsterizme 4y ago

This is very good timing for me, I just left my python dev job and am starting a job where they use Ruby. I’m very excited to be using Ruby again, it’s a much nicer language to use for a variety of reasons I can’t possibly enumerate. Ruby’s stdlib and surrounding documentation is pristine, I vividly remember being appalled when trying Python for the first time and thinking where the rest of it was. The major issue I find with Ruby (and that I saw mentioned elsewhere in this thread) are imports / requires, which is much too magical in Ruby; Python’s import is way saner

fny 4y ago
Ruby's imports aren't magical by default. Autoloading frameworks make them so.
- khaledh 4y ago
  The fact that ruby makes this possible means the community will take advantage of it, to the point of abusing it sometimes. This hurts understandability of the code base. Too many times I would open a ruby code base and spend significant amount of time tracing where things are defined (mostly relying on suboptimal searching) because of the lack of explicit imports/requires.
  - ysavir 4y ago
    An easy way to do that is to use the Pry gem. If you're in a pry console, you can use `show-method Thing.foo` and it will show you the method, which file and line it's defined in, etc. Pry is a great tool and this feature makes is a blessing.
  - Spivak 4y ago
    Python can do this magic too and the community hasn’t abused it. Every part of modules and module loading is swappble, mutable to the point where modules can be arbitrary classes if you want. It would be 2/10 difficulty to add transparent module autoloading to Python because you can just hook into module loading and arbitrarily modify or replace the module objects. You wouldn’t even need a courtesy import because the main module is still a module.

lloeki 4y ago

For some reason it reminded me of _why's unholy: https://github.com/devyn/unholy/blob/master/README https://github.com/devyn/unholy/blob/master/README > You know, it's crazy that Python and Ruby fans find themselves battling so much. While syntax is different, this exercise proves how close they are to each other! And, yes, I like Ruby's syntax and can think much better in it, but it would be nice to share libs with Python folk and not have to wait forever for a mythical VM that runs all possible languages.

tomc1985 4y ago
That's funny. In a previous job I was the biggest Ruby supporter on a team of Pythonistas. To show them how similar the language was I translated a couple of their scripts from Python to Ruby... it was surprisingly easy and the linecount was about the same
- teddyh 4y ago
  That is all good and well, but which was easier to read and debug?
  - tomc1985 4y ago
    That really depends on your background... I find Python harder to read than Ruby
    - ShamelessC 4y ago
      > On a team of Pythonistas

mark_l_watson 4y ago

I loved coding in Ruby. I also wrote a Ruby book for Apress, my last book for a major publisher before starting to self publish on leanpub.com/u/markwatson Two factors made me leave Ruby behind: I am somewhat known for Common Lisp, and so CL jobs would come my way. Also, in the last 8 years, a huge amount of my work has been in deep learning and Python wins there. Anyway, Ruby was designed to make programmers happy, and it is a big success at that.

deleted 4y ago
[deleted]
Hackbraten 4y ago
I tried for many years to be happy with Ruby. Ended up leaving it behind because more often than not, when I revisited a Ruby codebase after a while, Bundler would complain and tell me that I’m supposed to run `bundle install` something, and sure enough, doing just that sent me into a rabbit hole of errors.
- Taikonerd 4y ago
  If you switched to Python, then you probably traded your `bundle install` errors for `pip install` errors ;-)
  - fny 4y ago
    Pip doesn't do dependency resolution either... I spent a day trying to pin down issues migrating a project from pipenv to poetry because poetry did not agree with pipenvs resolution.
    - neeleshs 4y ago
      AFAIK, pip does dependency resolution, you can disable it via --no-deps https://pip.pypa.io/en/stable/topics/dependency-resolution/ https://pip.pypa.io/en/stable/topics/dependency-resolution/

mountainriver 4y ago

Really the only reason to use Python is ML, but that is the future of everything so….

goatlover 4y ago
> Really the only reason to use Python is ML Not the other scientific and statistical libraries? > but that is the future of everything so…. So is fusion and flying cars. Maybe one day AGI will be here, but I doubt we humans will be using Python ML libraries at that point.
- mountainriver 4y ago
  In the next 5-10 years, ML will likely write most of our code and that will almost certainly come from Python
x86x87 4y ago
nah. ML is not the future of everything. in fact I believe that as things are going to evolve ML as we see it today is going to be only a tiny fraction of what is going to be used
- mountainriver 4y ago
  yeah but the ML of tomorrow will write all of the code

revskill 4y ago

Ruby eventually failed in term of quantity of developers, means OOP will eventually died. It's not Ruby's fault, it's just the failure of OOP in general. My prediction, in about 4 years or more, OOP is just an abandon concept for all programmers.

tomc1985 4y ago
So, C++ and Java have just a couple of years of life left?
- damagednoob 4y ago
  Not too mention C#, Python and for some, Javascript.
  - mypalmike 4y ago
    All doomed. Google and Amazon, for example, will rewrite their many millions of lines of Java and C++ in Haskell by 2026.
gls2ro 4y ago
Mind you that (let's say) the modern concept of OOP was invented around second part of 60s (with Simula I think) and I think functional a bit earlier maybe in the beginning of 50s (with LISP I think). Both paradigms have a lot of years of practice and saying that anyone of them will die in 4 years is I think a bit of exaggeration. Why do you think that in 4 years OOP will be abandoned by programmers? What is the basis for your assertion? I think it is more probable that we will have a kind of cross-pollination between these two paradigms with maybe newer languages (or evolving existing languages) to borrow concepts and best practices while still providing the core way to design solutions. This is already happening in smaller scale in multiple languages as far as I see it.
goatlover 4y ago
Uh huh. And static typing will replace dynamic for all programmers, functional will replace all uses of imperative, nobody will use whitespace indentation, and all emacs users will switch to vim. Also, every programmer will abandon Windows and macOS for Linux.

by_the_bay 4y ago

One of my biggest complaints about Ruby is that that it’s so much harder to drop into a debugger. In python it’s as easy as import pdb; pdb.set_trace(), but for ruby (at least the versions on our build systems), you need to figure out how to add the dependency for pry/byebug first which is non trivial.

tomstuart 4y ago
A fair complaint, but FYI it’s outdated as of Ruby 3.0 (released in 2020) which includes the `debug` gem [0]. So in Ruby 3.0 onwards it’s as easy as `require 'debug'; debugger` just like you want. Hopefully your build systems will upgrade to a newer Ruby before too long. [0] https://stdgems.org/debug/ https://stdgems.org/debug/

bamboozled 4y ago

Forget all of it and use Go :)

entropie 4y ago
Probably not a bad advice. Most of the ruby enthusiasts I know from the old days took a deeper dive into go.
- goatlover 4y ago
  I would think Elixir or Crystal would have been the more natural transistion for Rubyists. Or even Common Lisp. Go's philosophy is very much at odds with Ruby's.
jonnytran 4y ago
The only thing I disliked more than moving from Ruby to Python was moving to Go. All the things I love about Ruby are the antithesis of Go.
x86x87 4y ago

amerine 4y ago

Ruby seems to have cemented itself in my head as one of my favorites. I’ve built a career from it and am eternally grateful.

RomanPushkin 4y ago

If you're learning Ruby, there is a free copy of my book available (CC BY 4.0 license): https://leanpub.com/rubyisforfun/ https://leanpub.com/rubyisforfun/ - English https://leanpub.com/rubyisforfun_ru/ https://leanpub.com/rubyisforfun_ru/ - По-русски (if you found typos, you can update the manuscipt https://github.com/ro31337/rubyisforfun https://github.com/ro31337/rubyisforfun)

jbverschoor 4y ago

I'm missing the best part - In ruby we have an intuitive and extensive standard library

aendruk 4y ago
Of all measures to compare by that seems a particularly ill choice. One of the few things I know about Python is its longstanding reputation for having batteries included. (But yes, you can pry Enumerable from my cold, dead hands.)

hawkeyedan 4y ago

Arguments about the “superiority” of Python vs Ruby always sound a bit like arguments about the “superiority” of Italian vs Spanish. If you squint a bit they’re basically the same. (By that simile, Lisp would be Sanskrit?)

thebigspacefuck 4y ago
True, but 85 million Italian speakers vs 500 million Spanish speakers so that tells you something. Sure the Roman Empire was big back in the day but the time has passed.
- hawkeyedan 4y ago
  And yet I can only read Dante’s original work in Italian!

submeta 4y ago

Ruby is a beautiful language, but it lost the race against Python long ago. - When I first looked into both some ten years ago, I was undecided what to choose. But even back then googling problems led to much more professionally written blogs / articles about Python. Articles about Ruby were not as profound. That’s when I decided to go with Python. And it was the right choice. ## Edit What I miss in Python: Ruby always returns a value and does not change structures in place. For instance `data.sort()` in Python will return `None` and change the order in `data`. Ruby won‘t do that and will return a sorted copy. Like Scheme (a Lisp dialect). In Scheme methods changing data have an exclamation mark as suffix: `(sort! data)` vs `(sort data)`, and it will always return a value. Unlike Python.

msbarnett 4y ago
What “lost”? They’re both Top 10 most used languages with tens of thousands of open positions currently available for someone competent in either. Python’s the more frequently used of the two industry-wide, but it seems like they both won, just with different crowds.
- disgruntledphd2 4y ago
  As a professional data scientist, I kinda wish ruby had won for this area, as it's much closer to R conceptually. Python is fine, the metaobject model is pretty nice, and I've stopped noticing the double underscores ;)
- dehrmann 4y ago
  I think it's that Ruby has mostly been relegated to Rails, while Python sees use in backend systems, data science, scripts, and as a popular first language.
tomstuart 4y ago
You may be making a point about what happens by default (and perhaps Ruby’s similarity to Scheme?), but in Ruby you can also say `data.sort!` if you want the `data` array modified in-place. It’s still returned, though.