Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 2.0 released

docs.djangoproject.com

Post reply on HN
Print view View original

131–140 of 177 posts

Re: Django 2.0 released

#131

Post by rtpg »

thecardcheat wrote: post #52
jordigh wrote: post #44

Earlier quoted context omitted.

I really dread upgrading Django. We have a codebase that has been with us since the 1.3 days and each time there's an upgrade, someone on the team sets about one month aside to deal with all of the breakage. You could say that this is our fault for "doing it wrong" but we just wanna get stuff done. Sometimes the only way to do it that we could figure out was by doing something that Django later decided we shouldn't h…

That's surprising to me as I have updated a large production Django code-base on my own for every version from 1.5 to 2.0 and it has never taken me more than a day, with an equal or lesser (typically lesser) amount of time dedicated to deprecations when I updated to the previous version. Any blockers past that point have always been due to slow-to-update third-party libraries. The Python 3 update took longer and had…

My guess here is that still being in Python 2 makes this more difficult.

If you're in Python 2 the bytes/str story is still mixed up, so API solidification happening in Django iteratively (in preparation for Django 2.0) will likely break a good amount of your code.

Inversely, we moved over to Py3 in the 1.7 days so we were spared some pain on that end.

Re: Django 2.0 released

#132

Post by jrumbut »

mjfisher wrote: post #117
fulafel wrote: post #37

Earlier quoted context omitted.

Interesting. What would you say is the biggest reason for this >10x development speed difference?

Just wanted to anecdotally affirm whalesalad's experiences with my own. I desperately wanted to like Django more than Rails (I just really appreciate python as a language), but I find projects much quicker to build in Rails. It really is the convention-over-configuration magic that makes the difference. There's less to do in Rails to add commonly used web/crud functionality - but it's much less explicit and relies on…

I feel like you can tell a good rails developer by finding who thought it was hard to learn. There really is a lot you need to know under the magic, and if you can learn to create compatible magic in your own code the framework becomes incredibly extensible.

My Rails projects have always been the ones that felt the most done on their initial release. That extra time not typing and configuring goes into caching, validation, UX, and making nice solutions to project specific problems that fit nicely and don't become pain points as time goes on. All these things that can feel shortchanged in other projects get more of the polish they need sooner.

Re: Django 2.0 released

#133

Post by odonnellryan »

whalesalad wrote: post #5
sgt wrote: post #4

This is probably your best bet if you're just going to build a nice CRUD frontend for a business app, possibly with an API (via DRF). I am doing this right now on a project as it's the shortest path to a win. The API however is written in Java 8 / vertx.

I’d posit that a simple crud app would take an order of magnitude less time with Rails. I’ve been a Django developer since 0.96 and have built dozens of apps with it. After transitioning to Rails, it’s hard to justify the use unless you’re in an evironment that absolutely must use Python.

I can get a fairly feature-complete Python up with Flask + Flask Admin, within a few weeks. 1-4 weeks I'd say is a good timeframe. Have done this multiple times. How does Rails stack up there? Not trying to enter a pissing contest .... I agree that Django is not faster than Flask for simple business crud apps.

Re: Django 2.0 released

#134

Post by drdaeman »

konschubert wrote: post #128
sebazzz wrote: post #33

Earlier quoted context omitted.

One disadvantage of Django is that database providers need to know a lot about the internals of the framework. This shows once you rely on a 3rd party developed database provider, which can break even on minor upgrades.

What do you mean with a database provider?

Possibly, database backends?

Like those: https://docs.djangoproject.com/en/2.0/ref/databases/#using-a...

They are, indeed, quite complex.

Re: Django 2.0 released

#135

Post by cschneid »

mjfisher wrote: post #117
fulafel wrote: post #37

Earlier quoted context omitted.

Interesting. What would you say is the biggest reason for this >10x development speed difference?

Just wanted to anecdotally affirm whalesalad's experiences with my own. I desperately wanted to like Django more than Rails (I just really appreciate python as a language), but I find projects much quicker to build in Rails. It really is the convention-over-configuration magic that makes the difference. There's less to do in Rails to add commonly used web/crud functionality - but it's much less explicit and relies on…

I've worked on a handful of large to very-large Rails apps, and I find that after a certain level of size, you're dealing with a Ruby code base that happens to have Rails as the way it is presented. Rails' implicit functions are either obvious because you use them often, or just not relevant, since you're deep in plain Ruby objects implementing your business logic.

Re: Django 2.0 released

#136

Post by jordigh »

thecardcheat wrote: post #52
jordigh wrote: post #44

Earlier quoted context omitted.

I really dread upgrading Django. We have a codebase that has been with us since the 1.3 days and each time there's an upgrade, someone on the team sets about one month aside to deal with all of the breakage. You could say that this is our fault for "doing it wrong" but we just wanna get stuff done. Sometimes the only way to do it that we could figure out was by doing something that Django later decided we shouldn't h…

That's surprising to me as I have updated a large production Django code-base on my own for every version from 1.5 to 2.0 and it has never taken me more than a day, with an equal or lesser (typically lesser) amount of time dedicated to deprecations when I updated to the previous version. Any blockers past that point have always been due to slow-to-update third-party libraries. The Python 3 update took longer and had…

> That's surprising to me

I'm surprised you're surprised. Have you seen the size of the breaking changes documented with each release notes? We typically hit about 10 of these changes per release, sprinkled all over our code.

https://docs.djangoproject.com/en/2.0/releases/1.10/#backwar...

https://docs.djangoproject.com/en/2.0/releases/1.9/#backward...

https://docs.djangoproject.com/en/2.0/releases/1.8/#backward...

And those are just the intentional breaks. We find a lot of unintentional breakage too, and sometimes we accidentally use undocumented stuff which of course also isn't documented when it breaks. Each Django release has added an average of 32 commits per release for the past four releases just to deal with the version upgrade.

Re: Django 2.0 released

#137

Post by rtpg »

bluewalt wrote: post #122
rtpg wrote: post #17

Earlier quoted context omitted.

The biggest challenge with upgrading Django is making sure all your Django-related dependencies have fixed things up. Django only has one paid full-time maintainer to my knowledge (Tim Graham). So given the team's limited peoplepower Only the last two releases (+LTS releases) get security updates. This means that Django 1.10 (released 18 months ago) won't get updates, so if you use any new features you're on the upgr…

I can't agree more with you. That's the one and only reason I'll stick to the 1.11 version. Garanty of compatibility between Django and ALL my external packages is a lot more valuable that a responsive admin panel and a new syntax for urls. I would love "important" (yeah it's opiniated) packages move to the official Django repo (like Channels), to help reduce this risk when migrating. It's actually surprising how oft…

I've had decent luck for the most part, but it only takes one package.

I would love to see someone start on a combination of `pyup` and some "maintenance fee" for projects that are found in ones `requirements.txt`.

For a monthly fee you can make sure that at least someone is checking to see that your Django dependencies are being kept up to date as time moves forward. The pitch being "get an extra maintenance developer for a fraction of the cost".

Re: Django 2.0 released

#138

Post by guftagu »

blunte wrote: post #30
_arvin wrote: post #9

Earlier quoted context omitted.

Python - Django Ruby - Rails PHP - Laravel all nice choices

And if you don't mind the learning curve (which will make you a better thinker!), I would add Elixir - Phoenix I wish there was a complete Clojure - ???

I'd wait for the ecosystem to mature before building a business app with Phoenix. You never know what taken for granted library is missing in Elixir, and it's going to be damn hard to hire a developer experienced with Phoenix. Everyone on your team will be slow and will be making a steady stream of mistakes as they learn the framework

Re: Django 2.0 released

#139

Post by ubernostrum »

Walkman wrote: post #108
simonw wrote: post #96

Earlier quoted context omitted.

I've ever understood this argument. Any library you can pick and mix into your Flask app you could just as easily pick and mix into your Django app. It's all just Python.

not really. Did you ever tried to use SQLAlchemy with Django? Good luck with that.

Ever tried using SQLAlchemy with Flask?

It's exactly the same situation: either you luck out, and someone already wrote all the conveniences and utilities and integrations with components for you exactly the way you want them with exactly the set of other components you wanted, or you do it yourself.

Also, you could make a similar argument about swapping major components into, say, Pyramid. Most of the alternatives people promote to Django are not really some paradise of trivially-swapped-but-tightly-integrated components. They just do exactly what Django does, with a different set of "use these or lose the integration" components chosen up-front for you.

Re: Django 2.0 released

#140

Post by ubernostrum »

whalesalad wrote: post #51
fulafel wrote: post #37

Earlier quoted context omitted.

Interesting. What would you say is the biggest reason for this >10x development speed difference?

Django forces you to declare everything. Lots of manual boilerplate. Example, you must define every bit of a model in order for it to work. Rails is the opposite. ActiveRecord will ‘just work’ with the database. You can run rails on an existing db for example if it follows what are widely used conventions such as lowercase model name is the table, foreign keys are foo_id, etc... This is where people fear the “magic”…

Example, you must define every bit of a model in order for it to work. Rails is the opposite. ActiveRecord will ‘just work’ with the database

Someone still had to create that database with those tables in it. It didn't magically pop out of the aether. Your complaint, then, is not "you must define every bit", but with where you do it, since you have to define things no matter what.

And if you have an existing database you'd like to use with Django, 'manage.py inspectdb' will reverse-engineer a set of model definitions from it.

Post reply on HN