161–170 of 213 posts
Earlier quoted context omitted.
How is it that Python is able to do so many things quickly (even excluding NumPy/SciPy)? Is it more native code libraries? Could Ruby follow this path as effectively?
Are the Python web frameworks that much faster?
Earlier quoted context omitted.
It is surprising until you realize that Rails' ActiveRecord consistently wastes 100-200ms on every request just to serialize / deserialize data from/to the database. So yes, a language that's both faster and has less overhead in its ORM / DataMapper library definitely will help you.
Our data-heavy API returns JSON responses from our DB in ~40ms using ActiveRecord. So no, it doesn't waste 100ms on every request! We're serving around 6000 requests like that per second.
The Heroku dynos I've tested with some years ago performed quite horribly. Only a proper Xeon server was able to achieve sub-100ms responses.
But hey, if Ruby improved in the meantime, cool.
Earlier quoted context omitted.
> The Elixir community doesn't seem to aim for popularity (at least several important maintainers have said so on ElixirForum). Wow, then why does every Rails thread has an Elixir guy trying to tell us what an inferior software we're running? For the sake of humanity? > and will get more and more important as our CPUs can't get faster single-core performance and are just getting more cores. I don't think it will beco…
> Wow, then why does every Rails thread has an Elixir guy trying to tell us what an inferior software we're running? For the sake of humanity? If you prefer that melodramatic phrase. I've been a Rails dev for 6 years and I know that many current Rails devs don't dare try something else -- call it a survivorship bias, fear to abandon what pays the bills now, habits, and most of the time you won't be wrong. Every now a…
OK, and I'm the one generalising yes? Clearly you have zero bias towards the Rails devs.
How about simply becoming really good in a skill instead of jumping stacks every 5 years? To REALLY become good in Rails, to the point where you can write gems for activerecord for example that do something cool with arel, or follow the work Tenderlove is doing easily, this type of good takes effort. and time. Some people don't care at all and will happily switch and rebuild that expertise (or will never become experts in anything). That's totally fine. I value expertise, and won't make the switch for something that on the surface doesn't look like will benefit me at all (again, concurrency as it is in Rails is just fine for my career path and I think most Rails devs are on the same boat).
Earlier quoted context omitted.
> is close to a flame bait. (Not to mention your gross generalization of the members of a not-small community.) You're the one who chose to use the term cargo cult a few comments above
Well, I've been to Rails meetups. I can bet a few bucks that you haven't been to Elixir ones.
Earlier quoted context omitted.
Our data-heavy API returns JSON responses from our DB in ~40ms using ActiveRecord. So no, it doesn't waste 100ms on every request! We're serving around 6000 requests like that per second.
Well, you likely have a dedicated (or pretty strong) server. The Heroku dynos I've tested with some years ago performed quite horribly. Only a proper Xeon server was able to achieve sub-100ms responses. But hey, if Ruby improved in the meantime, cool.
I've always thought of it as the platform you use for running toy apps with maybe a couple of dozen users at most and a low load. It's incredibly quick and easy to get a Rails app running on Heroku, a couple of hours at most. But you pay (in dollars and performance) for this.
Earlier quoted context omitted.
> For 3.5 years with Elixir this is the first time I hear that this is a problem. Any data to back this up? My point is that it doesn't come with Phoenix out of the box (unless something has changed?), and that difference in philosophy is the core of what I'm getting at. With rails new I'm getting an end-to-end test suite and chrome driver installation for free. Phoenix also has no plans of implementing something sim…
> My point is that it doesn't come with Phoenix out of the box (unless something has changed?) You put a lot of weight on built-in features of frameworks in your reply. This is not an objective truth and even DHH himself admitted as much -- including in his article "Rails is Omakase" which I very much enjoyed (because he says that the Rails team picks what they deem the best ingredients and if you disagree then you a…
There's nothing wrong with wanting to pick the parts yourself. But that comes at a cost and that was my original point that you responded to. Rails makes these decisions for you.
Elixir and Phoenix have taken a different approach, and there's nothing wrong with that. But let's not pretend that Phoenix is "as productive" as Rails. It isn't by choice. I disagree with that choice, but it's not my choice to make.
> Generating boilerplate is pretty easy. But how many tools out there can scan your code and tell you "this looks like Devise's boilerplate with exceptions in files A and B on lines 123 to 150 and 201 to 217"?
Rails can reverse just about every generator that it ships with. I'm guessing it's more difficult in Phoenix because the generators append stuff into contexts instead of generating new files maybe?
> and the Phoenix team cares more about building something that is "dogmatically perfect" (which you're correlating with quality)
>> And you have spoken with the Phoenix team. And they told you this. Exactly this? No. They don't do that.
>> There have been a number of discussions on ElixirForum about this and various important figures of the maintainers' teams have openly said that they aren't aiming to make the language and its stack more popular; they want to make useful tech
What? I feel like you're in agreement and disagreeing with me simultaneously here?
> Are you claiming that Rails' way is factually superior to learn?
No, I'm claiming that Rails is easier to learn and use because of the philosophy of its creators and maintainers. ActiveRecord is easier to use than Ecto. Reversible generators is an easier interface than "just undo it with git". Running a rails command for installing ActiveStorage is easier than building it yourself. ActiveJob is easier than wiring up Oban (not much easier, but still). Getting an end-to-end test framework out of the box is easier than hunting down elixir libraries and trying to bring them to the party.
Rails cares deeply about the developer experience. I think Phoenix does as well, but they focus on different things (LiveView).
Earlier quoted context omitted.
Well, you likely have a dedicated (or pretty strong) server. The Heroku dynos I've tested with some years ago performed quite horribly. Only a proper Xeon server was able to achieve sub-100ms responses. But hey, if Ruby improved in the meantime, cool.
Rails on Heroku is about the most inefficient combination you can get for a web server. I've always thought of it as the platform you use for running toy apps with maybe a couple of dozen users at most and a low load. It's incredibly quick and easy to get a Rails app running on Heroku, a couple of hours at most. But you pay (in dollars and performance) for this.
Earlier quoted context omitted.
> I don't see why that would be the case 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.
What makes you say that? method_missing is trivial with a tracing JIT and Chris Seaton's PhD covers how to do it for a method JIT.
The implication is, of course, that there isn’t a good one. This isn’t ruby the language’s fault, it’s just weird that after like 15 years being the go-to tool for VCs there’s no substantial investment in the core infrastructure.
We just gotta wait for banking software to be written in it, I guess, so there’s a vested interest in it over the long term.
Edit: I’d like to further note that other languages use similar features (string-keyed functions) but they aren’t typically put into high performance code/are seen as a hack around formally definitions (possible exception: common lisp, although I would expect a macro). This is inherently a readability improvement over manually defining the methods you use.
Earlier quoted context omitted.
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…
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 lear…
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).