4 ms·

All the standard web technologies are still relevant. MySQL & PostgreSQL are still relevant. Redis is still relevant. Ruby on Rails is still relevant. Javas

by fouc 8y ago

All the standard web technologies are still relevant. MySQL & PostgreSQL are still relevant. Redis is still relevant. Ruby on Rails is still relevant. Javascript is still relevant.

ramblerman 8y ago
Some of those are even more relevant these days. - JS has only grown in ubiquity and maturity of the language. - postgres also seems to be on a comeback now the honeymoon phase of nosql is over.
- rimliu 8y ago
  > JS has only grown in ubiquity and maturity of the > language. Well… if you say so. In my eyes a couple of sugarcoating patches do not make language mature. Standard library is still nowhere to be found.
- cutler 8y ago
  JS - mature? It still has no standard library and probably never will.
lmm 8y ago
Disagree with all of those except Javascript (and that only as an execution layer). All of the things that those technologies promised, we now have better ways of achieving.
- robenkleene 8y ago
  Yet here we sit in entire thread that’s the perfect place to discuss these “better ways” of doing things and I'm seeing zero consensus about what those better ways might be. Are other people interpreting this thread differently?
  - lmm 8y ago
    There's no clear consensus on which way is best. That doesn't mean there aren't better and worse ways.
- your-nanny 8y ago
  better than postgresql? and what would that be?
  - lmm 8y ago
    Depends what you were trying to achieve with it; for the various things I've seen it used for a mix of protobuf-in-flat-files, Cassandra, and Spark.
    - KurtMueller 8y ago
      I don't know the kind of work you do, but in the work I do, postgresql offers a lot of bang for your buck and works for me in the majority of all my web apps. The fact that I have one backend that can accomplish so much at good performance is a win for me.
      - lmm 8y ago
        The problems I have with postgresql in a web backend context are: Limited support for master/master replication (for availability); there are various approaches but none of them is really first-class in terms of driver support etc. Limited support for async (non-blocking) connection in a lot of languages. Again, it's often an option but not really first-class. Limited support for working with non-square-table data (even just simple things like having a "column" that holds a collection). Again supported by the server but often not really first-class in the driver etc. Rarely clear what the performance behaviour of a given query is going to be - you can write a query that looks exactly like an indexed join (fast) but it will silently decay into a table scan (very slow). Performance is slowed by mandatory transaction functionality that hardly ever makes sense in the context of a web app. You have to have a lot of indexes (otherwise you'll get aforementioned silent slow queries) but Postgresql will insist on updating all of those indexes before it will ever acknowledge a write. The overwhelming majority of the time, what you really want in a web app context is a "deferred index", but Postgresql doesn't have those; your only options are to wait for all index updates to happen or to do a fire-and-forget write without getting an acknowledgement at all. The design encourages you to run reporting queries/aggregations without any separation from your "live" operational updates. Because of the aforementioned mandatory transaction isolation that you're almost certainly not actually getting any value out of, it's very easy for those reporting queries to block, deadlock, or slow down your live operations. The tooling around tracking and restricting slow queries is very limited, and because of the aforementioned unclear performance it's not always obvious which queries are going to be slow ahead of time. Aggregation has to be done in a horrible pseudo-English query language where it's impossible to compose more than one query together. Also, even simple key lookups use this language, meaning a lot of time wasted in parsing (I once saw profiling results that something like 3/4 of the time taken to process a simple pkey fetch was spent parsing the query). A lot of serious engineering effort goes into these systems, but most of it is wasted in a web backend context. (Indeed for a long time the most popular RDBMS for web backends was MySQL, despite it (at the time) having very little support for all the supposedly-important RDBMS features like ACID). If the RDBMS was invented today I don't think anyone would use it for a web backend - it just makes the wrong tradeoffs for that context.
- goobynight 8y ago
  What are the better ways?

by fouc 8y ago

All the standard web technologies are still relevant. MySQL & PostgreSQL are still relevant. Redis is still relevant. Ruby on Rails is still relevant. Javascript is still relevant.

ramblerman 8y ago

Some of those are even more relevant these days. - JS has only grown in ubiquity and maturity of the language. - postgres also seems to be on a comeback now the honeymoon phase of nosql is over.

rimliu 8y ago
> JS has only grown in ubiquity and maturity of the > language. Well… if you say so. In my eyes a couple of sugarcoating patches do not make language mature. Standard library is still nowhere to be found.
cutler 8y ago
JS - mature? It still has no standard library and probably never will.

lmm 8y ago

Disagree with all of those except Javascript (and that only as an execution layer). All of the things that those technologies promised, we now have better ways of achieving.

robenkleene 8y ago
Yet here we sit in entire thread that’s the perfect place to discuss these “better ways” of doing things and I'm seeing zero consensus about what those better ways might be. Are other people interpreting this thread differently?
- lmm 8y ago
  There's no clear consensus on which way is best. That doesn't mean there aren't better and worse ways.
your-nanny 8y ago
better than postgresql? and what would that be?
- lmm 8y ago
  Depends what you were trying to achieve with it; for the various things I've seen it used for a mix of protobuf-in-flat-files, Cassandra, and Spark.
  - KurtMueller 8y ago
    I don't know the kind of work you do, but in the work I do, postgresql offers a lot of bang for your buck and works for me in the majority of all my web apps. The fact that I have one backend that can accomplish so much at good performance is a win for me.
    - lmm 8y ago
      The problems I have with postgresql in a web backend context are: Limited support for master/master replication (for availability); there are various approaches but none of them is really first-class in terms of driver support etc. Limited support for async (non-blocking) connection in a lot of languages. Again, it's often an option but not really first-class. Limited support for working with non-square-table data (even just simple things like having a "column" that holds a collection). Again supported by the server but often not really first-class in the driver etc. Rarely clear what the performance behaviour of a given query is going to be - you can write a query that looks exactly like an indexed join (fast) but it will silently decay into a table scan (very slow). Performance is slowed by mandatory transaction functionality that hardly ever makes sense in the context of a web app. You have to have a lot of indexes (otherwise you'll get aforementioned silent slow queries) but Postgresql will insist on updating all of those indexes before it will ever acknowledge a write. The overwhelming majority of the time, what you really want in a web app context is a "deferred index", but Postgresql doesn't have those; your only options are to wait for all index updates to happen or to do a fire-and-forget write without getting an acknowledgement at all. The design encourages you to run reporting queries/aggregations without any separation from your "live" operational updates. Because of the aforementioned mandatory transaction isolation that you're almost certainly not actually getting any value out of, it's very easy for those reporting queries to block, deadlock, or slow down your live operations. The tooling around tracking and restricting slow queries is very limited, and because of the aforementioned unclear performance it's not always obvious which queries are going to be slow ahead of time. Aggregation has to be done in a horrible pseudo-English query language where it's impossible to compose more than one query together. Also, even simple key lookups use this language, meaning a lot of time wasted in parsing (I once saw profiling results that something like 3/4 of the time taken to process a simple pkey fetch was spent parsing the query). A lot of serious engineering effort goes into these systems, but most of it is wasted in a web backend context. (Indeed for a long time the most popular RDBMS for web backends was MySQL, despite it (at the time) having very little support for all the supposedly-important RDBMS features like ACID). If the RDBMS was invented today I don't think anyone would use it for a web backend - it just makes the wrong tradeoffs for that context.
goobynight 8y ago
What are the better ways?