Earlier quoted context omitted.
> I look at a "sort of" competitor in our industry, and their rate of feature development is ridiculously slow by comparison. Seconded. At my org, Ruby/Rails is our competitive advantage. Our 5-6 competitors are all Java/.NET shops -- we deliver fixes and new features dramatically faster and deploy them with ease. It gets noticed. The main downside is rails doesn't scale well re: complexity so regular refactors are n…
While certainly a little polarising the adage of optimise later really comes into play here. We do a lightweight industry specific system that had all the generic stuff (eg time/tasks etc) with some special sauce that makes us stand out. One of our clients said "Mate the rate you guys are adding features - the ERP company we went with they haven't done 1/10th of what you've done in the last year. Can you implement fu…
Autotuner: How to speed up your Rails app
31–40 of 68 posts
Re: Autotuner: How to speed up your Rails app
#32I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.
Where do you get the idea that the rails ecosystem is striving? I work on a big Rails monolith as part of my day job and the amount of abandoned libraries in the ecosystem and general quality of libraries is pretty miserable if compared to Golang, Java, Python, JavaScript and others. I'm not saying it's a bad technology choice for a new company when all you need is to build a CRUD web app fast, but I wouldn't use it…
An equivalent example imo is the PHP ecosystem, which itself has been growing rapidly and thriving over the years -- but at the same time if you did deep enough you'll find a graveyard of long since abandoned frameworks, libraries, etc...
Re: Autotuner: How to speed up your Rails app
#33Re: Autotuner: How to speed up your Rails app
#34Github: https://github.com/Shopify/autotuner It’s incredible how much Shopify is investing in Rails (& Ruby for that matter). And I assumr the investment is paying off because otherwise they wouldn’t continue like this.
Re: Autotuner: How to speed up your Rails app
#35Earlier quoted context omitted.
Ruby is incredible. It is still one of the best choices for a platform to build a company or a product quickly with. If it cannot keep up with your scale, throw more hardware at it and it will still be worth it in terms of time and man-hours saved. I only ever wanted compile-time linting and better autocompletion such as in the case of Elixir LS. Does something like that exist for Ruby now? How is Crystal these days?
There is ruby-lsp and ruby-lsp-rails. For the former to shine you do need to use sorbet but for any moderate to large sized rails app I'd personally recommend it anyway. Yes it's not perfect, yes it has a learning curve but boy does it make refactoring easier, faster and safer. ruby-lsp-rails builds on top of that and hands out information on models and routes mostly
Re: Autotuner: How to speed up your Rails app
#36Earlier quoted context omitted.
Where do you get the idea that the rails ecosystem is striving? I work on a big Rails monolith as part of my day job and the amount of abandoned libraries in the ecosystem and general quality of libraries is pretty miserable if compared to Golang, Java, Python, JavaScript and others. I'm not saying it's a bad technology choice for a new company when all you need is to build a CRUD web app fast, but I wouldn't use it…
Rails is *ancient* in the context of tech though, I think it's fair to criticize the skeletons in the closest while not necessarily refuting that the ecosystem is still active. An equivalent example imo is the PHP ecosystem, which itself has been growing rapidly and thriving over the years -- but at the same time if you did deep enough you'll find a graveyard of long since abandoned frameworks, libraries, etc...
The problem that I can see with Ruby in particular is that its niche is getting smaller and smaller as the world evolves around it. Interactions with external services that are on the critical path to serving requests are becoming more common. Interactions with actual contents of pictures and documents are becoming more common. Concurrency is a major missing building block to build modern apps compared to 10 years ago, and the answer of the Rails community has mainly been YAGNI (although there are efforts to incrementally improve things, but no fundamental shift in language or runtime design).
Re: Autotuner: How to speed up your Rails app
#37I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.
I normally interview in Java, partly because I know it's deepest demons, and partly because pretty much anywhere will let you interview in it. But recently I interviewed for a staff engineer position and there was a portion that was "API programming." Just writing a basic REST API to CRUD a model object. And I was like, oh my god, I know what I have to do. So I used rails. It was an hour and 15 minute block, and I ra…
Re: Autotuner: How to speed up your Rails app
#38I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.
There’s also a ton of idea placeholder and half-baked proof-of-concept gems. These are easier to spot (usually released once, years ago) but are now nothing but squatters on the namespace.
Even if human effort is too much to ask, a filtered subset of packages that successfully bundle and pass their own tests for specific Ruby version+arch would be helpful. More broadly, perhaps that RubyGems should even be entirely siloed for each annual Ruby release, since this tends to be the boundary of breaking changes to the language (see also: semver) and approximately the cycle on which unmaintained packages become an obstacle to the update of shared dependencies.
Re: Autotuner: How to speed up your Rails app
#39Earlier quoted context omitted.
While certainly a little polarising the adage of optimise later really comes into play here. We do a lightweight industry specific system that had all the generic stuff (eg time/tasks etc) with some special sauce that makes us stand out. One of our clients said "Mate the rate you guys are adding features - the ERP company we went with they haven't done 1/10th of what you've done in the last year. Can you implement fu…
Because Ruby and especially RoR is a strict downgrade in every dimension compared to .NET. Now, these developers could have been using old .NET Framework, in which case we usually pretend they don’t exist because it’s like stubborn Python 2 of .NET that is otherwise the most productive platform for back-end (with really, really good performance).
And that line of thinking is damaging in the tech world. There is no one ring to rule them all. Each tool, language, framework has a place - everything has tradeoffs.
I've worked with enough .NET world to know what the tradeoffs would have been.
For instance the critical library that enabled this piece of functionality, the nearest thing in .NET world looks to have 1 star on github, last updated 4 years ago. The ruby gem has 1.8k stars, tonnes of commits and upto date.
So if you were to implement that in .NET you would be (a) hitting the books (b) re-writing that library or (c) doing a hugely in-effecient/naive implementation that wouldn't scale.
In RoR land - drop in the gem and be prototyping that afternoon.
Sure if I was VC backed, and had money to burn, it might be a bit more interesting to use .NET - if were targetting more enterprise oriented clients and potentially wanted an on prem option, then yeah - .NET. Wanting more access to developers in our country - .NET, that's the predominant market. Etc etc.
In our use case RoR isn't a downgrade.
Re: Autotuner: How to speed up your Rails app
#40I love to see how active and vibrant the Rails community is. I used to be concerned about the viability of building new companies in Rails, since the ruby share of languages is so low these days. Based on the still-healthy community and the ridiculous productivity level that a developer can have with Rails 7+ (turbo, morph, stimulus) I still think its a fantastic stack to build a company with.
The only gripe I have with the Ruby ecosystem (and transitively to Rails) is that RubyGems is not curated, and many gems have bitrotted into broken obsolescence over the years, but these are presented with equal standing to those that are actively maintained, and it takes a discerning eye & additional effort to tell the abandoned ones apart from packages that are simply very stable. There’s also a ton of idea placeho…