[pcmoney]

If you want the luxury of scale problems down the road you do RoR until you lock down that first couple billion dollars of valuation. Just ask Stripe, Github, AirBnB, Gusto, Shopify, Coinbase, Dropbox, Twitter, Door Dash etc. Then you can have the "problem" of picking the wrong language. Massive survivorship bias in the panning of Ruby/RoR IMO...

Also the Ruby/RoR community and culture is better than most other languages/framework. I think culture is a totally valid performance reason to pick a language. Sure there are faster languages and there are jerks everywhere but on average it seems RoR devs are on average nicer and more collaborative people relative to peers.

There is a just a mindset for wanting to write in a language optimized for developer happiness that dovetails with wanting to be happy and work happily with other people. Ya sure those C++ guys can write more performant code but I know who I want to work next to 8 hrs a day. And who I will be more productive working with.

Also I don't think there are plenty of languages that are Ruby/RoR peers. Django doesn't come close. JS ecosystem is a dumpster fire. Some functional and JVM languages maybe but they often come with a corporate culture that kills their benefits. Kotlin would be my bet I guess?

Also if scale is your issue and rails isn't cutting it then you need to go to a proven language with a proven and hirable developer base. That rules out a lot of new and promising languages. Sure they might be just as productive languages but they are resource constrained at the people level. It is really hard to hire Elixir/Phoenix devs etc. You need a talent pool of thousands. Also you need to KNOW the language will be there with a community in 10 years and that it has a history of evolving without screwing over the community. I guess Twitter going to Scala would be an example of this, from my understanding it doesn't solve all their problems.

Total aside: plenty of language need massive tuning to work at scale but it seems like Ruby is unfairly singled out if someone does "exotic" tuning of it but if someone tunes a JVM language or invent their own it is supported.

[joelbluminator]

I don't think Dropbox use/d Rails. But you can add Gitlab to that list which is a VERY good company.

[jb3689]

> Also you need to KNOW the language will be there with a community in 10 years and that it has a history of evolving without screwing over the community.

I don't think this is true at all. Where was Rails 10 years ago? It was pretty bad compared to today's Rails. If the Rails 2 and Rails 3 rewrites never happened then RoR likely would've been superseded by something else and be "dead" today. The point is that Stripe, Github, etc were all early adopters of Ruby and accepted that risk

> You need a talent pool of thousands

I also don't think this is true. You need to hire the right people and you need for them to stick around. And you need to be in the right line of business obviously. Again most of the companies you listed were small/passionate/scrappy for a long time

[leetrout]

Edit: downvote away for disagreeing. I don’t see anyone presenting a counter argument.

This has not been my experience.

It has been “do it THIS way in ruby” even though either way is perfectly valid (eg list of Literal strings / symbols vs %i or %w.

Lots of bike shedding type discussions on which way is better and unsurprisingly no consistency across the codebase.

There’s also a lot of hidden things you can only learn from years of usage and no clear documentation of when / where features came and went.

All in all every Ruby dev I’ve worked with across 4 companies have all had the same sort of elitist / pretentious attitude compared to Python, Go or Java devs. Ruby has only been second to Scala and Rust devs (so far).

[kenhwang]

Seems like you're comparing between languages that end up being the default choice due to their low learning curve (Python/Go/Java) and languages chosen because the default choice wasn't good enough (Ruby/Rust/Scala). The latter tends to be much less restrictive or more featureful which necessitates governance by convention/culture/guidelines since its significantly more difficult to be exactly prescriptive over significantly more variance.

For example, most Ruby found in the wild follows some variation found in the style guide: https://github.com/rubocop-hq/ruby-style-guide (same with Scala: https://docs.scala-lang.org/style/ and Rust: https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide...) and their communities generally care enough to try to enforce it. Most languages have an universally agreeable style guide these days.

I personally find the first set of languages to be more consistent syntactically (typically because they're simpler languages that have auto-formaters) but the latter set of languages are extremely consistent in patterns/ideologies. It seems like you care more about the former and didn't care to learn about the latter (which I'll admit, does present a higher learning curve and tends to be acquired through experience with the community than through a doc).

[toomanybeersies]

I find that Rails apps tend to have some of the most consistent styling (within the codebase, and between codebases) of any language/framework out there. There's generally the "Rails" way of doing things, usually whatever Rubocop defaults to.

Also, "perfectly valid" doesn't mean "good", or "best practice", most style rules tend to reason beyond just looking pretty. String literals are slower and use more memory than symbols, and they're harder to grep for (either visually or with grep) in the codebase. More importantly, it's a lot clearer in code what a symbol's intent is, it's an immutable internal identifier, whereas strings should be used for storing data. Strings are mutable, which can be a source of bugs, a fairly trivial example would a developer making a typo and writing `str += 'label'` instead of `str = 'label', using symbols would raise an exception. Same for using %i or %w for arrays of integer or words, it ensures that the contents of the array are of a consistent type (at least at that point). Personally I don't think it should be a strict rule (I've turned the lint rule off on our codebase), but I do use them where appropriate, in particular when defining a constant as an array as it makes it clear to others reading the code what its intent is.

The only real complaint I have about Ruby style is that there's a million ways to work with enumerables, often with subtle differences in behaviour. For example, extracting a value or default from a hash is commonly done with `hash[:val] || 'default'` or `hash.fetch(:val, 'default')`, if the the key exists in the hash, but with a falsey value (nil or false), it will return 'default', but the second will return the falsey value. This can be good or bad depending on your specific use case, but I've come across unexpected behaviour from both versions.

I definitely agree with you about hidden features though. I've spent hours this week reading through different gems' source code because the documentation was lacking, at least it's generally readable code. It's frustratingly common when reading gem docs for me to find `#method(opts={})` as the method signature, with no additional explanation as to what parameters it takes.

I much prefer Ruby having a prescriptive style guide that the majority of developers use, I can look at the source code for any gem or app and immediately be familiar with how it looks, it's a lot less overhead when starting on new codebases. Compare this to C, where there's half a dozen different conventions on where to put your curly braces, or JS, where there's arguments as to whether lines should end with a semicolon.

You're right that a lot of ruby developers are pretentious, especially compared to Java or C# developers. Most Ruby developers are programming/technology enthusiasts, they have a passion and interest in what they do, I spend a fair amount of my spare time programming, or reading about programming. This is especially true for experienced developers (before bootcamps were all teaching Rails), they learned Ruby in their own time, not at university.

On the other hand, a lot of Java/C#/Python devs do it as a job and nothing else, which there's absolutely nothing wrong with, everyone has different hobbies and interests. One of my coworkers was previously a Java developer, and he has no particular interest at all in programming, he would probably be just as happy as an accountant, he spends his spare time painting or with his family.