4 ms·

The response to "MySQL handles our devs’ bugs better" is ¯\_(ツ)_/¯ over and over, but, in my opinion, it's perfectly valid criticism. When writing a tool for re

by euyyn 10y ago

The response to "MySQL handles our devs’ bugs better" is ¯\_(ツ)_/¯ over and over, but, in my opinion, it's perfectly valid criticism. When writing a tool for real-world businesses to use, the path of least resistance needs to lead to bug-free code, and the tool must handle common buggy usage gracefully.

gdulli 10y ago
The path of least resistance should lead to quick and obvious failure rather than a false sense of security that the system is working. Careless development creates a price that has to be paid one way or another. You can't get something for nothing.
- foldr 10y ago
  That's a very good point. Unfortunately, it is not the meaning of "¯\_(ツ)_/¯" in any language that I know of.
  - flooq 10y ago
    ¯\_(ツ)_/¯
- tormeh 10y ago
  If you want your product to succeed it has to be easy to get to work. That means having insecure defaults etc. When a product is in production, people will go through hell to make it work a little better; when they're trying out a product they'll drop it at the slightest inconvenience.
  - gdulli 10y ago
    > When a product is in production, people will go through hell to make it work a little better No they won't. https://www.linux.com/news/about-40000-mongodb-databases-found-open-online https://www.linux.com/news/about-40000-mongodb-databases-fou...
  - pg314 10y ago
    Some people work that way. Other people do a more in-depth evaluation. The first group tends to end up with MySQL, the second with PostgreSQL. I'm painting with a broad brush here, there are situations where it might make more sense to use MySQL. It would be hard to argue that PostgreSQL is not successful. MySQL has a larger market share, but the PostgreSQL project is alive and thriving.
- euyyn 10y ago
  > You can't get something for nothing. If by that you mean that you can't have a developer tool whose "least-resistance" usage leads to anything other than failure (be quick and obvious, or hidden), I'm sorry that that's the nature of the tools you've found. I do think we can have nice things; it's why the level of abstraction of our tools keeps steadily rising over time.
  - gdulli 10y ago
    I put effort into learning the tools I use that are as important as the place where I store all the data. So it's a moot point.
- FunkSQL 9y ago
  Wait, that's not what's happening. We're not talking about something that actually failed but appeared to work. We're talking about something that was maybe poorly used but still worked correctly. That can be genuinely beneficial.
naasking 10y ago
> When writing a tool for real-world businesses to use, the path of least resistance needs to lead to bug-free code, and the tool must handle common buggy usage gracefully. Disagree. There's a reason fail fast and hard is gaining steam as a best practice. The number of latent, surprising or buggy behaviours explodes combinatorially with each layer of a system that acts permissively in this way.
- euyyn 10y ago
  The issues talked about in the presentation aren't caught at compile time, testing, or canarying, by PostgreSQL. The database "failing" here, according to the presentation, meant outages for Uber.
  - naasking 10y ago
    Except these weren't DB failures, they were very clearly programmer failures. And the OP suggested addressing such programming failures by using more permissive tools. But you don't solve failures by making the systems involved more permissive, you solve problems by making them more strict. If the opposite were true, our most reliable systems would be written in bash or perl.
    - euyyn 9y ago
      Take for example opening processes instead of threads. How would you make that more strict? Spin up a VM each time? Is MySQL wrong in using threads?
      - naasking 9y ago
        Strict vs. permissive has little bearing on this question, but it still isn't a valid problem on Uber's part as it's trivially solved by connection pooling.
        euyyn 9y ago
        "Trivially solved by <doing some work> instead of not having to do anything if you used MySQL" is precisely the ¯\_(ツ)_/¯ answer that's just a snarky way to ignore constructive criticism.

by euyyn 10y ago

gdulli 10y ago

The path of least resistance should lead to quick and obvious failure rather than a false sense of security that the system is working. Careless development creates a price that has to be paid one way or another. You can't get something for nothing.

foldr 10y ago
That's a very good point. Unfortunately, it is not the meaning of "¯\_(ツ)_/¯" in any language that I know of.
- flooq 10y ago
  ¯\_(ツ)_/¯
tormeh 10y ago
If you want your product to succeed it has to be easy to get to work. That means having insecure defaults etc. When a product is in production, people will go through hell to make it work a little better; when they're trying out a product they'll drop it at the slightest inconvenience.
- gdulli 10y ago
  > When a product is in production, people will go through hell to make it work a little better No they won't. https://www.linux.com/news/about-40000-mongodb-databases-found-open-online https://www.linux.com/news/about-40000-mongodb-databases-fou...
- pg314 10y ago
  Some people work that way. Other people do a more in-depth evaluation. The first group tends to end up with MySQL, the second with PostgreSQL. I'm painting with a broad brush here, there are situations where it might make more sense to use MySQL. It would be hard to argue that PostgreSQL is not successful. MySQL has a larger market share, but the PostgreSQL project is alive and thriving.
euyyn 10y ago
> You can't get something for nothing. If by that you mean that you can't have a developer tool whose "least-resistance" usage leads to anything other than failure (be quick and obvious, or hidden), I'm sorry that that's the nature of the tools you've found. I do think we can have nice things; it's why the level of abstraction of our tools keeps steadily rising over time.
- gdulli 10y ago
  I put effort into learning the tools I use that are as important as the place where I store all the data. So it's a moot point.
FunkSQL 9y ago
Wait, that's not what's happening. We're not talking about something that actually failed but appeared to work. We're talking about something that was maybe poorly used but still worked correctly. That can be genuinely beneficial.

naasking 10y ago

> When writing a tool for real-world businesses to use, the path of least resistance needs to lead to bug-free code, and the tool must handle common buggy usage gracefully. Disagree. There's a reason fail fast and hard is gaining steam as a best practice. The number of latent, surprising or buggy behaviours explodes combinatorially with each layer of a system that acts permissively in this way.

euyyn 10y ago
The issues talked about in the presentation aren't caught at compile time, testing, or canarying, by PostgreSQL. The database "failing" here, according to the presentation, meant outages for Uber.
- naasking 10y ago
  Except these weren't DB failures, they were very clearly programmer failures. And the OP suggested addressing such programming failures by using more permissive tools. But you don't solve failures by making the systems involved more permissive, you solve problems by making them more strict. If the opposite were true, our most reliable systems would be written in bash or perl.
  - euyyn 9y ago
    Take for example opening processes instead of threads. How would you make that more strict? Spin up a VM each time? Is MySQL wrong in using threads?
    - naasking 9y ago
      Strict vs. permissive has little bearing on this question, but it still isn't a valid problem on Uber's part as it's trivially solved by connection pooling.
      - euyyn 9y ago
        "Trivially solved by <doing some work> instead of not having to do anything if you used MySQL" is precisely the ¯\_(ツ)_/¯ answer that's just a snarky way to ignore constructive criticism.