AWS is incredibly convenient, but it's priced at a premium. The main cost liability to building on AWS is the cost of bandwidth is insane, 5X the cost of DigitalOcean or Linode, 10X the cost of co-location.
Of course this depends on the type of startup you are building, a video startup is gonna be crazy expensive on AWS, Non-media heavy SAAS it may not matter.
Of course you can always build on AWS and place a caching layer in front of your bandwidth heavy media using DigitalOcean boxes to save big.
I agree, the AWS free tier is incredible for getting a project off the ground. For a side project of mine, I'm spending a little over $10/mo on AWS:
- 2x 1GB instances (one free, one $10/mo)
- Free ELB to load-balance between them
- Free 1GB Postgres RDS
Then I spend less than a buck or two a month when I spin up a c4.large for a few minutes to compile a new AMI periodically. This would all cost at least 3-4x on something like Linode or Digital Ocean.
This comment breaks the HN guidelines, obviously, and I've already warned you recently not to do this (https://news.ycombinator.com/item?id=11784145). It doesn't matter whether the other person is breaking the rules, being provocative, or whatever. Please don't do it again or we'll end up having to ban you as well.
It sounds like it wasn't decided to keep 3rd party as much as decided not to not combine yet:
> The feedback I got during the proposal process for putting Channels into Django 1.10 (it did not get in before the deadline, but will still be developed as an external app with 1.10) was valuable; some of the more recent changes and work, such as backpressure and the local-and-remote Redis backend, are based on feedback from that process, and I imagine more tweaks will emerge as more things get deployed on Channels.
It seems to be taking more of a South approach, and I really like this. Shake out conceptual issues, find an API that works well, iterate a bunch. Django release cadence is pretty slow, so having it simmer outside of it makes a ton of sense.
If it's a big hit like South was, it'll get rolled in and we won't have to immediately start deprecating things due to an un-tried design.
But all of the package recipes are just Bash scripts, which I think is just terrible, btw. Using a real programming language would have been a much better choice.
> Using a real programming language would have been a much better choice.
The problem is that everyone disagrees on what a tolerable real programming language is. Some refuse to use Python; others Ruby; others Scheme; others Lisp.
Well said. Also, what could be called perfect today is not necessarily "perfect" tomorrow. Example: other frameworks solve the problems at hand in a better way.
