3 ms·

> just use Django (or Rails) What do you mean by "just use"? The OP seems to have a long experience and having had used Rails recently myself as a 20 years exp

by h1d 8y ago

> just use Django (or Rails) What do you mean by "just use"? The OP seems to have a long experience and having had used Rails recently myself as a 20 years experience web developer, all I can say is stay away if you know the way web works and not doing it as a medium team size. You need to learn everything the rails way even if you know every moving parts of what makes a web site which can often get in the way and I can't live without googling every 30 minutes and I assume Django is similar. Why not recommend something like Koa which is for node.js but more modern than Express, even by the same author, and with TS and async/await it works well which is my main framework these days. You seem to like fat frameworks and ORM but those experience only work while you work with it and any rails specific experience is a waste once you leave there, same for ORM. And why PostgreSQL by default? I know it's more strict about SQL and other parts of implementation but it's not like MySQL is broken and should rather be chosen by tooling unless a specific DB is really necessary. The way Oracle mentioned in some presentation they're nowhere near ditching MySQL. As for editors, consider using JetBrains offerings too. Price is nothing if you're serious. VS code is good too.

majewsky 8y ago
PostgreSQL is a good default choice because it is rigorously engineered and offers a wide variety of production equality extensions that mold it into whatever you need it to be. If, halfway through your implementation, it turns out that you need to store GIS data or time series or you need a key-value document store, Postgres can easily do all of that, and you can have everything in one DB (unless it turns out that your requirements are truly special).
Sebb767 8y ago
> but it's not like MySQL is broken Here's a good article about that: https://grimoire.ca/mysql/choose-something-else https://grimoire.ca/mysql/choose-something-else
- evanelias 8y ago
  This article is extremely out-of-date, referring to numerous problems that were solved many years ago. Notice the repeated references to MySQL 5.5, and one reference to how "5.6 is due out soon" -- this indicates the article is 6 years old. Additionally, a number of things in that article are misleadingly worded, and/or show a blatant disregard for information in MySQL's documentation. And a few things are just completely misstated or outright false. I would not consider it a "good article" on this subject.
  - aeonflux 8y ago
    What things are misstated? General arguments are worthless. Anyway I do not recall Postgres being broken few years ago. It had less features, was slower, but was working as expected. Whenever someone points out that some severe problems with given software are already fixed its not building a good rep for the product. If something was seriously broken, yet considered production ready its a bad sign for the feature of this product anyway.
    - evanelias 8y ago
      MySQL wasn't "broken" 6 years ago either. It just required changing a few settings away from their defaults to avoid some of the behaviors in the article, in the few cases where the article's complaints are even valid. A majority of the largest internet properties use MySQL as their primary storage, and have been doing so for years. Do you believe they're all "broken" in their ability to store and retrieve primary product data? As for what's mistated in the article, it would take hours to correct in-depth, but in brief: * All of the "silent data conversion" complaints -- as well as others -- are fixed by setting a strict sql_mode. This has been the default since MySQL 5.7 (2015), but has been available (and recommended as a best practice) since 2004. Literally, one single setting that has been available for 15 years wipes out a solid chunk of this article's complaints. * The backup discussion makes no mention of xtrabackup, the most widely-used free-and-open-source InnoDB binary backup tool. This tool was already in common use when the article was written, so the author is conveniently choosing to ignore it. * MyISAM storage engine is effectively dead, all of the complaints about it in this article are moot. There was no valid reason to use this storage engine when this article was written, let alone today. * The article's discussion on nondeterministic binary logging is overly broad with no examples. Author is complaining that simple inserts with auto_increment aren't safe for binlog, which is completely ludicrous. And all of the rare legit nondeterministic cases are handled by modifying one setting (changing binlog format to either row or mixed; both available when the article was written, and now default since 5.7 in 2015). * Character sets: 4-byte utf8 is the default in mysql 8.0. While the complaints about MySQL's old 3-byte utf8 are valid, the reason for it makes historical sense: when MySQL added utf8 support in early 2003, the utf8 standard originally permitted up to 6 bytes per char at that time, which had excessive storage implications. Emoji weren't yet in widespread use and 3 bytes were sufficient to store the majority of chars in use at that time. I could go on and on. This article is simply not based in reality.
aeonflux 8y ago
Close to 20 years of using both MySQL and PostgreSQL as a programmer but as an sysadmin as well I would pick Postgres any day for everything. YMMV.
LaGrange 8y ago
> I assume Django is similar. I'd say more than Rails. Rails actually doesn't make too many choices about the application itself. Django does - it kinda expect the application to be CMS-y (which is super useful for a _lot_ of work - but not if you're not doing anything CMSy), has default for authentication which aren't great (usernames that aren't emails, for example) and has a sub-standard (but not terrible) ORM. The admin interface is useful in the beginning, but becomes a drag on development as time goes by. Django is workable, so I wouldn't say "stay away," but I wish more companies went with something like Flask + SQL Alchemy. My experience is that people who pick Django often leave companies after a year, leaving a mess for others to clean up. > And why PostgreSQL by default? PostGIS. I know projects that ended up with two databases, because they picked MySQL early, and later needed GIS features.
cherrypepsi 8y ago
I agree. This is spot on. You don't "just use" Rails. I've been trying to learn the Rails conventions ("magic") for weeks now and I feel fucking stupid. It's not the MVC arrangement, it's the inherited behavior from ActiveWhatever that makes it frustrating. The Rails project might be open source but it definitely feels propietary in nature. For reference, I come from using vanilla PHP and Python with Bottle/Flask since ~2010 and I'm confused as hell with it. Also, OP can leverage full stack modern JS now, so sticking to Node for the server side makes sense.

by h1d 8y ago

majewsky 8y ago

PostgreSQL is a good default choice because it is rigorously engineered and offers a wide variety of production equality extensions that mold it into whatever you need it to be. If, halfway through your implementation, it turns out that you need to store GIS data or time series or you need a key-value document store, Postgres can easily do all of that, and you can have everything in one DB (unless it turns out that your requirements are truly special).

Sebb767 8y ago

> but it's not like MySQL is broken Here's a good article about that: https://grimoire.ca/mysql/choose-something-else https://grimoire.ca/mysql/choose-something-else

evanelias 8y ago
This article is extremely out-of-date, referring to numerous problems that were solved many years ago. Notice the repeated references to MySQL 5.5, and one reference to how "5.6 is due out soon" -- this indicates the article is 6 years old. Additionally, a number of things in that article are misleadingly worded, and/or show a blatant disregard for information in MySQL's documentation. And a few things are just completely misstated or outright false. I would not consider it a "good article" on this subject.
- aeonflux 8y ago
  What things are misstated? General arguments are worthless. Anyway I do not recall Postgres being broken few years ago. It had less features, was slower, but was working as expected. Whenever someone points out that some severe problems with given software are already fixed its not building a good rep for the product. If something was seriously broken, yet considered production ready its a bad sign for the feature of this product anyway.
  - evanelias 8y ago
    MySQL wasn't "broken" 6 years ago either. It just required changing a few settings away from their defaults to avoid some of the behaviors in the article, in the few cases where the article's complaints are even valid. A majority of the largest internet properties use MySQL as their primary storage, and have been doing so for years. Do you believe they're all "broken" in their ability to store and retrieve primary product data? As for what's mistated in the article, it would take hours to correct in-depth, but in brief: * All of the "silent data conversion" complaints -- as well as others -- are fixed by setting a strict sql_mode. This has been the default since MySQL 5.7 (2015), but has been available (and recommended as a best practice) since 2004. Literally, one single setting that has been available for 15 years wipes out a solid chunk of this article's complaints. * The backup discussion makes no mention of xtrabackup, the most widely-used free-and-open-source InnoDB binary backup tool. This tool was already in common use when the article was written, so the author is conveniently choosing to ignore it. * MyISAM storage engine is effectively dead, all of the complaints about it in this article are moot. There was no valid reason to use this storage engine when this article was written, let alone today. * The article's discussion on nondeterministic binary logging is overly broad with no examples. Author is complaining that simple inserts with auto_increment aren't safe for binlog, which is completely ludicrous. And all of the rare legit nondeterministic cases are handled by modifying one setting (changing binlog format to either row or mixed; both available when the article was written, and now default since 5.7 in 2015). * Character sets: 4-byte utf8 is the default in mysql 8.0. While the complaints about MySQL's old 3-byte utf8 are valid, the reason for it makes historical sense: when MySQL added utf8 support in early 2003, the utf8 standard originally permitted up to 6 bytes per char at that time, which had excessive storage implications. Emoji weren't yet in widespread use and 3 bytes were sufficient to store the majority of chars in use at that time. I could go on and on. This article is simply not based in reality.

aeonflux 8y ago

Close to 20 years of using both MySQL and PostgreSQL as a programmer but as an sysadmin as well I would pick Postgres any day for everything. YMMV.

LaGrange 8y ago

> I assume Django is similar. I'd say more than Rails. Rails actually doesn't make too many choices about the application itself. Django does - it kinda expect the application to be CMS-y (which is super useful for a _lot_ of work - but not if you're not doing anything CMSy), has default for authentication which aren't great (usernames that aren't emails, for example) and has a sub-standard (but not terrible) ORM. The admin interface is useful in the beginning, but becomes a drag on development as time goes by. Django is workable, so I wouldn't say "stay away," but I wish more companies went with something like Flask + SQL Alchemy. My experience is that people who pick Django often leave companies after a year, leaving a mess for others to clean up. > And why PostgreSQL by default? PostGIS. I know projects that ended up with two databases, because they picked MySQL early, and later needed GIS features.

cherrypepsi 8y ago

I agree. This is spot on. You don't "just use" Rails. I've been trying to learn the Rails conventions ("magic") for weeks now and I feel fucking stupid. It's not the MVC arrangement, it's the inherited behavior from ActiveWhatever that makes it frustrating. The Rails project might be open source but it definitely feels propietary in nature. For reference, I come from using vanilla PHP and Python with Bottle/Flask since ~2010 and I'm confused as hell with it. Also, OP can leverage full stack modern JS now, so sticking to Node for the server side makes sense.