Sam is not an asshole. His twitter is great, he's definitely opinionated, and if you haven't had the luck of meeting him you might misread his tone as grumpy. It's not. It's sarcastic/dry humour and honest.
Perhaps he's quite nice over zoom, but since very few of us are going to meet him in that context, the rest of us are left to judge him by what he posts. And as they say, you never get a second chance to make a first impression.
Based on what I've read so far, with his shit-talking the competition, he seems like... a bit of an asshole.
> he just comes off as funny on twitter once you've met him.
Never heard of the guy before today, but his dickish, edge-lord aura (on X and in this thread) makes me not want to meet him. If I had to choose between buying from him, or some other random dude, I'll hear out the random dude first.
Oh no, how am I ever going to avoid giving my custom to someone who has allegedly cornered the market on - checks notes - a db proxy? Give me a break.
I can think of at least 4 other ways of scaling horizontally without switching DB engines. I'd have to be mightily constrained to have this particular product as the only option.
Sure, I don't doubt your ability to do so yourself. I just question your ability to trust some random unknown figure with your data if you have enough scale. That's quite different, actually.
There's obviously more to the story than outsiders are aware, but personally it just leaves a bit of sour taste in my mouth when the tech and blog posts you guys put out are amazing.
Did anyone say you said anything untruthful? No, they just called you an asshole. You can both be an asshole and be right.
PS - Just some advice that I learned in sales 101 early in my career...focusing on shit talking the competition generally isn't a strategy that works well.
In case you were unaware, if someone's defense against being called an asshole is to say "well nothing I said was false" they're almost certainly an asshole.
I have tabs from like 6 months ago. Modern browsers have gotten pretty good at hibernating unused tabs and restore when needed. And this website is extremely light, it gets restored in milliseconds.
The browser history contains a lot of junk and I don't want that saved forever. Curated tab history is a bit different. It's stupid for sure, but also a bit comforting to keep the most important articles and such. For anything I really care about, there's always ArchiveBox.
If you pay developers x money / day and one of their core tools is down for n hours during the day and they spend their money on HN instead that's pretty straight forward to calculate.
“lol just use a workaround” doesn’t work in an environment with hundreds or thousands of employees coupled with audit, security, and other legal requirements to ship software.
If you're actually bleeding money, you better believe you'll get permissions for a workaround, if you know what you're doing.
It all ties back to the OP, where the issue you've might not be as bad as you think. I have been in situations where we have dropped all procedures to push a hot fix because we were actively bleeding money, and in situations where you know there is an issue, and you let it be.
What an odd hill to die on. Maybe I just lost a $30M client because they wanted an issue fixed now. Maybe my company would get sued for violating their contractual obligations if someone went cowboy to bypass procedures.
Maybe I pay for a service and I want that service to work consistently during core business hours.
Hosting the tournament has nothing to do with it. America is a lucrative market, and on top of that, FIFA can get away with charging insane ticket prices. I'm Canadian and soccer is my primary sport. Unfortunately, on a global level, nobody really cares about Canada or US when it comes to soccer.
it's arguable the "much of the rest of the world" could refer to number of countries rather than number of people, but I think "much of" applies to both so the author avoided the confusion.
one of cool road signs I saw years ago in Ladakh state on road from Manali to Leh. Funnily enough that 19h minibus trip sometimes went through valleys without any form of road, just used least uneven path. Not so funnily enough we had an obvious technical stop later when driver was banging with huge rock on some part of suspension for an hour, and luckily his caveman engineering worked well enough to get us moving again
> (Most) CRUD/OLTP applications don't delete data by timestamp; they delete by primary key. For those workloads, DROP TABLE (or dropping a partition) isn't a palatable option.
Property testing is stochastic, which may be fine, but only gives you a statistically (hopefully) high chance of discovering a problem. If you use something like SPARK/Ada, you can actually embed a proof in the code so that you actually know that the code is correct (for what you've proven). PBT scales better than embedding proofs, though, and is highly effective in practice along with fuzzing.
Unless you literally try every possible combination of inputs (which is usually infeasible), property testing can't give you mathematical guarantees about correctness. You can think of it as a halfway house between classic testing and formal verification:
Classic testing: A human comes up with some concrete example inputs for which they know the "right answers" (corresponding outputs). They write code that runs the code under test, gets its actual outputs, and compares them to the desired outputs.
Property testing: A human comes up with a precise way of randomly generating concrete example (input, desired output) pairs. They write some code to describe how to generate the pairs, often using a declarative DSL that describes only constraints on the inputs and outputs, with the understanding that anything not expressly forbidden is permitted, like "The input can be any list of between 0 and 100 integers each between -500 and 500" and "Every integer in the input must appear the same number of times in the output". They then write some more code (often a single line) to ask the computer to use this "spec" to randomly generate, say, 1000 such pairs, or as many pairs as can be checked in 1s. The computer generates the pairs itself, runs the code under test on each input and and checks its output matches the desired output.
Formal verification: A human comes up with a spec that typically describes conditions that must hold for all (input, output) pairs. This may look very similar to, or even exactly like the DSL used for property testing, though in general there are other conditions that can be expressed that cannot be checked with property testing even in principle -- for example, checking that the program always eventually terminates. The main difference is that the code under test is never actually run; instead, the computer analyses the source code itself to attempt mathematically prove that the stated conditions hold. How to actually accomplish this is a field of active research, but one basic approach is called "symbolic execution". To greatly simplify, if we forget about loops and conditionals for a moment, the idea is that we can write down things we know must be true after each statement executes, based on the things we knew must be true before it executed. So for example if x is a variable initially containing any integer (and we ignore overflow) then after the line
x = x * x
runs, we know that x >= 0. To handle conditionals like
if x > 50:
x = 42
something_afterwards(x)
the prover "forks" into two cases: One in which we know for certain that x > 50, one in which we know for certain that x <= 50. At the end of the if statement it then has the task of recombining what is known about the two cases. In this example, the first case lets us conclude that x = 42 by the end, while the second case lets us conclude that x <= 50 by the end, so it could conclude that x <= 50 either way by the time execution reaches something_afterwards(x). Handling loops is trickier but generally involves looking for invariants.
reply