[HN Gopher] An Ode to Ruby
___________________________________________________________________
An Ode to Ruby
Author : yboulkaid
Score : 245 points
Date : 2022-01-10 13:43 UTC (9 hours ago)
(HTM) web link (blog.yboulkaid.com)
(TXT) w3m dump (blog.yboulkaid.com)
| YorickPeterse wrote:
| > For I once again have trouble installing Nokogiri.
|
| One could consider https://rubygems.org/gems/oga, as it doesn't
| have any installation problems. It's not actively maintained
| though (mostly because the author considers it to be complete). I
| do think the author is a bit of a weirdo though :)
| Lukas_Skywalker wrote:
| Thanks for creating oga :) I use it a lot. Bonus: it's even
| slightly faster than Nokogiri.
| cHaOs667 wrote:
| A big shoutout to the author to include the Nokogiri installation
| "experience"... :D <3
|
| Well done!
| tibbon wrote:
| I have similar problems in Python with OpenCV. It should be so
| simple, but generally is not (or at least last I tried)
| squaresmile wrote:
| OpenCV has wheels built for all common platforms so it should
| be fine now. If your platform or python version is too
| new/old/unsupported then yeah, you can forget about building
| it and use another platform/python version.
|
| To be honest, it's always this dice roll with most things on
| pypi. If there are wheels for you, golden. If not, you better
| hope it's a pure python package or it doesn't pull any
| outside libs. Things are getting better though with solutions
| like cibuildwheel.
| fuzzyengineer wrote:
| ...you might not immerse me in the meta'verse but I am happy
| getting lost in meta'programming...
| mrtranscendence wrote:
| A coworker of mine is leaving for a Ruby job, which caught me off
| guard, so I've had Ruby on the brain a bit lately. I was a big
| fan of Ruby for a few years back in 2004-2006 or thereabouts.
| Rails was the new hot thing, but I wasn't into web dev so I
| didn't pay all _that_ much attention to it. I remember
| blindsiding my networking professor by using Ruby for an
| assignment when he expected but failed to specify Java or C ...
| he was a good sport, thankfully.
|
| I strayed from the CS path into econometrics and then data
| science, so Ruby just wasn't a good fit for basically anything I
| do. That seems to remain the case, unfortunately, though I like
| it on the language level more than my bread and butter Python. Oh
| well.
| vidarh wrote:
| I used Ruby for my MSc thesis... which involved applying
| statistical approaches to reduce error rates in OCR. I did have
| to call out to C code for a few things (k-means in Ruby 1.8.x
| was not fast...).
|
| Most of my Ruby work has been outside of web. Message brokers,
| cloud orchestration and assorted devops, a text editor (for my
| own use - it's replaced Emacs for me), financial simulations.
| And that means the majority of my work for the last 15 years.
|
| Ruby has gotten more low key, but for those of us who never
| really liked Rails that's not really mattered much.
| pantulis wrote:
| I used to joke about Nokogiri dependency troubles for many years,
| but to be honest the experience in macOS lately has been
| straightforward for me.
| Mikeb85 wrote:
| Just curious, what's the issue with Nokogiri for some people?
| It always installs just fine for me...
| pantulis wrote:
| In OS X it was usual to have your bundle explode when
| compiling Nokogori due to som libXml dependency, circa 2010.
| JamesSwift wrote:
| I've lost countless hours to "works on my machine but not
| coworkers" which turned out to be issues compiling nokogiri
| with native extensions. It broke all the time between macOS
| updates. Vagrant / docker were a godsend to removing that
| element of uncertainty.
| ascendantlogic wrote:
| My eye still twitches when I think about all the times it blew
| up my bundle installs.
| scelerat wrote:
| Started a new job in the past year and it's 50% rails, 50% react.
| Thought I would chafe after returning to ruby after ten years of
| nothing but JS and TS, but I quite like it.
|
| I only wish there was slightly less magic and a bit more
| declaration. It always weirds me out that Ruby just finds stuff
| without me having to 'import' or 'require' it. I have a love/hate
| relationship with much of the DSL stuff too (more 'magic') but
| overall, working with Rails and Ruby is quite nice.
| psadauskas wrote:
| > Ruby just finds stuff without me having to 'import' or
| 'require' it.
|
| That's either bundler (which `require`s every dependency you
| specify unless you tell it not to) or the Rails autoloader[1]
| (which goes hunting for a file that might define the constant,
| which also allows hot-reloading to work). Ruby itself requires
| you to `require` everything.
|
| [1]:
| https://guides.rubyonrails.org/autoloading_and_reloading_con...
| scelerat wrote:
| thanks!
| fourseventy wrote:
| haha the last line "For I once again have trouble installing
| Nokogiri." is so true
| jebronie wrote:
| Want something easy to host? Use PHP.
|
| Want something fast and simple? Use Go.
|
| Want something really fast and powerful? Use Rust.
|
| Want something ubiquitous, with lots of developers in the labor
| market? Use Java.
|
| Excuse my ignorance, but what is Ruby's strength?
| sam0x17 wrote:
| Productivity.
|
| Also you can short circuit a lot of what you said with Crystal
| lang (for speed) or Ruby on Jets (for ease of deployment,
| serverless, etc). At Arist (YC S20), we were able to fully
| rebuild our app in Ruby on Jets, pass a pen test, get SOC 2
| compliance, all in under 12 months. This frankly would have
| taken years if we couldn't lean on the Rails ecosystem, and our
| Appdex score is 0.999 typically, and we are prepared to 10-20x
| our current traffic because everything is serverless and each
| endpoint in each controller automatically becomes its own
| lambda upon deployment. Yet we can lean on the usual rails app
| structure, and use gems and features designed for rails.
|
| With things like Go, basic string operations like reverse
| string are left to the user to implement. In the ruby/rails
| ecosystem we have Active Support. To that same point, you also
| get the most fully featured ORM in the world in the form of
| ActiveRecord. No other ORM comes even close to the features AR
| provides.
|
| To your point though, we do use Rust for image and gif
| processing in one small lambda. I love Rust, but there simply
| isn't a web framework with the "sane defaults, everything
| included by default" mentality of rails yet. Cookie management,
| CSRF protection, etc., are largely left to the programmer to
| configure correctly, and it's simply a waste of time if you are
| trying to iterate quickly as a startup.
| jebronie wrote:
| Thank you. I sometime read that too much "magic" and
| abstractions can quickly get in the way when doing something
| complicated that is not covered by a heavely opinionated
| framework. Is this nonsense in your estimation, or is this
| something to look out for?
| sam0x17 wrote:
| This is very true if you don't actually understand and/or
| couldn't implement the magic yourself. As someone who has
| had to implement CSRF protection, cookie management, etc.,
| from scratch in other languages/frameworks, it's just a
| pure productivity boost when I use something rails-based.
|
| Where you can really get into trouble is if you take rails
| things for granted, and then go to a framework in another
| language. For example, you could have been brought up on
| rails and just take for granted that cookies are encrypted
| by default, and not realize that your supposedly server
| side cookie secrets stuff in express is being set in plain
| text.
|
| What I like about rails, though, is it tries really hard to
| stop you from doing something stupid. Strong Params is a
| great example of that. You have to really fight
| ActionController to get it to do something actually unsafe.
| By that same token, properly configured rubocop will catch
| 100% of potential SQL injection vulnerabilities.
| hnlmorg wrote:
| This reminded me of Black Perl, a poem written in Perl 3
|
| https://en.wikipedia.org/wiki/Black_Perl
| bachmeier wrote:
| One of my goals for 2022 is to write my first real web app. I
| want to understand things like authentication, creating an API,
| and security. My initial impression is that the JS/Node world is
| miserable. Rails looks 1000 times more pleasant.
| revscat wrote:
| > My initial impression is that the JS/Node world is miserable.
| Rails looks 1000 times more pleasant.
|
| God, yes. Especially with Hotwire [1], which advertises being
| able to do modern web apps with a minimum of JS. I've played
| around with it, and for me it completely eliminates the need
| for AngularJS/React/whatever.
|
| [1] https://hotwired.dev
| charcircuit wrote:
| Having tried both Node and Rails, Rails was a horrible
| experience. I hated every minute of it and will ignore any job
| listings including it. Your whole project is in a billion files
| and everything works by "magic." There is so much complexity
| and different flies that it sucks to work with. Meanwhile with
| Node you can start with a simple index.js and work your way up.
| fourseventy wrote:
| So you come from the Node ecosystem and your main complain
| about Rails is that the project has a lot of dependencies and
| files? lol
| NoSorryCannot wrote:
| I hear your point but the quantity of files produced by
| initializing a new rails project is very large, larger than
| an equivalent node project with server and framework. These
| aren't transient build artifacts either, they will live in
| the repo and may occasionally need attention.
| syspec wrote:
| Except with node you have to roll everything yourself, so
| jumping between different projects is a nightmare (each
| one a snowflake)
|
| Roll your own session management, auth, ORM, db
| migrations, html templating, CORS, cross site scripting
| protection, the list goes on and on.
| charcircuit wrote:
| When you create a project it makes like 100 files that are
| all automatically executed somehow. Nothing really includes
| them, but you know it works. These files arp part of your
| project, but they is also a bunch of rails stuff so it
| blurs what is and isn't a dependency for your project.
|
| With node projects they typically keep all of their
| dependency neatly under node_modules/ and you can clearly
| see how things are included and how things work.
| gwright wrote:
| FWIW It seems to me your comment about Rails is a more
| general comment re: frameworks.
|
| Learning a language/runtime takes some effort but much less,
| IMHO, than learning a framework. Doesn't matter if that is
| Rails, Django, Ember, Angular, iOS SDK, Android SDK,
| React+Redux+???, and so on.
| charcircuit wrote:
| I don't think so out of your list I've used the Android SDK
| along with a react and redux stack and I didn't get the
| name kind of feeling. With those you start out with a
| mainly clean project and everything makes more sense to me
| how it works.
| troxwalt wrote:
| Node and Rails aren't close to the same thing. I would think
| a better comparison would be Node - Sinatra.
| clairity wrote:
| ruby and rails is a much nicer, more complete, more consistent,
| and easier to learn ecosystem relative to js/node. and node is
| just the js server, so you need need a framework on top of it,
| like react/angular/vue/ember, to be equivalent. for most use
| cases, i really can't recommend the js-heavy route now that
| rails comes with hotwire (a transparent js framework for
| live/async _html_ transfer, rather than json).
|
| for authentication/authorization/security, it's great to learn
| by writing those from scratch, but unless you want that to be
| your career focus, you'd really be much better off to defer to
| battle-hardened libraries in those areas for any
| commercially-/publicly-oriented web app.
| tyre wrote:
| Rails is quite pleasant. There is a reason it became so
| popular.
|
| I'd recommend using rails without any front-end framework
| initially so you understand the HTTP calls going on. Just
| return HTML from your controllers (classes that run specific
| code when you hit an endpoint.) Build up from there and you'll
| get the hang of it while understanding what's happening
| underneath.
| Mikeb85 wrote:
| Rails is shockingly easy, especially Rails 7.
|
| Strait up, use Rails with all the defaults (ImportMap, Hotwire)
| but use Postgres and maybe Tailwind (`rails new myapp
| --database=postgresql --css=tailwind`). No extra gems are
| needed really (if anything, they add more complexity as not all
| are updated to be compatible with Rails 7).
| ReleaseCandidat wrote:
| Elixir with Phoenix and Liveview.
| Toutouxc wrote:
| I'm a Rails dev at $JOB, currently flirting with Phoenix, and
| while I think that both Elixir and Phoenix are really solid
| and even quite enchanting, I don't think they're the best
| choice for someone's first contact with webdev. Most people
| are more comfortable with imperative languages and Elixir
| only adds to the initial friction of not knowing the proper
| webdev lingo and concepts.
| dnautics wrote:
| > Most people are more comfortable with imperative
| languages
|
| Unscientific poll with possibly a biased sample: more
| people find functional easier to work with. But telling,
| the difference is _more_ pronounced among bootcampers and
| informally educated programmers than formally educated
| programmers
| https://twitter.com/DNAutics/status/1459348334007787526.
|
| Not to mention that Elixir is basically "mostly functional
| but you don't have to faff around with monads or anything
| to do imperative".
| jebronie wrote:
| When you learn Rails, you mostly just learn Rails. If you want
| to learn the nitty gritty details I think a different language
| might be better suited. I think Go strikes a nice balance
| between "doing everything yourself" and "just putting pieces
| together" If you constrain yourself to the standard library.
| tjpnz wrote:
| Definitely consider Python with FastAPI too. I got a simple API
| up and running in a few hours with OAuth2. Auth comes batteries
| included and wasn't nearly as complex as I feared.
| ascendantlogic wrote:
| Rails and Django are both very pleasant and have enormous
| ecosystems where every imaginable problem has been encountered
| and "solved". It's been a while since i was writing Rails but
| from what I gather Rails 7 is a homerun release and has a lot
| of buzz around it.
| matwood wrote:
| I don't know about miserable, but definitely easier to get side
| tracked deciding what libs to use. Rails tends to push users
| down a path that works for most things. This makes it much
| easier for new users. JS leaves it up to the developer to pick
| and choose what libs which is not new user friendly.
| burlesona wrote:
| Very well done, esp. the nokogiri bit :D
|
| That said if you're in Ruby land and _do_ want something
| "shiny", I'd encourage you to look at Jeremy Evans work (Roda and
| Sequel in particular) and some of the broader ecosystem beyond
| Rails. There's a lot of good stuff beyond just Rails :)
|
| https://github.com/jeremyevans
| Lio wrote:
| I'd also suggest Jeremy's book Polished Ruby[1]. It's excellent
| IMHO.
|
| 1. https://www.oreilly.com/library/view/polished-ruby-
| programmi...
| scruple wrote:
| I no longer write Ruby professionally but in my last 18-24
| months of Ruby work I leaned _heavily_ on some of Jeremy 's
| excellent work with roda, sequel, and others (forme, erubi,
| rack-unreloader, etc.). Top notch work, truly. I had no idea
| that he had written a book, thanks for pointing that out, and
| I'll definitely be picking a copy up.
| brightball wrote:
| I use Sequel and the Parallel gem all the time. Good stuff.
| jack_riminton wrote:
| I like that the Ruby community has embraced the fact it is no
| longer cool.
|
| I recently interviewed for a ruby/rails job where the dev team
| had come from a previous start up that tried to port an existing
| Rails app to a React/Microservices one with disastrous results.
| For this job they were relishing coming back to a monolithic
| Rails app. I hope this trend continues!
| mperham wrote:
| A sports car might be cool but it's terrible as an Uber.
| Context is important when making any choice, tech stack or
| otherwise.
|
| Ruby and Rails are pragmatic choices for building a business,
| they may not be cool anymore but they are focused on developer
| happiness and productivity.
| ryanbrunner wrote:
| My latest job is at a place where we have an extremely 'old-
| school' Rails app. The vast majority of UI is server-rendered
| HTML, Javascript (at least that we wrote, we do use Turbo) is
| very, very minimal, and we're just one very large service.
|
| The previous place I was at was a microservice heavy (the count
| of services was almost on par with the number of developers)
| React and Node based application.
|
| I'm orders of magnitude more productive with the Rails app,
| it's more well regarded by our customers, and using it, there's
| no obvious telltale signs that it's not using the modern SPA
| approach.
| jack_riminton wrote:
| I'm not surprised.
|
| I have a theory that there's a perverse incentive for
| startups to make their work more expensive and therefore more
| complicated. It's related to this quote by Paul Graham about
| funding:
|
| "VCs don't invest $x million because that's the amount you
| need, but because that's the amount the structure of their
| business requires them to invest. Like steroids, these sudden
| huge investments can do more harm than good. Google survived
| enormous VC funding because it could legitimately absorb
| large amounts of money. They had to buy a lot of servers and
| a lot of bandwidth to crawl the whole Web. Less fortunate
| startups just end up hiring armies of people to sit around
| having meetings."
|
| (from here http://www.paulgraham.com/venturecapital.html)
|
| For those that aren't VC funded I think that a lot can be
| explained by cargo-culting; "If startup X is using
| Node/React/Redux/microservices and they just scored a 20m
| Series A then we'd better do it too"
| Zababa wrote:
| > For those that aren't VC funded I think that a lot can be
| explained by cargo-culting; "If startup X is using
| Node/React/Redux/microservices and they just scored a 20m
| Series A then we'd better do it too"
|
| Part of it is also from employees: "everyone else is using
| Node/React/Redux/microservices, if I can push my company to
| do it I will have more relevant skills for the market". I
| often hear that for k8s too.
| sam0x17 wrote:
| Yes, I find that community interest tends to peak about 10
| years before business interest peaks in any given language.
| Right now we have more companies using Ruby/Rails than perhaps
| we ever did, but community interest peaked 10 years ago.
| Perhaps we'll see something similar with Rust a decade from
| now.
| andrei_says_ wrote:
| "Cool" is so subjective. When I want "cool", I re--watch Le
| Samurai.
|
| Ruby is elegant, brings me joy and puts me in a state of flow.
| eximius wrote:
| I think Ruby might be the antithesis to Java.
|
| For all that I despise Java's ridiculous boiler plate, I always
| know exactly what's going on.
|
| In Ruby, I feel like there are unknowns in every file.
|
| I hate Java, but Ruby makes me miss Java.
| weatherlite wrote:
| > For all that I despise Java's ridiculous boiler plate, I
| always know exactly what's going on
|
| Not my experience at all when doing Spring Boot, talk about
| magic. Rails looks dead simple compared to that.
| marquis_andras wrote:
| This has been my experience too.
|
| I constantly fear Spring Boot magically reconfiguring itself
| based on what it finds in the classpath, and half the
| codebase being annotations and import statements.
|
| I've found the metaprogramming in Ruby much easier to
| understand and teach than Java's reflection and annotation
| processing.
| weatherlite wrote:
| I really gave Spring Boot a shot, it's just way above my
| head. Never felt like I had a good sense of knowing what
| the heck was going on what with all the Beans and
| annotations. But my Java was pretty poor - that could be
| the reason. However I never had this difficulty with
| Rails/Django/Node, they all felt pretty intuitive to me.
| eximius wrote:
| Perhaps I've only had to deal with sane Java codebases - I
| feel like magic is not the norm in Java.
|
| Magic is built into the Ruby language, what with everything
| being "message passing" under the hood.
| halfmatthalfcat wrote:
| Managing different projects with different Ruby versions with
| rbenv has been the bane of my existence the past couple weeks.
| Why isn't this experience fleshed out better by now?
| regularfry wrote:
| Personally I get very good mileage out of the ruby-
| install/chruby/rv trifecta. RVM and rbenv tried to do too much
| for my liking.
| nitrogen wrote:
| Use rvm with .ruby-version (and optionally .ruby-gemset) files
| in each project. RVM hooks into the cd command so it's
| automatic.
|
| For CI scripting you use "rvm (path) do (command)."
| jamesgeck0 wrote:
| rbenv also automatically swaps versions based on .ruby-
| version files. I believe it accomplishes this by wrapping the
| ruby binary with a script that checks your project directory;
| it doesn't touch cd.
| rubyist5eva wrote:
| I love Ruby - Rails has been my day job for the past decade and
| my life is so much more pleasant when working with it than the
| odd time I've ventured off into things like Go or Java.
|
| For personal things, my bread and butter is Sinatra and Sequel
| and that's a great combo as well.
|
| My only real issue with it is differences in building native
| extensions on macos vs linux, usually need to set different
| compiler flags in the bundle config. Otherwise, works great.
|
| ie. # ~/.bundle/config
|
| ---
|
| BUNDLE_BUILD__PG: "--with-
| pg_config=/usr/local/Cellar/postgresql@10/10.19_1/bin/pg_config
| --with-cflags=-Wno-error=implicit-function-declaration"
|
| BUNDLE_BUILD__THIN: "--with-cflags=-Wno-error=implicit-function-
| declaration"
|
| BUNDLE_BUILD__FFI: "--with-cflags=-Wno-error=implicit-function-
| declaration"
| nitrogen wrote:
| I'm curious, do you know what function was being declared
| implicitly? That's really atypical in modern C code, so there's
| probably a missing #include somewhere that could be fixed
| upstream.
| weatherlite wrote:
| So what's the upside for you with Sinatra? I'm embarrassed to
| having been doing Ruby for 8 years and never touching it. Just
| never saw the need - Rails in API mode seems adequate.
| vidarh wrote:
| Sinatra is small (the main part is about 2k lines). That's
| the main upside and/or downside depending on your philosophy.
| As someone who likes to know what goes on, I love Sinatra,
| but Sinatra does force you to pull in other code as needed
| yourself - you don't get handheld the way you do with Rails.
|
| If you need the kitchen-sink you might as well use Rails. But
| often you might need only a tiny fraction, and Sinatra is
| small enough to read. If you need a "halfway house" between
| Sinatra and Rails, Padrino layers nicely on top of Sinatra
| and you can pick and choose which parts of Padrino you want
| to use.
|
| My preferred stack is Sinatra + Sequel as the ORM, but if I
| need something "quick and dirty" I might throw Padrino on top
| as it's lightweight and unopinionated enough it doesn't get
| in my face the way Rails does.
|
| The caveat is that if your team is used to Rails chances are
| they'll hate you if you make them use Sinatra and they don't
| share a dislike for big frameworks.
| jamesgeck0 wrote:
| Sinatra and the Camping microframework were an enormous
| help for me when I first started learning Ruby. Being able
| to read a minimal implementation of routing (for example)
| helped dispel a lot of the magic that I got hung up on in
| Rails.
| Mikeb85 wrote:
| It's too bad Ruby isn't seen as 'cool' anymore, it's just so easy
| to be productive in it. And now MJIT, YJIT and TruffleRuby are
| making some very impressive performance gains. Rails is also
| better than ever and I still can't think of a better language for
| scripting.
| swat535 wrote:
| I love the fact that Ruby is no longer cool anymore and has
| finally matured enough that one can build a stable system on
| top of it. It now has been battle tested and powers some of the
| biggest platforms on the web.
|
| I couldn't be happier with the direction that Ruby 3.0 and
| Rails 7.0 are taking at the moment. We have businesses to run
| and Ruby allows just for that. It's boring, it's stable and
| will deliver results.
|
| I wouldn't pick it to build the next Discord though.. One must
| use the right tool for the job.
| pantulis wrote:
| What was cool was Rails, IMHO, and Ruby was the surprise inside
| it.
|
| I've had my own personal Advent of Code these holidays, coding
| a small API for a personal need. Ruby (Sinatra) took one
| morning to full deployment in Heroku. Then I tried Crystal
| (Kemal) and it took me a couple of days to figure out how to
| map JSON to Crystal data structures. Then I rewrote it again in
| Rust (Rocket). Two weeks till I figured out, well, almost
| everything.
|
| My opinion: they will take dynamic typing from my dead cold
| hands.
| sam0x17 wrote:
| Hot take: I'd love to see JSON die and get replaced with
| something more strongly typed and safer to work with. What,
| I'm not sure, but it is, as you say, a major pain point no
| matter what language you're in. Either it's easy to work
| with, but insecure, or it's difficult to work with.
| mhoad wrote:
| I moved to gRPC and protobufs for this exact reason. It's
| so nice to work with.
| brigandish wrote:
| I also took a while to get used to the typing in Crystal but
| once you do get it, it's worth the effort IMO. I occasionally
| still fire up Ruby but if I have anything more to do than a
| quick command-line command, I use Crystal, so many less
| problems.
| sam0x17 wrote:
| Crystal is also my go-to for writing a quick script to do
| something.
| Lio wrote:
| I think I'd be more interested in Crystal if it was easier
| to integrate into existing ruby code bases via something
| like the FFI.
|
| As it is from Ruby 3.0 we have built in optional static
| typing and with interesting projects like Sorbet
| Compiler[1] we have the option to statically compile making
| use of that. It's still WIP I believe but it's giving ruby
| devs some cool options.
|
| 1. https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-
| comp...
| pantulis wrote:
| Crystal was overall a pleasant experience, which I cannot
| say for Rust. Although it was probably my fault: 1) for
| being "rusty" as a programmer myself, and 2) having zero
| experience with Rust. I want to believe that once you get
| over the learning curve in Rust development speed becomes
| much higher.
|
| Surprisingly, Crystal seems to be much leaner in runtime
| size than Rust, with similar performance (although the use
| case is so simple that even good old Ruby is fast enough).
|
| But then again, I feel you cannot beat Ruby in terms of dev
| productivity.
| m12k wrote:
| I've heard it described that Rust allows you to write
| programs in a specific way. If you try to write them in
| any other way, you're going to have a very, very bad
| time, and fight the borrow checker every step of the way.
| But if you embrace that way of writing programs, it makes
| it pretty easy, you get really good error messages, and
| as a cherry on top your program will be provably sound in
| a way pretty much no other language can guarantee. So it
| all comes down to whether you're interested in learning
| that specific way of structuring programs.
| syspec wrote:
| The real cherry on top is that you can put "written in
| Rust. Modern. Fast" on your project description.
| pantulis wrote:
| That's true, but then it is not "allowing" or "enabling"
| me, it is "forcing" me to do it that way. Of course, the
| Rust compiler is catching a gazillion bugs beforehand, so
| this is cool: you finally feel like your program will
| have no bugs once you manage to compile it.
|
| Error management through Option values, the borrowing
| checker... they are cool technologies for a C-like
| language, but they are not palatable at the beginning
| (maybe they are an acquired taste like beer?). I am
| tempted to stretch it a little bit more and see how
| productive I can become writing Rust code, but also not
| so sure about the effort.
| rattray wrote:
| Surprised you didn't try Elixir? What about Sorbet?
| syspec wrote:
| I would love to try elixir, but JetBrains still does not
| have an IDE for it. I'm addicted to their IDEs.
|
| I did try the community made plug-in for elixir, but had
| trouble getting the debugger to work which was a show
| stopper for me.
| dnautics wrote:
| You probably don't want to use an ide-driven debugger for
| elixir, you'll want to use :dbg which has a different
| "conceptual model" than what you are used to and doesn't
| map well onto Conventional debuggers.
|
| It's simply not the same due to the extreme high degree
| of concurrency in the beam VM
| pantulis wrote:
| Well, I did a little bit of research on Elixir a couple of
| years ago, so I felt like I had that covered. Using Kotlin
| + Ktor was also tempting.
| dnautics wrote:
| it's way different now. I've actually never deployed
| elixir on a deployment service till last week (either:
| "was R&D and never deployed to prod", "I ran elixir on-
| prem inside a DC", "my prod environments have been
| managed by ops team"). It was surprisingly easy, had my
| first deploy (including installing the service provider's
| tool) in about... 3 hours?
| ace33 wrote:
| "I still can't think of a better language for scripting."
|
| Python I find equally if not more simple. Would you agree?
| weatherlight wrote:
| It's not about simplicity, It's about expressivity.
| busterarm wrote:
| Python forces you to wrestle with its'/Guido's
| idiosyncracies. It wears them on its sleeve almost like a
| badge of honor. You may enjoy them, but I don't. Lack of Tail
| Call Optimization is a huge red mark for me, personally.
|
| Ruby, on the other hand, is literally meant to delight you
| with its choices/options/expressiveness and I find that it
| absolutely delivers on that promise.
| [deleted]
| kouteiheika wrote:
| > Python I find equally if not more simple. Would you agree?
|
| Simple, yes. But when I want to write a script as fast as
| possible with the least amount of effort I don't want simple.
| I want convenient and powerful. Many things which in Python
| take multiple lines in Ruby are simple one liners.
|
| There's a certain dichotomy between Ruby and Python that I
| also see in many other pairs of languages. One language is
| simple, easy to learn and easy to read (Python), but is not
| as powerful or convenient to write. The other language is
| more complex, harder to learn and harder to read (Ruby), but
| is more powerful and convenient to write.
|
| It seems like most people prefer the first category, which I
| think is why languages like Python or Go are so popular.
| There's nothing wrong with that as it's a tradeoff, but I
| personally prefer the second category, which is the reason
| why I do all of my scripting in Ruby and not in Python like
| everybody else.
|
| Simply put I don't really mind the extra complexity since it
| is essentially mostly a one time cost, so I always pick
| whichever tool will make me more efficient in the long run.
| And out of the two (Python and Ruby) that's Ruby. (With a few
| exceptions like, e.g. machine learning, where you don't
| really have a choice.)
| vidarh wrote:
| Python is entirely unreadable to me. Not in the sense that I
| _can 't_ but in the sense that I have to put effort into it
| in a way I don't have to with Ruby. Part of it is undoubtedly
| that I'm very picky about syntax and formatting and Python
| has made a lot of choices that are pretty much the opposite
| of what I want, but I just can't get used to reading Python
| code.
| sodapopcan wrote:
| Equally maybe. Simpler? I'm not sure, I don't know Python
| very well.
|
| A couple of things I found surprising about Python was having
| to do the whole `re.compile` thing instead of just `//` in
| Ruby. Also, no one will ever convince me that a list
| comprehension is simpler than `map` and related functions.
| Also, it's hard to beat the convenience of libs that let you
| do `1.day.ago`.
|
| Ruby gets complicated when people start throwing around
| metaprogramming where they shouldn't.
|
| I do like Python's file == module. Python seems like it would
| be a good functional programming language but it goes and
| only allows for single line lambdas.
|
| Again, I don't know Python very well.
| revscat wrote:
| > Ruby gets complicated when people start throwing around
| metaprogramming where they shouldn't.
|
| This is true. Thankfully it appears that the broader Ruby
| community has recognized this as well, and has moved away
| from metaprogramming to a large extent. It's still there,
| but you don't see it utilized nearly as frequently as you
| once did.
| sodapopcan wrote:
| I'm fine with it for libraries. In fact, its use in
| libraries is a lot of makes ruby great! It goes too far
| when people start sprinkling it in business logic making
| it impossible to find where anything is defined. I'd say
| you'd either have to go full-lisp and create an entire
| DSL for your domain (and document it) or keep it
| completely out of business logic (which, as you say, the
| community as a whole has pretty much figured this out).
| gilbetron wrote:
| Having done both professionally, I'll take Python any day of
| the week. The "Expressivity" lauded by Ruby fans translates
| into a lack of readability. But the things that drives me
| crazy is the optional/alternative syntax of ruby.
| nitrogen wrote:
| Ruby is a lot like spoken language in that regard. When the
| many ways in which to do things are chosen well, Ruby reads
| like pure poetry. For that I will always enjoy Ruby.
|
| Moreover, the choice of which idiom to use conveys the
| intent and mindset of the author.
|
| But like any complex language, it's also possible to write
| very unpoetically, and like any complex language,
| readability is a function of familiarity with the
| language's syntax and idioms.
| Mikeb85 wrote:
| Nope. Can't stand that Python uses built-in functions for
| basic things like list, map, fold, etc... instead of methods
| on base classes. Here's a super basic example. Add one to an
| array [1,2,3] and print results.
|
| Python: print(list(map(lambda x: x + 1, [1,2,3])))
|
| Ruby: print [1,2,3].map {|x| x + 1}
|
| So much more readable, easy to write, etc... Ruby keeps it
| consistent by making pretty much everything an object and you
| just call methods. Even Haskell has dot notation to chain
| functions since it's just so much easier to read and write...
| travv0 wrote:
| > Even Haskell has dot notation to chain functions since
| it's just so much easier to read and write...
|
| Are you referring to function composition?
| iterati wrote:
| print([x + 1 for x in [1,2,3]])
| KerrAvon wrote:
| This really goes to the heart of the problem with modern
| Python. It's lost the simplicity of the language which
| was the whole point of it in the first place. OO and
| functional paradigms were bolted on to varying degrees of
| success, but an outsider can no longer look at average
| Python code and understand it at a glance.
| trufas wrote:
| To be fair, you almost never should use the map builtin
| instead of the pythonic equivalent, list comprehensions.
|
| `print([x + 1 for x in [1, 2, 3])`
|
| I agree that the ruby approach is better in terms of
| consistency, but most developers will be aware of the
| conventions python uses.
| runjake wrote:
| You're splitting hairs about what the op said. How about
| len() ?
| marquis_andras wrote:
| [1,2,3].__len__()
| junoper wrote:
| Python, I think, has n number of ways of doing the same
| thing while Ruby's everything is object approach forces
| you down a single approach. So while reading ruby code,
| you usually don't have to shift your mental model from
| OOP to procedural/list comprehension etc.
|
| If Ruby gets a good machine learning library on par with
| something like Pytorch, I am sure many folks will shift
| to it and we might see new DSL emerge.
| regularfry wrote:
| Which is ironic, given that "There should be one-- and
| preferably only one --obvious way to do it" is in PEP 20.
| busterarm wrote:
| The vast majority of Python code that I have had to
| interact with professionally seems to ignore the fact
| that PEP even exists.
| Mikeb85 wrote:
| Ok, that's a nicer result (obviously I don't write Python
| lol) but still seems inconsistent to me (putting the
| function before the array) considering Python is an OO
| language and most people are going to be writing methods
| for classes where you call methods with dot. I just
| remember list comprehensions from Coffee-script and not
| going to lie, I hate them. It's like reading backwards.
| knodi123 wrote:
| > still seems inconsistent to me (putting the function
| before the array)
|
| I'm experienced in ruby, and learning python for a
| project. I don't think I'll ever not wince when using
| python's ternary;
|
| ruby: size = (waist > 30) ? 'large' : 'small'
|
| python: size = 'large' if (waist > 30) else 'small'
| cle wrote:
| I've always assumed this was to maintain syntactic
| consistency with comprehensions like [x for x in arr if x
| > 2].
| iterati wrote:
| Python is a multi-paradigm language, of which OO is one
| paradigm it supports.
| Mikeb85 wrote:
| Ruby has map, filter, reduce and a bunch of other
| functional methods. It's more about the consistency of
| wondering what's a function versus what's a method and
| then things like list comprehensions and for loops.
| Python also doesn't have a lot of the goodies of a real
| functional language, it encourages for loops and seems to
| be even more procedural than Ruby but less OO?
| jimbokun wrote:
| Ruby is a strongly OO language, which arguably also has
| better support for functional programming than Python.
| j_mo wrote:
| This is what really put me off Python as somebody who
| learned Ruby as their first proper (professional 9-5 usage)
| programming language.
|
| There are other things too, like how print used to be
| written like a keyword not a function for some reason, and
| enforced indentation instead of braces or "end" keywords,
| all just really bugged me. It felt like somebody made YAML
| Turing complete...
| regularfry wrote:
| For me it's annotations. Looked at from a distance, what
| appears to have happened is that the implementation hit a
| certain level of complexity before class methods got
| implemented, and it ended up being easier to do them with
| "@classmethod" than with "def self.foo", or to fix whatever
| reason it is that makes "def foo(a,b,c)" not act like a
| class method if "a" isn't "self".
| wfleming wrote:
| Really depends on what you mean by "simple". "Simple" is one
| of those descriptors that gets tossed around a lot in
| programming by rarely with a clear definition.
|
| Python is a "simpler" language with its preference for "one
| obvious way", and it does tend to support fewer paradigms
| than Ruby. Ruby is a more complex language, supporting many
| approaches. But if you are familiar with the various
| approaches, that can be "simpler" if it allows you to choose
| the most fitting approach for whatever problem you have at
| hand.
|
| To put it another way, "simple" can mean "the language is
| small/has an obvious way it wants you to do things", or
| "simple" can mean "the language is flexible enough to be used
| to model your problem in the most appropriate way". Python is
| the first kind of simple, Ruby is the second.
|
| IMHO Ruby is much more expressive than Python, and the stdlib
| is better designed and less crufty. Ruby really has one of
| the best stdlibs around, I think, and a lot of languages
| could learn a lot from it - particularly the design of
| `Enumerable`.
|
| So I prefer Ruby when I have the choice. Part of that is
| probably just familiarity, but I've been a full time dev on
| both Ruby & Python projects for long stretches of time so I
| think I'm in a decent position to compare them. My personal
| preferences/taste is another aspect, of course, and there's
| no objective accounting for that.
|
| The case where I often will prefer Python is if I'm scripting
| something that needs some degree of portability. If you pick
| a random Linux box it's much more likely to have some version
| of Python installed than Ruby, so if I'm writing something
| that should be easy to copy to a box and use without
| additional setup, I'm more likely to pick Python.
| rahoulb wrote:
| Personally I think writing Python is like writing maths,
| writing Ruby is like writing English.
|
| Depends which one you prefer.
| vidarh wrote:
| Whether or not it is true, that would certainly explain why
| I prefer Ruby so strongly over Python.
| marquis_andras wrote:
| Ruby has the ability to automatically download required gems
| in single-file scripts via bundler. I don't know of any
| equally convenient alternative for my python scripts.
|
| e.g. https://gist.github.com/destiny-
| index/2a2e7e586bb9cd6e5c3000...
| AtlasBarfed wrote:
| I am not a Python or a Ruby dev.
|
| The Ruby devs I know are overall great devs
|
| The Python people are second-rate.
|
| Ruby produced tons of good software as a framework base
| besides Rails.
|
| Python? Eh.
| linspace wrote:
| I'm a Python dev. The python devs I know are average on
| average. I have never met a Ruby dev. But I'm sure I'm
| first rate!
| dwaite wrote:
| They are surprisingly different.
|
| Ruby has a focus on developer joy and productivity. In some
| cases this comes to the detriment of language simplicity, and
| existing features can complicate language evolution.
|
| Surprisingly with this complexity Ruby has had a bit more
| success with optimized implementations than Python, such as
| Truffle Ruby.
|
| Ruby is a bit more multi-paradigm than Python IMHO, and has
| been jokingly called a "language for connecting adults". One
| can monkey-patch override division to return fractions, with
| the person maintaining the project deciding if this is a good
| idea or not. This can potentially make projects with a large
| number of dependencies harder to debug, which interestingly
| seems to have created some push-back on importing lots of
| arbitrary dependencies.
|
| With both Python and Ruby, you wind up having divisions
| between dependencies because of the poor mismatch between
| different paradigms - for instance, libraries built to work
| with Python Twisted or Ruby EventMachine for I/O, or
| libraries built to work generically or to integrate into say
| Django on Python's side or Rails on Ruby's side.
|
| Interestingly the communities seem to have different key
| focus areas - Ruby has historically been very focused on
| testing (cucumber and selenium for instance) while Python has
| had a lot of focus on documentation (pydoc and sphinx).
| Oddly, neither really has had a noticeable literate
| programming push.
| cipheredStones wrote:
| Is "language for connecting adults" an autocorrect of
| "language for consenting adults"?
| dwaite wrote:
| Hah yes it was
| jmuguy wrote:
| A quick Haiku Bundle hung again? Ah, its
| just Nokogiri. With native extensions.
| samb1729 wrote:
| Haikus are 5/7/5 syllables, this is 5/7/6
| jjgreen wrote:
| To-con-vey one's mood In sev-en-teen syll-able-s
| Is ve-ry dif-fic
|
| John Cooper Clarke
| dankwizard wrote:
| Oh I like this!
| troysk wrote:
| claps!!!
| vlunkr wrote:
| Here's my hot take on Ruby (as a big Ruby fan): Ruby libraries in
| general have bad documentation. Some other languages I've worked
| with in the same time frame that typically have better docs are
| node.js/regular js, Python, Golang and Elixir.
|
| For many gems, all you're going to get are a couple of examples
| in the readme. If you're lucky, there will be some generated
| rubydocs, but quite often that isn't helpful either, because it's
| just a list of method names with no descriptions, or it's not
| clear at all which pieces are intended to be the public API. Even
| Rails has this problem sometimes. The guides are very good, but
| when I need to do something off that beaten path, I'm often
| reaching for stackoverflow.
| mrinterweb wrote:
| My favorite documentation trick for ruby is to run your own doc
| server locally documenting the versions of the gems you are
| using. I use the "yard" gem.
|
| yard server --gems --reload
|
| For rails and ruby docs, I use Dash (on Mac). I use Dash for
| local docs for other languages and systems as well. Just a
| handy tool for local docs.
| dragonwriter wrote:
| > Here's my hot take on Ruby (as a big Ruby fan): Ruby
| libraries in general have bad documentation. Some other
| languages I've worked with in the same time frame that
| typically have better docs are node.js/regular js, Python,
| Golang and Elixir.
|
| JS libraries, IME, are often very bad, though there are some
| good ones. But, on Ruby, I would go further and say that,
| especially compared to Python which is so similar in many other
| respects, Ruby (and not just the library ecosystem,) has a very
| bad documentation culture.
|
| In fact, _more_ than in libraries, this is evident in the
| first-party documentation available on the language homepage.
| vlunkr wrote:
| I agree, JS is kind of all over the place.
| ecshafer wrote:
| I am a newbie to Ruby. I hadn't touched it before a few months
| ago, after coming to Shopify. But I really think Ruby is a
| fantastic language, I would much rather program in Ruby than in
| Python, JS or Java right now. It reminds me of small talk and is
| just nice to write. And Rails, wow Rails is such a good web
| framework, there's no surprises, and its opinionated nature makes
| it really easy to come up to speed in even a big code base.
|
| Tech trends are weird, and the "hot new thing" is usually based
| off of some blog post or tech company saying its cool. Plus with
| things like TruffleRuby and Sorbet and JITs, there's some
| interesting development in the ecosystem.
| vidarh wrote:
| > It reminds me of small talk
|
| That's not a coincidence. Ruby is heavily Smalltalk-inspired
| syntax with a dash of Perl and Awk thrown in (notice all the
| "$"+single character bits, as well as a look at the "-n"
| command line) wrapped in nicer syntax.
| sdze wrote:
| How many nuclear power plants do you need to run an ordinary RoR
| webapp?
___________________________________________________________________
(page generated 2022-01-10 23:01 UTC)