Ruby in Twenty Minutes (2006) | Hacker News Reader

Ruby in Twenty Minutes (2006)

ruby-lang.org

154 pointsmooreds112 comments

I'm a self-taught junior developer who started with Ruby in 2016. I've very much enjoyed the experience so far, and am currently rather invested in Rails, though I'm preparing to branch out into other areas of web development (I'm looking at you, React).

This thread is really opening my eyes to the sheer vitriol that gets directed at Ruby outside of its own echo chamber.

I get that it has performance issues (to be addressed in Ruby 3) and interest in Rails is now less than half what it was at its peak.[0] Everyone has very strong opinions, and when people start soapboxing like they are in this thread, nobody learns anything.

At this point, honestly, I just think the rest of the community could use a little bit of Ruby's characteristic niceness.[1]

[0]: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0...

[1]: https://en.wiktionary.org/wiki/MINASWAN

The people who complain about Ruby performance are really missing the the forest for the trees, IMO. Most people are using Ruby for web development. Web development has hundreds of milliseconds of latency that there is absolutely no way to get rid of (in the form of transit to the server and back to the client). Then you're doing a bunch of I/O. The actual amount of time spent executing Ruby is just not significant in all of that. Ruby could be 2x faster than it is now and it would probably make a sub-10% difference in response time for most of the endpoints in most of the Ruby/Rails apps I've encountered.

I'm getting 74ms of total latency loading this page; much less than hundreds.

You are correct that there are latencies involved that don't involve executing code, however my experience with Ruby, Python, and PHP is that they contribute a significant portion of the total latency in the most basic CRUD LAM(P|R|Py) stacks. Once you start getting into much heavier applications such as CMS's or eCommerce app code execution can easily dominate request latency by more than an order of magnitude.

I'm almost certain that you're hitting a cache when you load this site (I'm getting a 40ms ping to news.ycombinator.com, which would leave about 30ms to render a page here, and these pages are complex enough that the DB query would be more than 30ms). Caching is a thing you can do with Rails, you know...

Look, I spend a fair amount of time looking at the performance monitoring tools for the Rails apps I deal with. Ruby execution time just isn't that big of a deal most of the time. And when you have a monster of a page and it is an issue, you use caching, like you do with every other language/framework.

Using Tcl for the same purpose in the first .com wave taught me to never use again in production a language without JIT or AOT on their canonical toolchains.

You really note the difference with that load falls down and then there are this weekend all nighters converting script code into C.

JRuby can leverage HotSpot via invokedynamic and has been able to partially leverage HotSpot for about 10 years. It's in production use at places like SoundCloud and TalkDesk.

Ivo Anjo (now working for Amazon) has talked about their use of JRuby at TalkDesk: https://ivoanjo.me/blog/2017/01/29/benchmarking-jruby-invoke...

I have followed most of the JRuby talks at JVM Language Summit and the efforts lead by Charles Nutter.

However I did mentioned "on their canonical toolchains" on purpose, as not many in the Ruby community would welcome Java on their computers and rather fork a C compiler as pseudo-JIT.

JRuby is canonical and both teams contribute to ruby/spec. JRuby does not alter the language unlike Rubinius.

MJIT uses C to mimize the maintenance burden on the core team. Using LLVM would mean either pinning to an LLVM version as Rust does or supporting what would probably be 6 different versions of IR to support as far back as say, Ubuntu 14.04.

Faire enough regarding JRuby.

As for MJIT, it is not like LLVM would be the only way to implement a JIT compiler, plus the impact of forking a C compiler and linker is quite considerable versus an in-process JIT.

CRuby needs a full C compiler and linker for JIT to be able to inline things like object allocation.

The alternative proposal which Evan Phoenix explored was to compile the VM and standard library into LLVM IR and keep it for use when JIT compiling Ruby methods.

If you look at the JIT compiler in Racket which is maintained by a small team like CRuby but does use a custom backend, then it has some big limitations like a maximum of 3 function args.

Implementing something like C1 would be an enormous amount of work.

I'm not sure what you mean about a maximum of 3 arguments, but the Racket JIT runs on all functions no matter how many arguments they take.

Hah, thanks! I was reading the Racket JIT source code late and mixed something up.

Certainly, as in almost every JIT I know of, there are limits on which things get optimized in certain ways, which may be what you saw.

Execution speed of your server code is critically important in today's atmosphere. It's a lot easier to scale an application than the database behind it (e.g, spin up a few more VMS/containers vs. partitioning your db - one is a 2 minute task, the other a bohemian effort).

That being said, I enjoy Ruby a lot, and mostly enjoy working on Rails codebases (depends on how the front end is built, as Rails particularly _doesn't_ prescribe any form of convention here). I wish they worked on improving the front end story like Laravel has.

If it's easy to scale your application servers horizontally, then language execution speed isn't very critical. Speed is critical for the things which are hard to scale (like your data store).

And everyone is coming at this conversation like caching isn't a thing that you do on any high-traffic site (and lots of low-traffic ones too).

Unrelated to your main point, but what is a bohemian effort?

s/bohemian/herculean ?

50ms response time, as compare to 50ms Round trip. I don't see that as a Sub 10% difference. And that is assuming most of the Rails Apps does 50ms response time. Yes, there may be 30ms spent in DB, in parts because of the ORM, but the whole languages and framework still needs a lot more speed to become that "10%" difference.

With the typical website loading megabytes of JS to serve a SPA, which itself make additional requests, plus tens to hundreds requests for ads and third party tracking, how is the performance of Ruby relevant? Again I’m not talking about advanced and scaled up use cases, just typical websites and web apps. What’s the point of a low latency if it’s to serve loaders?

In my experience Roda/Sequel beats almost any other combination of application language / DB (ORM)

Speed stats - https://www.techempower.com/benchmarks/#section=data-r14&hw=...

If you're looking into React, have a look at this.

https://github.com/reactjs/react-rails

Sets up Webpack and directly integrates into your templates with ERB tags like

<%= react_component("HelloWorld", { greeting: "Hello from react-rails." }) %>

(First argument is name of component, second argument is a hash of props)

Easy as pie!

I've never learned ruby in an intentional manner, but whenever I needed to write some, I found that things just worked the way I expected it to, and the docs were always super helpful. To be fair, I haven't built anything large scale with it, but my experience with the language has been anecdotally pleasant.

I am having the opposite feeling about Python. Seems everyone is using python these days and I am constantly running into things which I like just a bit less as I am trying it for side projects. Things just don't quite work the way I expect them to.

Same. I’ll get downvoted for saying this but I find that it is a very overrated language that is popular mostly because of its dominance in fields that are currently in the vogue, i.e. ML/AI.

(I know Django is a thing, but that has always been in the shadow of Rails, and rightly so.)

In 2005 I had to choose to invest in learning either Ruby or Python as a primary language for writing a fairly complex piece of technical software.

I looked into Ruby and it struck me as being a truly aesthetically pleasing language, and since it espoused the "principle of least surprise" -- with caveats, naturally -- most Ruby code tended to be straightforward to read.

Python on the other hand, while clean -- I came from Perl -- had a fair bit of ugliness like the "self" argument in class methods, and the "dunders" in dunder methods (__init__). That said, the Python ecosystem, especially in the numerical computation space, was far ahead of Ruby's at the time, so I chose Python. It worked out really well and allowed me to accomplish what I needed to. To this day I have no regrets choosing Python.

Compared to many languages (like Haskell etc.) Python's design isn't the most aesthetically pleasing or orthogonal or clean. But being a Dutch design, at least initially, it was very pragmatic. And Python is by no means ugly on an absolute scale, on the contrary. It’s just not as beautiful as some others.

Python's main advantage is the energy behind it: to this day there are no converged alternatives to Numpy or Pandas on Ruby.

I can't help but wonder that if in an alternate universe/timeline, Travis Oliphant, Pearu Peterson, Wes McKinney and others happened to have encountered Ruby first, we might have a different de facto language for scientific computing and data science.

I don't understand why people bashing self argument. It's part of best design decisions in python. Methods in languages such Java or JavaScript always have hidden argument called 'this'. In js this actually become messy duo to binding of this. In python you can easily find this method is bind to instance of class aka 'self'. It's not always self, It could be cls for classmethods or nothing for static methods.

Most languages have an implicit “this”/“self” which works well. This makes it easy to convert functions to class methods and vice versa without using any editor refactoring features. It also makes it easier to refactor (no need to search and replace every reference to foo within an object to self.foo —- the only time this might be iffy is if there’s a global function foo, but in practice it’s not onerous to handle)

Also beginners don’t have to mentally blot out in their heads the self argument when calling a method (“you mean self isn’t the first argument?”). Debug messages are also more consistent (“the debug message says my method needs 1 argument. Isn’t self right there?”)

I accept Python’s explicit self for what it is (Python’s philosophy prefers explicit over implicit), and don’t have trouble with it but aesthetically it deviates from most OOP languages out there. It’s a valid choice for practical reasons but I would also say that an implicit “this” is an equally valid choice for aesthetic reasons.

Here’s a survey of this/self choices: https://en.m.wikipedia.org/wiki/This_(computer_programming)

Python is like a dutch windmill and Ruby is like a japanese origami. Python is robust and Ruby is elegant.

No downvotes, but I think it's popular because it's an extremely well-designed language. It has a ton of warts - not even to mention the 2.x -> 3.x kerfuffle - but in general it is a thoughtfully designed language.

I don't see why anyone should be downvoted for expressing his or her own consclusions that draw on personal and practical experience of using both languages. The comment is not inflamatory and it merely reflects your own experience. Perfecly valid.

I can’t speak about here, but on Reddit, people use the voting for “like/agree” or “dislike/disagree”.

At some point I read somewhere that the whole point of upvote and downvote on Reddit was for “contributed to conversation” (upvote) or doesn’t (downvote).

That, to me, makes sense.

Disagreeing is part of what promotes good, challenging discussions. It also buffers us from external influences controlling the crowd of “agree’ers”. By promoting and encouraging differences of opinion or view, we make it harder for someone to come in and sway the crowd.

I think I'm starting to get the gist of it now. Thanks. I should have upwoted than, because I felt the sentiment to be valid in the context of the post and the conversation thread.

unfortunately some people feel that saying something they don't agree with isn't contributing to the discussion and are downvoting anyways. i upvote comments that i see unfairly downvoted.

btw, our little subthread here is off topic and may be downvoted for that. (rightfully as we aren't contributing to the actual topic)

A lot of Python's popularity, in my experience, is from the simple fact that it came loaded on many mainstream Linux distros by default. Many people picked it up simply because it was there, and it became the de-facto systems tooling language for a while.

I wrote both and I think you are right in terms of unexpected things happening in python.

I never had a problem with ruby map/reduce, but any expression more complex than a simple loop becomes hard to write with list comprehensions.

On the plus side, python has type annotations and static type checking with the help of mypy.

It has async/await which was a good strategic move to give javascript users a sense of familiarity. Ruby is somewhat lacking in this aspect.

> any expression more complex than a simple loop becomes hard to write with list comprehensions

By design, at that point write a function or proper loop. This provides an opportunity for documentation.

> I am constantly running into things which I like just a bit less as I am trying it for side projects. Things just don't quite work the way I expect them to.

How much of your like/dislike do you think comes down to familiarity with the language?

When I was first learning python, I definitely didn't like it as much because I was unfamiliar with some fairly basic syntax. Exactly the feeling that you're describing (I was coming from matlab). I've been using python for two years now and expressing most 'programs' feels like second nature. I.e. if I am to describe an algorithm on a whiteboard I may as well do it in python because then I don't have to worry about coming up with pseudo-code conventions on the fly, and there is little syntax getting in the way of me expressing semantics.

Based no the link, it seems like ruby is largely similar to python, but it has slightly different choices. I'm curious what someone who's experienced with both would have to say about the stylistic features of the languages (ignoring libraries).

I have some experience with Python and a lot with Ruby. My experience is similar to djohnstons: For the longest time I just wrote Ruby like I thought it should work, and it worked, and if not you'd look up that specific thing in the docs. I struggled at first with attr_accessor and instance variables and the difference between String and Symbol, and I needed to see blocks in other code multiple times to understand them, and implicit block passing I got just recently after many years. But overall, Ruby just worked: If you mix "how would I write that in basic english" and "make a mix of all the C-like languages I know" and for the functional aspects "take what I remember from the onetime I learned a lisp", then you write Ruby, and it feels very natural.

Python does not feel natural at all. And I don't mean the indentation, that's in your face enough that it can be handled fast. But Python is just everywhere almost like you'd expect, only to still be different whenever it can. Dicts for example, why is that in there instead of a Hash or what I'd call a assiociative array? Using list instead of Arrays, as if it were a lisp, only that the list behaves like an array with different syntax, and Python is not lisp like at all. Null is of course not null (I already disliked ruby's nil), it's None. Compare how easy ruby makes range, and how inelegant Python makes that.

In the end none of that matters that much and discussing it too much probably only leads to a flame war. What mattered to me: My python program (an audio player for the tray) was completely unstable, it ran into multi-thread issues without me ever understanding why and how to solve them. My first ruby program was enough to pass my employer, my second one is still online (and one of my active projects linked in my profile).

If I want got get something done and have it work well, I use Ruby. Though fact of the matter for ML or even just statistics the ecosystem is way less nice and I will be forced to use Python next time, my try to use Ruby during my last encounter with ML just failed.

For me the decisive advantage Ruby has over Python is way better map/reduce/select semantics. Python's list comprehensions are just ungainly to me, and I've never understood the reverence for them.

I think one reason people like comprehensions in python is because they provide an intuitive syntax for both map and select/filter. As I understand it, reduce still provides functionality that you can't get from comprehensions alone. I feel like comprehensions are expressive and readable unless you try to do multiple maps in the same comprehension.

I looked up the select/filter syntax in ruby. I guess the main difference is that the name of the element you're iterating over is left implicit compared to comprehensions, but equivalent to filter.

  details.select{ |item| item[:qty] != "" }

  [item for item in details if item.qty != '']

  filter(lambda item: item.qty != '', items)

I'm curious if the implicitness is cumbersome when you need to do a selection that combines multiple lists. How would you express the third line of the following in ruby?

  A = range(65,69)
  B = ['A', 'B', 'C', 'D']
  [a for a, b in zip(A, B) if b=='C']

My approach would probably be to create the zipped list in the beginning, split it for the comparison and then select the wanted element:

     A = (65..69).to_a
     B = ['A', 'B', 'C', 'D']
     A.zip(B).select{|x, y| y == 'C' }.map{|x, y| x }

Thanks!

That looks equivalent to python without comprehensions.

As far as I can tell the difference in the expressiveness of `map/filter/reduce` is mainly about whether you like or don't like comprehensions. Do you have any examples where you believe ruby has cleaner syntax?

> As far as I can tell the difference in the expressiveness of `map/filter/reduce` is mainly about whether you like or don't like comprehensions.

Comprehensions don't replace reduce, they are equivalent to a combination of map, filter, and flat_map. The difference is not just about comprehensions, since map/filter/reduce, and friends, in Python are functions, where in Ruby they are methods; so in Python when you can't do it all with comprehensions (reduce, zip, etc.), it's either imperative loops or functional notation (inside-out), while Ruby uses method call notation, which results in operations reading in the order of application.

Great clarification. You're right, reduce was a typo.

I definitely like how method call notations can be read left-to-right rather than inside out.

Now I'm curious why python developers decided not to add these 'transformation methods' to all Iterables.

The obligatory and beloved, http://poignant.guide/

this, along with some of julia evans excellent 'zines, are going straight on my bookshelf if i ever have a cool bookshelf

Ruby helped me grasp the basic OOP concepts when I was a teenager, just by reading tutorials and blog posts during the time RoR was all the rage.

It was one of those unexpected moments of extreme enlightenment I haven't experienced in a while now.

i'm a bit confused about who the target audience for this tutorial is...it is too fast-paced for a newbie, but also seems to be too basic for anyone who is experienced with other programming languages.

not entirely sure what the "in twenty minutes" bit is aiming to achieve here

I do like these https://learnxinyminutes.com/ very much

Why would anybody want to learn Ruby over say... node.js/Typescript these days?

Well, Rails is still the fastest way to build and iterate a web app that I know of... BY FAR.

I volunteer to teach an intro to Rails class to folks getting ready to graduate a local code school and always enjoy watching their facial expressions as I live demo in about 15 min what they just spend the last couple months learning how to implement in the node/JS stack.

Plus, Ruby is just a joy to work with. Hard to put a price on enjoying the language and framework you work with.

The magic of opinionated and reasonable defaults.

When Node Js is taught people often teach Express framework. If someone teaches AdonisJs, it will have similar effect on audience as mentioned above.

AdonisJs actually does look interesting.

As a side point though, it is much less mature than rails.

Just going off the age, and number of: commits/releases/contributors.

Its GitHub pulse is also obviously not as “rapid”

Rails also has a rich set of libraries in the form of gems - which AdonisJs most likely doesn’t rival

Rails is also used/has been used in production by some major companies. Perhaps AdonisJs has been too, but it can’t be as many

There is also Nest.js (which is Typescript based and also comes with an OEM,etc.).

Nest has a bit more mindshare right now - with Triplebyte, etc using them

https://nestjs.com

The good part is that it uses Express under the hood (which probably is ending up becoming the Rack of JavaScript middleware) ...so you get the third party ecosystem compatibility.

I found this post a good overview of Ruby in 2019:

https://naturaily.com/blog/who-gives-f-about-rails

PHP is the fastest at whipping something up. Not a fan, but it’s fast.

Same reason as you'd learn any language: job market (some areas have more openings for one language (for instance, in Houston, Ruby is slightly ahead of Node, and C# blows both of them away) or another or you need to work with projects written in that language (in the Ruby example, say you want to write a module for Metasploit or hack on Gitlab), etc. It's never as simple as focusing only on what the coolest web language is.

i've always thought of Ruby as a very clean, elegant, ergonomic language to write tools in (based on a few months of experience working with it a few years ago).

I'm familiar enough with JS that i would primarily use JS now for web stuff, but Ruby is quite a nice language to use, and I wouldn't be surprised if its easier for beginners to learn than JS.

In any case I think that skills in any one of the popular 'big' higher level dynamically typed languages (Ruby, JS, Python) are fairly transferable to the others too.

I remember people suggesting I learn javascript when I first started out. I found the syntax of ruby way easier to understand in those early days, and found ways to actually build stuff when I didn’t really know what I was doing. Now I sort of miss ruby (while writing node/typescript all day everyday).

I agree. Mainly done PHP and Nodejs and lately helping on a ruby project but I like how it's more fun when other languages feel more tight.

I feel too bad that Python had taken over the position of Ruby more or less.

Ruby is a beautifully designed language and that makes it worth learning on its own.

It depends on the use case? Are you assuming everything is a web front-end?

I believe your question would be more poignant if you s/node\.js\/Typescript/python/ . There's a lot more overlap between the use cases for Ruby and Python. Just saying.

There is also https://ruby.github.io/TryRuby/ (inspired by the now defunct tryruby.org)

Also my favorite: https://learnxinyminutes.com/docs/ruby/

I just started playing around with ruby (on rails) a few days ago and there is something I found frustratingly refreshing (I consider myself a Jr.) in comparison to python. The directory is Ruby's virtual environment. End of story. I was awed and mildly cursing at the same time.

Virtualenvs are easily the worst part of python

EDIT - I asked 9 months ago and the top comment recommended pipenv and flit:

https://news.ycombinator.com/item?id=17062184

There was a lot of negativity around pipenv a couple months ago.

https://news.ycombinator.com/item?id=18612590

I just use pythons integrated venv and pip, which work fine for me. However, it was in that same thread (the link posted in this comment) which suggested poetry and another I believe, which I do feel like trying out.

pipenv is still a mess.

Definitely give poetry a shot, it's really good. In particular, I enjoy how the maintainer engages with the community and is receptive to feedback. He's pretty good about adding features to satisfy the users, rather than handwaving legitimate concerns in one-line responses.

what's wrong with virtualenv? I've never had a problem

Just unnecessary complication.

Also - the fun way to learn Ruby https://news.ycombinator.com/item?id=19125800

How to grind your programming career to a halt in 20 minutes by buying in to a community that thinks metaprogramming, duck typing, monkeypatching, unsealing and resealing, and _everything_ done at runtime are good ideas, with no self awareness or ability to understand why other ecosystems left these terrible ideas behind.

The community has matured a lot over the past decade. Practical OO Design in Ruby seemed to introduce a paradigm shift as people discovered the old ways could help them write more maintainable code. And that just because you can(meta programming), doesn't mean you should.

I haven't had to deal with Ruby in a couple years though.. I don't miss mixin hell, or chasing down a code line from a strack trace that doesn't exist because it was generated at runtime(I hope your ears are burning Chef).

Isn't it a bit late for Ruby now?

It's never too late for a little bit of vitamin R.

Late in the day, you mean?

Personally I love a little Ruby after dark...

Ruby is going the way of Perl, same as the Dodo. I wouldn't recommend anyone learn Ruby over Typescript, JS, Python, C#, or Java.

There's too much magic and Ruby is seriously sllllooowww. Slower than PHP, Perl, and Python. The main draw of Ruby was rails, which is functionally obsolete for modern front end frameworks like React and Angular. It's the OSS version of Asp.Net WebForms

Ruby 3 is specifically going to address speed issues, among other features. However in a lot of cases that’s usually not where the bottleneck is.

Using rails-api as a backend with your choice of frontend is still a viable option. Perhaps it’s not one’s first choice these days but it’s far from obselete.

Agreed. Rails API and whatever Javascript front-end you want is the best possible option out there. It's fast to develop, it's well documented since Rails has been around forever, Ruby on the backend is sooo much nicer than Javascript, and you still get access to the front end trickery you need from modern Javascript.

I have three languages I use. My web sites are done in Rails because it's fast and logical. One site has a Vue front end, only on a couple of pages where I need the JS fancy stuff. Most of my pure APIs are done in Flask because it's lighter weight. I use React Native for my native apps. I tried using Express.js for the APIs backing these apps but I could never get it all working right. I ended up rewriting it in Rails and now it's rock solid and fast as hell.

I'd also like to mention most web development out there is still right in line with even old school PHP and does not need React or Angular or anything fancier than Rails. YAGNI.

While I like ruby, your post is completely based on your experience. I have a Koa (express.js successor) with TypeScript and it's rock solid and since I don't like rails that much, I feel pretty loose there.

Isn't this comparing apples to oranges? I haven't used koa, but it seems to be same level of abstraction as express - basically a thin layer over HTTP with routing. Rails or Django are several levels higher - they include auth, database interaction, CRUD etc. I'm not saying that either approach is better, just that the comparison seems strange.

Rails doesn't include Auth.

Devise does a great job of it though - https://github.com/plataformatec/devise

It does include "has_secure_password" and its friends (password/password_confirmation) though, which goes a ways towards including auth/authz even if one doesn't use devise, when coupled with before_action-s. It certainly comes with some facilities for getting off the ground:

https://api.rubyonrails.org/classes/ActiveModel/SecurePasswo...

I'm only saying what the OP and I'm stating is worthless because they're based on experience.

Agree 100% Koa from the original devs of Express is amazing. Rails is worthless for modern webapps, there's just much better options

This ain't a good defense for Ruby server-side. They're working on speed, okay. is that not where the bottleneck is? Perl 6 is coming too I guess

Because on production servers we have 10 Ruby front ends for a single Postgres database that barely sweats. At the same time, we have a lively Hibernate setup in crufty java using 4 front end servers and overloads our database regularly.

Ruby is slow as hell, to the point that it costs a lot more money to run servers vs ancient J2EE junk. V3 speed increases will be interesting if it's 10x+ . If not, Ruby is dead. Even Python and it's crazyness is far faster and somewhat easier to use.

Ruby is doomed

It all comes down to what you're doing. To put it another way: it depends. Obviously, writing logic in Go can boost performance, but one needs to assess that that's where the slowdown actually is first. One can also eke out a lot more speed from ruby/rails than you'd think! [0]

For a lot of people (and businesses), Ruby more than suffices. If it doesn't, other languages always exist. So no, Ruby is far from doomed–one just needs to evaluate the pros and cons of Ruby vs something like Go, etc. Ruby with Rails isn't hype or sexy technology, but it is quite mature and robust.

[0]: https://www.speedshop.co/

Ruby is a little faster than Python in most situations these days, to nitpick.

No definitely not. Reply with a link to any benchmark from the last couple years and I'll believe you

From 2018 https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Sometimes Ruby's faster, sometimes Python is.

However all those benchmarks are probably useless. They are not testing how the language is used or should be. The trick with all the scripting languages is to make the CPU spend most of its time in the C code inside the standard library or the implementation of the native constructs of the language with as little overhead as possible.

Example: you don't want to do numerical computation using plain Python, you want to use Numpy.

You also want to learn very well all the ways Ruby's standard library can group operations in a single method call saving time compared to naive multi method chains.

Inconvenient.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Ruby is fast in some cases and python in some other cases.

Every new version of Py has speed improvements as well.

Wait, I've heard this one before!

Except for crystal-lang, which is compiled Ruby, more or less, and smokes all the above mentioned interpreters, no?

Crystal is magnificent in its typing and speed compared to Ruby, but it’s still a niche language (small ecosystem / lack of developers) and breaking changes happen all the time.

When it reaches 1.0 and becomes stable I’d like to work with it again. For small simple APIs raze was great.

Even though I always wanted to learn some ruby, I never made it through any short tutorial.

My problem is: I already _know_ that LISP is the best language(-family) ever and probably nothing in future will change that.

And meanwhile I accepted python for daily use because it has so many libraries.

after learning common lisp and smalltalk i realized that almost none of the languages that were created after added anything new to the language. this doesn't make lisp the best language, but certainly one that's good enough, and the only thing holding it back today is lack of popularity, not lack of ability.

i feel that newer languages add a more complex syntax without necessarily simplifying the the process. though here i feel that ruby and python have a rather nice syntax, and it's debatable which is actually easier to read.

for my part, i like the minimalistic syntax of either lisp or smalltalk, because they make it easier to reason about the code once you get used to it because there are not so many syntactic elements that i need to keep track of. but both do take some getting used to.

maybe ruby and python today feel easier to pick up because we start learning with rather complex syntax.

a good comparison may be lego bricks. lisp and smalltalk syntax is like the basic bricks that can be used anywhere, whereas ruby, python and others have additional special parts that only have a single use.

while the basic bricks are much easier to understand, maybe it does take more skill to use them to build complex systems than if you have a lot of specialized parts...

Wow, I thought Ruby was supposed to be an elegant and simple language for developers but now I realize why it's dying off. It looks like it's trying to cater to newbies and not real developers with all the syntax changes and odd paradigms. I'll stick with Python.

What's wrong with catering to "newbies"? How do you define "real developers" vs. a newbie?

One of my previous teams at one of the big tech companies who's products or services you likely use every day had an entire suite of tests for data pipelines that were quickly implemented in Ruby. That system is still in production today.

I guess none of the folks on that team were "real developers", huh?

The folks at Basecamp, Github, AirBnb, Hulu, Kickstarter, MyFitnessPal, Twitch, or tons of other Rails-powered sites must not be "real developers" either...

Add Discourse as a rails app too which is becoming hugely popular. Also GitLab.

And GitHub and Basecamp and Twitter

OP already states 2 of those and I thought Twitter left rails forever ago.

I wonder to what extent are those 'a rails app'. Those are all huge apps with many microservices I would assume. Don't tell me Twitch backend is all rails.

While those examples may not be pure Rails apps anymore, it was the way they started. Rails was essential in making all those startups succeed and grow massively.

Definitely. Rails is great as a starting point. By the time a product/company has started to 'outgrow' it then of course migrating away might make sense and there'll more than likely be a large enough team at the time to do the migration.

A bit of YAGNI is clear here.

Reply on news.ycombinator.com