181–190 of 332 posts
Earlier quoted context omitted.
"... hits C performance for many tasks" Really?
particular improvements that come closer to C are related to string operations and regex https://tomaszs2.medium.com/ruby-3-2-0-is-from-another-dimen... here are some benchmarks from 2019 (ruby 2.5) related to string and regex operations. already certain operations were faster in ruby than C or go, particularly on longer strings. http://jultika.oulu.fi/files/nbnfioulu-202001201035.pdf
Earlier quoted context omitted.
You suggest people should refactor later on when needed?
Yea, you identify bottlenecks and refactor those as needed (with something like rails it's pretty easy to change out parts of your system while retaining the rails core). Every business will have different bottlenecks and it's very hard to identify them before you start accumulating customers and see how they are using your app
Earlier quoted context omitted.
I agree with this, but that seems to be a problem with Github's frontend code, not their server code. I don't think that detracts from this blog post's message.
I guess my implied question should be stated more explicitly: is GitHub's front end code entirely separate fro the Rails code? That's not how Rails apps usually work, I thought. Admittedly, it's been a long time since I looked at Rails code, and I don't have the slightest idea how GitHub is actually architected. But I don't remember the "front end code" in Rails being a separate thing from the server code, typically:…
Point is, there's nothing about Rails in particular that would prevent fixing these issues, that's probably the result of development and business priorities, legacy code, etc. that would be an issue with any tech stack.
Github is one of the few webapps where I can feel daily that the framework used isn't enough. So many things get out of sync/not up to date, which are fixed by refreshing the page.
I feel the same with Gitlab, with e.g. build pipeline status not updating when it's done - it feels pull- instead of push-based. I mean it may be working just fine, but I don't see it - and the success rate of refreshing a page to see an update is so high that it doesn't instill confidence. These tools should be more reactive, I think, with live progress indicators and the like.
I absolutely love Rails. I'll always remember back in 2010 catching the train to Waterloo station in London and seeing a huge sign overlooking the train tracks that read something like "We Need Rails Developers". Rails was such a huge part of my professional career. Now, 13 years later and I'm deep in the JavaScript ecosystem and have been for 8 years. The most exciting thing to come out of this ecosystem recently is…
Earlier quoted context omitted.
this absolute is a little ignorant. For some products the scalability is the core competitive advantage. He can't engineer it in after the fact.
It's literally Donald Knuth: “The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”
> Instead of telling your team you found something in Rails that will be fixed in the next release, you can work on something in Rails and see it the following week! That's awesome. Not only fixing it for your team but the entire rails world.
Or breaking it for some.
Earlier quoted context omitted.
the mindset "if it works, leave it there" edit: also it's a big project without specs, good luck at finding broken stuff...
Going to sound nuts but perhaps you can leverage ChatGPT4 to start generating some tests, based on some prompts for like 20% of your app. you just have to be pretty disciplined about how you write your specs.
> scheduled GitHub Action workflow ..sounds like they're not dogfooding dependabot? curious if anybody knows more/why
Earlier quoted context omitted.
Github itself used to be. They ran a custom fork of Rails 2.3 for years rather than go through the pain of upgrading to Rails 3. By the time they finally did, Rails had already moved on. It took Github a full eight years to get caught up after that fateful decision in 2010 to hold off on Rails 3.
What were the sticking points that made the 2.3 -> 3 upgrade so tough?