Live data from Hacker News

Django and Postgres for the Busy Rails Developer

andyatkinson.com

51–60 of 127 posts

Re: Django and Postgres for the Busy Rails Developer

#51
post #31

Earlier quoted context omitted.

I can’t speak for rails’s ActiveRecord but I don’t think DjangoORM is worse than any other ORM in that regard. It’s probably one of my favorite ORMs. I don’t think I’ll ever really use it again but that includes every other ORM.

I mean there is a clear difference in how ORMs that use the data mapper pattern like Hibernate or Entity Framework etc. ultimately allow for a cleaner overall application architecture vis-a-vis ActiveRecord (the pattern) which usually ends up leaking throughout the entire application.

I think we agree. I don’t think there is that much difference between ORM patterns (and I’m sorry I misunderstood you) because they all eventually become more trouble than they are worth in larger and more serious projects. I agree that you can probably go further with data mapper pattern ORMs, like EF, but I’m not sure I think the same is true for something like DjangoORM vs SQLAlchemy. On the flip-side a lot of projects will do fine with any ORM and never run into issues over their lifecycles.

Though in a world of SQLC (and similar) I’m not sure what ORMs are really solving for anyone anymore.

Re: Django and Postgres for the Busy Rails Developer

#52

Earlier quoted context omitted.

You can do that with Rails too. The difference is that Rails defaults are very good.

The Rails dev says that Rails defaults are very good and so says the Django dev about the Django defaults. The Django ORM is loved by tens, maybe hundreds of thousands of Python devs globally, and while I could raise concerns about it (for example, the async experimental capabilities fucking suck, and the core dev team is extremely slow to innovate on them on the basis that that's not "the Django way"), I've never he…

Actually the dango dev is saying that the whole appeal of dango is that you can swap the defaults out easily, kind of the opposite

Re: Django and Postgres for the Busy Rails Developer

#53
post #19
post #7

Earlier quoted context omitted.

Majority of learning surface will come from framework and not the language, if you need Python elsewhere just learn that as well, but this shouldn't move framework choice much.

Ruby, and Rails in particular, has a lackluster dev experience with any editor that isn't RubyMine. That's been a huge obstacle for me personally.

ruby-lsp and rails-lsp from shopify is pretty good right now and getting better by the day. the vscode extension handles it well too.

Re: Django and Postgres for the Busy Rails Developer

#54

Earlier quoted context omitted.

> I've never heard anyone but a Rails dev complain that it's "too verbose". Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.

That's curious to me honestly. I really prefer the ergonomics of Django's ORM compared to when I've had to use SQLAlchemy+Alembic in the past. I find alembic incredibly confusing and poorly documented. Not that documentation matters as much nowadays with AI

yeah, alembic feels especially "small" and obscure compared to the hyper exhaustive nature of SQLA for everything else. felt like a side project at first

Re: Django and Postgres for the Busy Rails Developer

#55
Well. I use GeoDjango with PostGIS. Django supports it natively. And django-rest-framework takes it to another level.

Python has the best machine learning and AI support too. It is very easy to mix geographic libs with data science tools.

To build a simple CRUD software with vanilla SQL you really don't need Django and Python. But I challenge any one to try a GIS full stack without Django and Python.

Just look for GDAL, pyproj, shapelly, fiona and MapLibre/Mapbox.

And it really powerful to combine with HTMX or Vuejs for reactive SPAs

Re: Django and Postgres for the Busy Rails Developer

#56

Earlier quoted context omitted.

The Rails dev says that Rails defaults are very good and so says the Django dev about the Django defaults. The Django ORM is loved by tens, maybe hundreds of thousands of Python devs globally, and while I could raise concerns about it (for example, the async experimental capabilities fucking suck, and the core dev team is extremely slow to innovate on them on the basis that that's not "the Django way"), I've never he…

> I've never heard anyone but a Rails dev complain that it's "too verbose". Maybe not too verbose, but there's a large population of python devs that find SQLAlchemy (+ Alembic) the much better option.

Yeah SQL Alchemy is 1000x better.

Django's ORM is miserable.

User.objects.filter(company__product__product_variation__var_type__in=['var1', 'var2'])

vs

User.where(company: { product: { product_variation: { var_type: ['var1', 'var2'] }}})

Little things like that make it so much harder to read.

Re: Django and Postgres for the Busy Rails Developer

#57

Earlier quoted context omitted.

Funny you mention templating, its one key thing I'd change about Django, that... and maybe scaffolding, I'd crank it up drastically more. My ideal enhancement to Django would be something like how Microsoft made Razor into Blazor... A template engine that can run purely on the back-end or purely on the front-end, replacing any need to ever use JavaScript, you stick to your native programming tongue if you will.

I think of Django's templating system as a great tool for a previous era. I'm hopeful that PEP 750 [1] gets accepted and a modern ecosystem of template engines emerges in Python-land. For the moment, I tend to use in-python builders like htpy [2] when I want back-end Python code to generate some HTML. [1] https://pep-previews--4124.org.readthedocs.build/pep-0750/ [2] https://htpy.dev

Didn't know about pep 750, that's really cool that there's a push for native templating. I just hope we see a gradual stepping away of "everything clientside" and the JS framework hell that exists today. I've tried and I've tried but I just can't take javascript seriously. It's so ugly and overbuilt. It should never have been brought to the server, Node was a horrible mistake. In my ideal future, the web returns to servers doing their jobs, and JS being used for minor interactivity features when necessary.

Re: Django and Postgres for the Busy Rails Developer

#58
post #4

I'm working on a Rails and on a Django project for two different customers and I've been doing that for years now. I'd pick Rails over Django any time for every single feature. The absolute worst Django feature is the templating language. It seems to be designed to slow down developers to the like of old time Java web apps, almost mandatory templatetags et all. The query language is moderately bad, quite verbose (Mod…

One of the biggest things I dislike about Django is its lack of a standard project structure. I haven't used it in years, so things may be different now, but back in the day, even the core team recommended against using the default project layout, which always made me wonder why they generated new apps that way.

Switching between Django projects while doing contract work was always a "what the hell?" experience. Rails' opinionated nature makes it easy to dive into new projects you know virtually nothing about.

Nowadays, I focus exclusively on Elixir/Phoenix apps. Elixir eliminates the OOP requirement (I've never liked OOP because I don't feel it remotely lives up to the hype) while maintaining all the other great things I love about Rails, like consistent project layouts. It also makes writing multi-threaded, distributed apps easy.

Re: Django and Postgres for the Busy Rails Developer

#59
post #4

I'm working on a Rails and on a Django project for two different customers and I've been doing that for years now. I'd pick Rails over Django any time for every single feature. The absolute worst Django feature is the templating language. It seems to be designed to slow down developers to the like of old time Java web apps, almost mandatory templatetags et all. The query language is moderately bad, quite verbose (Mod…

Shameless plug for https://www.reactivated.io

It swaps the templating engine for React. But still server side and using all the Django features you know and love. No SPA needed.

Re: Django and Postgres for the Busy Rails Developer

#60
post #4

I'm working on a Rails and on a Django project for two different customers and I've been doing that for years now. I'd pick Rails over Django any time for every single feature. The absolute worst Django feature is the templating language. It seems to be designed to slow down developers to the like of old time Java web apps, almost mandatory templatetags et all. The query language is moderately bad, quite verbose (Mod…

I saw someone mention reactived but there's also https://github.com/wrabit/django-cotton
Post reply on HN