121–130 of 213 posts
I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…
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.
Earlier quoted context omitted.
I don't wanna answer for Shopify because I don't work there, but: 1) Shopify LIKES Ruby. The founders love it. You don't drop this after 15 years to gain 20% more speed. 2) Rewrites are hard. We're talking about millions(?) of lines of code 3) Their teams will have to adapt to a new language 4) Maybe 10 years from now a faster language appears - do they do a rewrite yet again? 5) Optimising things is a part of what w…
I agree for Shopify a rewrite would not make sense. But I think writing new features, or rewriting some critical paths of the codebase in a new language could make sense. It's atleast a valid question. They are clearly already spending a lot of resources optimizing Ruby code to match their demands. My question is at what point does continuing with Ruby become trying to force a round peg into a square hole?
> They are clearly already spending a lot of resources optimizing Ruby code to match their demands.
I think the work on Graal is a VERY long term investment. They can grow to become a 200B company even if none of that work succeeds. Also, I think it's just one guy Shopify is hiring to do that but I may be wrong, so definitely not a showstopper for Shopify :)
I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…
I don't see why that would be the case. In fact, the performance improvements during the 2.x era seem to indicate the contrary: that Ruby can be faster.
Earlier quoted context omitted.
> Why would you need an external service for that? It's adding complexity -- and likely hosting costs. We're also dependent on mysql, are you gonna implement that in Elixir as well? Redis is a great piece of software, and it's a real SHARED cache, so it could work for sessions or other small state management you sometimes want to remember for example. What you described won't work for that.
Both are not equal at all. Redis you can definitely do without. A database you can't skip in most apps. Sessions work quite fine in Elixir's local cache as well. :)
This seems to suggest otherwise https://hex.pm/packages/redix, Why is the redis client is so popular in Elixir world? For such a small community 3+ million downloads is huge.
Earlier quoted context omitted.
> If Phoenix wants to increase their adoption, then I think they need to accept that things like this matter. It's gonna be tough for them really, even if it's a great framework (I have no idea). Elixir didn't take off like Golang or other languages from the last decade. It seems to have quite the learning curve, so for beginners any of ruby / php or even .net / java will make much more sense. For seniors...idk. Not…
Popular tech pays the bills of many people. Fringe tech is usually a secret weapon in consulting, or, more rarely (but still happening quite a bit), in a full-time job. Apples to oranges. Erlang existed for 30 years and has been used by its small-ish but also very vibrant community, with great success. So you know, very popular or not, us the people who use it successfully commercially will keep doing so. But as I ha…
I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…
I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…
Why do you consider Ruby to be inherently slow? I don't see why that would be the case. In fact, the performance improvements during the 2.x era seem to indicate the contrary: that Ruby can be faster.
Well, the extensive use of “method_missing” appears to be staggeringly difficult to optimize short of a tracing jit and it’s also the core idiom of many popular frameworks. Of course it can be faster—if you remove the slow, unique features you can optimize it like any other language.
I wonder what would be more efficient, constantly trying to eke out some performance out of a inherently slow language? Or writing/rewriting new/critical paths of the codebase in a faster language. Ruby used to be able to say we sacrifice performance for developer productivity. I don’t think this is any longer true, there’s plenty of languages out there that developers can be just as productive with, while producing…
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 langu…
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).
Benchmarks are subjective, but all benchmarks show Ruby as slower than compared dynamic languages. The relative speed difference is different per benchmark, but across the board Ruby is slower. It fundamentally has to be slower. Ruby is the most dynamic of the dynamic programming languages. And the community has embraced metaprogramming, making it every more dynamic. Especially on webservers, you'll be executing hund…
No & No.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...