3 ms·

For instance, we choose Riak+LevelDB some 8 years ago as our data store. It doesn't support SQL but it's fast and easily scalable. And free. I'm not sure if we

For instance, we choose Riak+LevelDB some 8 years ago as our data store. It doesn't support SQL but it's fast and easily scalable. And free. I'm not sure if we could achieve the same speed and fault tolerance with any SQL solution available at that point. So the deal is, you give up your time invested in learning SQL and get some advantages in return. This is reasonable. But if it's only about language, no additional perks, then it just isn't worth investing your time. If continue the parallel with programming languages, there are tons of C-killers nobody knows about. I think, roughly every third programmer in the world tried to write more ergonomical C at some point in their live. And there is Rust. Which is not about ergonomics really but about memory safety combined with comparable performance. No more buffer overflows, no more Heartbleed. People see what they are trading their time on Earth for and the language is getting traction because of that. This is, of course, only my personal opinion but languages are just thin interfaces over technologies.

throwaway_pdp09 6y ago
With respect, I think you're missing a lot. Sit with an expert SQL guy and you'll learn a great deal. Maybe not enough to change your mind but certainly enough to realise you're blocking out a really valuable technology. > but languages are just thin interfaces over technologies No. Not at all. SQL is derived from a mathematical basis. The principle came first, then the language and tech together developed to fulfil it.
- okaleniuk 6y ago
  But that doesn't contradict my point. The mathematical basis matters, sure, but the language on top of it (exactly because it derives from the math anyway) is mostly irrelevant. I don't really care if I have to write SELECT or \forall or σ as long as they all have the same meaning. But I'd prefer to use SELECT because I already spent time learning how to work this way. SQL as a language is fine. There is no real need to reinvent SQL unless you're going to reinvent the math behind it too.
  - throwaway_pdp09 6y ago
    2 points then; 1. Do you know SQL currently? Because your previous comments implied you don't 2. SQL is a bad implementation of the underlying relational model. And it's just bad in other ways. For one, it's bloody wordy: select * from people but as SQL is an expression language, why not? people From an answer of mine a few days ago (slightly modified here) to pick out differences: ( select * from t1 except select * from t2 ) union ( select * from t2 except select * from t1 ) I'd prefer to write that crap as (t1 \ t2) + (t2 \ t1) or similar. If you write a lot of SQL, that matters. SQL aggregates don't nest easily. Transactions are screwed up (https://news.ycombinator.com/item?id=23569513 https://news.ycombinator.com/item?id=23569513). SQL is poorly composable (https://news.ycombinator.com/item?id=23550420#23561301 https://news.ycombinator.com/item?id=23550420#23561301). For better or worse it has nulls therefore tristate logic. This causes errors! And more. BTW. transactions don't work in the way you might think, atomically. Which is why MS added https://docs.microsoft.com/en-us/sql/t-sql/statements/set-xact-abort-transact-sql?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/t-sql/statements/set-xa... and I'm sure Pgres has similar. From the link: "When SET XACT_ABORT is OFF, in some cases only the Transact-SQL statement that raised the error is rolled back and the transaction continues processing" That peculiarity is from the standard BTW. SQL is problematic. It could have been much better.

throwaway_pdp09 6y ago

With respect, I think you're missing a lot. Sit with an expert SQL guy and you'll learn a great deal. Maybe not enough to change your mind but certainly enough to realise you're blocking out a really valuable technology. > but languages are just thin interfaces over technologies No. Not at all. SQL is derived from a mathematical basis. The principle came first, then the language and tech together developed to fulfil it.

okaleniuk 6y ago
But that doesn't contradict my point. The mathematical basis matters, sure, but the language on top of it (exactly because it derives from the math anyway) is mostly irrelevant. I don't really care if I have to write SELECT or \forall or σ as long as they all have the same meaning. But I'd prefer to use SELECT because I already spent time learning how to work this way. SQL as a language is fine. There is no real need to reinvent SQL unless you're going to reinvent the math behind it too.
- throwaway_pdp09 6y ago
  2 points then; 1. Do you know SQL currently? Because your previous comments implied you don't 2. SQL is a bad implementation of the underlying relational model. And it's just bad in other ways. For one, it's bloody wordy: select * from people but as SQL is an expression language, why not? people From an answer of mine a few days ago (slightly modified here) to pick out differences: ( select * from t1 except select * from t2 ) union ( select * from t2 except select * from t1 ) I'd prefer to write that crap as (t1 \ t2) + (t2 \ t1) or similar. If you write a lot of SQL, that matters. SQL aggregates don't nest easily. Transactions are screwed up (https://news.ycombinator.com/item?id=23569513 https://news.ycombinator.com/item?id=23569513). SQL is poorly composable (https://news.ycombinator.com/item?id=23550420#23561301 https://news.ycombinator.com/item?id=23550420#23561301). For better or worse it has nulls therefore tristate logic. This causes errors! And more. BTW. transactions don't work in the way you might think, atomically. Which is why MS added https://docs.microsoft.com/en-us/sql/t-sql/statements/set-xact-abort-transact-sql?view=sql-server-ver15 https://docs.microsoft.com/en-us/sql/t-sql/statements/set-xa... and I'm sure Pgres has similar. From the link: "When SET XACT_ABORT is OFF, in some cases only the Transact-SQL statement that raised the error is rolled back and the transaction continues processing" That peculiarity is from the standard BTW. SQL is problematic. It could have been much better.