251–260 of 332 posts
I must be the only person on Hacker News who dislike Ruby. It simply has too much magic and doesn't offer enough abilities (unlike Elixir or any Scheme variant) to justify the dynamic type nature. Go and Rust are perfect for me (and maybe Zig?). They covered everything I need.
I must be the only person on Hacker News who dislike Ruby. It simply has too much magic and doesn't offer enough abilities (unlike Elixir or any Scheme variant) to justify the dynamic type nature. Go and Rust are perfect for me (and maybe Zig?). They covered everything I need.
You should also read about Github's history with "Rails" and how challenging it was for them to make it fast enough for them and upgrade it. It's pretty interesting they got around that "challenge" by throwing a LOT more resources at it. It's interesting because this isn't usually a challenge with other major framework upgrades. It makes sense you would need this much investment given the hyper-dynamic dangers of Ruby (not just the language, but the ecosystem), making it difficult and risky to upgrade.
TL;DR the advice in this blog post does not seem applicable to most companies.
Even as a much smaller team, building Heii On-Call [0] as a lightweight alerting/monitoring/on-call rotations SaaS based on Ruby on Rails has basically been a pleasure! And as the article highlights, perhaps the key reason for smooth deployments and upgrades is that the CI testing story is so, so good: RSpec [1] plus Capybara [2] for us. That means we have decently extensive tests of just about all behavior. The few…
My startup is using minitest (mainly for running tests in parallel I believe) and capybara. Crystal looks great, are you using it mainly for type checking? If so why not Sorbet?
(1) the API server at https://api.heiioncall.com/ which gets hit frequently for check-ins, e.g. cron job monitoring
(2) the outbound probe processes that do website monitoring, polling your desired URL every minute and making sure it's up!
Earlier quoted context omitted.
I imagine it wouldn't be too hard, since Django only has one dependency - Django itself (NodeJS developers weep). Is rails the same way dependency wise?
Wait is this true? Doesn’t it also use SQLAlchemy at least? Which then likely has its own dependencies? I’d be really surprised if Django had no dependencies at all.
The first release of Django was in 2005. Back then, the Python Package Index didn't exist yet. Installing Python dependencies was really hard - you pretty much had to grab a copy of the code for each one and put it on your "sys.path" somehow.
So Django avoided the issue entirely by bundling everything you needed to build a web application in a single package.
That's why Django has "django.contrib" - in a time before pip dependencies, it was a way to separate out things like GeoDjango which weren't exactly part of the "core" framework but could be distributed along with it.
I'm curious what their data access layer looks like underneath that monolith. Is the Rails piece mostly now just a frontend for dozens of other services, properly owned and maintained by other teams? I don't mean to trivialize something that's obviously huge and complex as "just a frontend", but IME one of the biggest things that breaks down in a Rails monolith as it scales is heavy, direct usage of ActiveRecord. Eit…
I've heard this several times over the last few months. Like what makes several devs working in the same area of the code "hard"? In my experience whomever is lucky enough to commit first gets the easiest of it, everyone else just rebases and resolves their conflicts. Maybe if you don't rebase and merge instead? I've seen some screwed up stuff happen from bad merges... like entire lines of code vanish. But generally,…
Earlier quoted context omitted.
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:…
Rails can just serve JSON or GraphQL from an API to an SPA frontend, or you can do full server-rendered, or Hotwire to do HTML fragment updates, or any combination thereof. IIRC Github used something like Hotwire but home-grown. I've not done Rails development for a while so not sure what the state of things is for web sockets, but I would think that's not a problem for the framework. Point is, there's nothing about…
Earlier quoted context omitted.
I have yet to see a tech stack that's not locked up into a framework version. That's more because of our engineering culture. The cost of NOT upgrading outweighs by a huge margin than keeping building on top. And yes, have seen Django shops locked into 0.9x release patched right into the core and running for a very long time, impossible to upgrade and all the horror stories. EDIT: Added Django
I think this is mostly a consequence of using dynamic typed languages.
Earlier quoted context omitted.
You MUST have an insane amount of test coverage to trust something like this to Ruby. I'm new to Ruby, with 13 yoe as a SW engineer. Personally, I find it a very hard language to master. Writing tests often feels like I'm settings variables left and right without seeing them being used in the current context. But that then happens to be part of the let() way in rspec. Now you might say: why use rspec? I inherited thi…
You don't have to use `let` in specs. I prefer setting instance variables inside a `before :each` block.
I must be the only person on Hacker News who dislike Ruby. It simply has too much magic and doesn't offer enough abilities (unlike Elixir or any Scheme variant) to justify the dynamic type nature. Go and Rust are perfect for me (and maybe Zig?). They covered everything I need.