151–160 of 216 posts
Earlier quoted context omitted.
Or if you want productivity and a performant web server, try Elixir + Phoenix. Number crunching still has to be dished off to something else like C, Rust or Go, though.
The lack of a type system in Elixir is a productivity killer though :(
I love Ruby/Rails and owe my career to it, but I don't see the advantage of choosing this stack in 2019 over Elixir/Phoenix for greenfield projects. Elixir tooling and libraries are now up to par and I'd argue have surpassed RoR. At this point, it's just as productive (perhaps even more as you don't have to glue on a bunch of additional components) and joyful to work with like RoR but massively scalable out of the bo…
1. You can find a RoR developer.
Earlier quoted context omitted.
Or if you want productivity and a performant web server, try Elixir + Phoenix. Number crunching still has to be dished off to something else like C, Rust or Go, though.
The lack of a type system in Elixir is a productivity killer though :(
Earlier quoted context omitted.
Long ago I liked ActiveRecord(AR), then I worked at a company that did large aggregations in SQL and found it to be severely limited in working with complex queries which use many JOIN statement and sub-queries. During that time I came to enjoy working with the Sequel[0] gem, and its fantastic documentation. Now, after working with Ecto[1] in Elixir, I've found that the ROM[2] builder pattern is a better approach to…
From what I've seen of Sequel is looks awesome and I've been dying for an excuse to use it. found [ActiveRecord] to be severely limited in working with complex queries which use many JOIN statement and sub-queries I'd humbly suggest that this is not a flaw of ActiveRecord whatsoever! I think this is AR working exactly as designed. I would certainly agree that SQL > AR once your queries grow past a certain (fairly low…
My biggest issue with AR is that the arbitrary SQL cannot be combined or reused in a way which leads to compositional queries. An example would be to break up a large SQL statement into several smaller statements and then recombine them in different ways, safely.
What I found with Ecto and ROM is that, while simple to low complexity SQL was about the same as AR, maybe 10% harder to understand, complex to very complex statements were about equivalent to their SQL counterparts and could be composed together. That was a major win over AR for non-trivial queries.
Among my peers (undergrads in college) Rails has largely lost mindshare to python and Node (and even PHP!). At the 3 hackathons I went to this semester I could not find a single other person who knew Rails (so I always have to switch to node or python). If you take a look at devpost, Rails is increasingly losing popularity: https://devpost.com/software/built-with/ruby-on-rails My plea to the Rails community and Rails…
The problem is, I think, DHH doesn't really cares about it. He made it clear that Open Source shouldn't come with responsibility to make it great or fit your needs. It is more like a gift to the rest of the world with No Strings attached.
There is also the resources and company backing problem. Python is THE languages in Data Science, Node is javascript that is everywhere, and PHP, despite many people despise it, still runs the vast majority of the web.
With Github and Shopify now actively contributing to Rails, and Stripe working on Ruby, hopefully things will be better in the future.
Rails, by default is still viewed as a Server Rendered Only Framework. Although its API Mode could be used with any front end such as Vue.js, it doesn't seems to be well known or gaining any momentum.
I am wondering if Ruby Rails will ever pick up something similar to liveView [1], instead of sprinkle of Javascript, LiveView could get rid of it. It fits the narrative of Ruby Rails, and for those that don't like it could still use it as Rails-API and some other front end.
Edit: Turns out there is something similar on Rails called Fie. [2]
[1] https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
Earlier quoted context omitted.
From what I've seen of Sequel is looks awesome and I've been dying for an excuse to use it. found [ActiveRecord] to be severely limited in working with complex queries which use many JOIN statement and sub-queries I'd humbly suggest that this is not a flaw of ActiveRecord whatsoever! I think this is AR working exactly as designed. I would certainly agree that SQL > AR once your queries grow past a certain (fairly low…
Yes, I agree. For simple to low complexity queries AR is hard to beat, especially if your SQL knowledge is limited, and it allows for arbitrary SQL statements as string arguments. My biggest issue with AR is that the arbitrary SQL cannot be combined or reused in a way which leads to compositional queries. An example would be to break up a large SQL statement into several smaller statements and then recombine them in…
You can do this, look into arel. Here's a blog post:
https://blog.codeship.com/creating-advanced-active-record-db...
Earlier quoted context omitted.
Yes, I agree. For simple to low complexity queries AR is hard to beat, especially if your SQL knowledge is limited, and it allows for arbitrary SQL statements as string arguments. My biggest issue with AR is that the arbitrary SQL cannot be combined or reused in a way which leads to compositional queries. An example would be to break up a large SQL statement into several smaller statements and then recombine them in…
> arbitrary SQL cannot be combined or reused in a way which leads to compositional queries You can do this, look into arel. Here's a blog post: https://blog.codeship.com/creating-advanced-active-record-db...
Whenever I read about Rails it makes me want to try it again and "understand" it this time... But it always ends up feeling wrong, and I go back to old reliable Django. I can't put my finger on it, but Django just feels intuitive to me and Rails just feels strange. Maybe it is the convention over configuration mindset which results in lots of magic, but I just can't get comfortable using Rails. I love the idea of Rai…
Earlier quoted context omitted.
Agreed - its just interesting to see the next generation of talent completely ignoring a major platform in current tech industry.
I suppose they will be in for a bit of a shock when they try to make their way into the workforce to find out that the majority of enterprise-land is using Java or .Net and a bit of python mixed in.
I'm just talking out loud here, not to you specifically, but things are the way they are, for good reasons. It's not a "mistake", the way the landscape is today, most technical leads are not sheep. Technical & business requirements have been mulled over time and time again by many thoughtful people, usually leading to these two platforms. A lot of us don't care about what's cool. We demand true technical innovation to adopt a new platform, not technical churn and there's an awful lot of that, if not outright downgrades.
For me, all these things matter.
-Good tooling
-Industrial-strength language design
-Backwards compatibility and support
-Breadth of domains you can target and target well (server-side, desktop, mobile)
-Availability of talent for employers
-Availability of jobs if you're an applicant