More scientists doubt salt is as bad for you as the government says - <AUTHOR> http://www.washingtonpost.com/blogs/wonkblog/wp/2015/04/06/more-scientists-doubt-salt-is-as-bad-for-you-as-the-government-says/ <comment><USER2> >>How could something as simple as salt stymie scientists for so long?

The human body has numerous overlapping pathways for salt regulation. Salt (sodium chloride) plays a major role in the osmolality (electrolyte concentration) of blood. A drop in the sodium concentration results in the release of renin, which causes changes in vascular constriction, sympathetic activity, and sodium reabsorption itself.

This seems like a great research question for systems biology, although it would require some detailed modeling.

<comment><USER3> Electrolyte balance in general seems like a good research question. We load our food with sodium chloride, but natural diets are far higher in potassium chloride. The relationship between the various electrolytes is something about which we know very little.

<comment><USER4> The function of the various proteins used in the sodium-potassium pump, which transports Na+ out of cells and K+ into cells, against their natural diffusion gradient, suggests that the ratio between Na+ ions and K+ ions in the diet, and their relative concentrations in intercellular fluid is far more important than the absolute quantity you consume.

If your Na+ to K+ balance is healthy, consuming too much of both could be solved as easily as drinking more water.

But consuming too little of either one will cause the sodium-potassium pumps to function poorly.

My hypothesis is that there is an optimal ratio of Na+ to K+ such that the saltiest water (containing only NaCl and KCl) that a human could drink for prolonged periods without observable ill effects has that ratio. A different ratio would require more water for the kidneys to clear the ions present in excess, and that would lower the total concentration of dissolved salts.

Learning that value could possibly enable the production of drinkable water by partial desalination with potassium supplementation rather than complete desalination. I have heard that water that is 40% seawater and 60% freshwater can sustain someone in a survival emergency. Perhaps 50% seawater and 50% dilute potassium chloride solution could extend the water supply on a life raft by another 20%? You could hardly do the experiment if an ethical monitor for human experimentation thinks that supplying that much of an absolute quantity of dietary sodium is dangerous, independent of relative concentrations.

<comment><USER3> Instinctually, I'd be a little wary of that, because Na+ and Ka+ do more than act as ions within the neurological system. I'm not sure a higher concentration, even at the right relative concentrations, wouldn't have adverse effects.

<comment><USER4> It's a bit difficult to figure out the highest concentration that doesn't have adverse effects if you're not allowed to produce adverse effects.

<comment><USER3> We could probably do this with an animal model for testing, and work up to human subjects pretty quickly.

</comment></comment></comment></comment></comment></comment><comment><USER5> Ben Goldacre, who does a lot for public understanding of health and science, among other things including being a GP for the NHS, is often asked for some positive health advice after he warns about the worthless-at-best value of most health advice. If I recall correctly, his response is always "Try to increase the amount of fresh fruit and veg in your diet, try to reduce alcohol and cigarettes, do some exercise.".

Also, this comedy sketch from Fry & Laurie is relevant, especially the "too much is bad for you" rant at 2m00s.

[https://youtu.be/XV4yK-26smM](https://youtu.be/XV4yK-26smM)

<comment><USER6> Fruit might be good for it's vitamins, but in moderation. Increasing fructose consumption after a certain threshold - which could be easily crossed when increasing it's consumption - would not necessarily be a good thing.

<comment><USER7> Do you have a reputable source for that? Fruit is definitely good for more than its vitamins.

Also, we are not monkeys anymore, but monkeys eat a lot of fresh raw fruit. Arguably they climb trees while doing so but eating like a monkey seems like a relatively safe thing to do to me.

<comment><USER4> Elephants and manatees are closely related, as well, but I would not recommend that they look to one another for dietary recommendations.

Speciation can occur when different populations fill different niches. Human physiology (along with still extant hunter-gatherer cultures) indicates that we are opportunistically omnivorous cursorial hunters. The species closest to us genetically are opportunistically omnivorous frugivores. Chimps and bonobos eat fruits and nuts most of the time, and eat monkeys maybe once a month. If you want to consult the animal kingdom for dietary advice, look to wolves for the meat and bears for everything else.

Eat like a bear until you see a potential prey animal, then run it down and eat it like a wolf. When you finish, switch back to bear mode. That seems like a relatively safe diet to me.

</comment></comment></comment></comment><comment><USER8> The article covers its chosen areas pretty well. Additionally, there are aspects missed in the article.

The Puritan angle is important. If you're not making people feel guilty about enjoying something, its hard to control them, and any attack on any form of Puritanism is fundamentally an attack on all forms of Puritanism. So "salt is OK" is going to fundamentally offend innumerable superficially unrelated individuals who rely on guilt as social control in entirely non-food related areas.

Tied in with the above, bland tasteless food isn't in as much demand as flavorful tasty food. If the average American were dangerously anorexic then a viable public health strategy would be to encourage salty food because it'll taste somewhat better than bland salt free food and optimistically people will eat more preventing anorexia. Obviously a visit to walmart will cure any inaccurate belief about the average American being too skinny to be healthy. So anti-salt is at least somewhat anti-obesity. Making stuff taste bad, is good, if people are fat.

Finally (insert small percentage) of people are salt sensitive and it raises their blood pressure. The other (vast majority percentage) just sweat or pee out excess salt with no effect on their blood pressure. This results in two interesting political issues. One is that financially we're better off telling everyone to eat bland food so we don't have to spend money figuring out who's in the susceptible minority or provide parallel logistical tracks of food. The other is that the mere existence of differences offends certain political beliefs about equality of outcome.

</comment><comment><USER9> It's sad that we've known this for many years [http://www.sciencemag.org/content/281/5379/898.summary](http://www.sciencemag.org/content/281/5379/898.summary) but still incredible amounts of effort have been utterly wasted on pushing low salt diets. And as the article describes, this will continue. Truly the study of salt is political science.

</comment><comment><USER10> Looks like the dietary "guidelines" of the past decades are essentially BS. Especially the "low-fat" wave that came as a consequence.

At least low salt consumption has no consequences (of course if you abstain completely from salt it will have, I'm talking about "normal" low consumption here, however salt replacements, high in potassium, may have)

<comment><USER11> > I'm talking about "normal" low consumption here

Well, not really:

FTA:

 _Then, this past August, the New England Journal of Medicine published the results of a massive research effort known as the PURE study. It indicated that people who conform to the U.S. recommended limits actually have more heart trouble._

[...]

 _Under the current dietary guidelines, too much is more than 2,300 milligrams of sodium per day - the amount of sodium in a teaspoon of salt. (For people over 50, and for African-Americans, the current recommended intake is even lower - 1,500 milligrams per day.)

If the U.S. salt warnings are correct, Americans are indeed endangering themselves on a massive scale. Americans typically go way over the limit, ingesting about 3,500 milligrams per day.

If the skeptics are correct, on the other hand, most Americans are fine. In their view, a typical healthy person can consume as much as 6,000 milligrams per day without significantly raising health risks. But consuming too little - somewhere below 3,000 milligrams - also raises health risks, they say._

<comment><USER10> Interesting

I was thinking about this [http://en.wikipedia.org/wiki/Hyponatremia](http://en.wikipedia.org/wiki/Hyponatremia) but it's not necessarily caused by "too little salt"

</comment></comment></comment><comment><USER12> I wonder when they will stop with this one-size-fits all advice? I guess it's because of this ideal that all humans are equal that pervades our culture, which causes many to assume that all people are fundamentally the same. However, every human is biochemically unique. A diet that works well for one person doesn't necessarily work well for another.

I also think it's a mistake to look at any single nutrient or food in isolation, and ask, is this healthy? It's impossible to answer that, because whether or not something is healthy depends on the rest of the diet. For example, is broccoli healthy? If the rest of your diet consists of fast food, then clearly adding some broccoli would be a good idea. But if the rest of your diet already contains tons and tons of vegetables, then perhaps you have a serious gas problem, and you would be better off avoiding adding broccoli to your diet.

EDIT: I remembered that I read somewhere that sodium "competes" with potassium in the body. Apparently, if you consume a lot of potassium, then you can tolerate more sodium.

</comment><comment><USER13> The headline and some commenters are misrepresenting the debate. From the article:

 _Both sides agree that eating too much salt, especially for people with high blood pressure, can be dangerous.

The critical disagreement concerns how to define "too much."

Under the current dietary guidelines, too much is more than 2,300 milligrams of sodium per day

... If the skeptics are correct ... a typical healthy person can consume as much as 6,000 milligrams per day without significantly raising health risks._

</comment><comment><USER14> _For people over 50, and for African-Americans, the current recommended intake is even lower - 1,500 milligrams per day._

I am intrigued by the current guideline for African-Americans. Does anyone know what is the rationale behind this stricter limit?

<comment><USER15> A greater incidence of high blood pressure, which salt is believed to exacerbate.

<comment><USER16> I prescribe a diet of not being subject to the constant stress of racist micro-aggressions.

<comment><USER17> People with dark skin can experience vitamin D deficiency in northern climates. One of the many symptoms is hypertension. Some estimates are that you need 10 times more sun exposure to produce the same amount of vitamin D as a person with pale skin.

<comment><USER16> This does not suggest reducing salt, but rather supplementing vitamin D. It also doesn't rule out stress as a distinct, parallel cause.

<comment><USER17> Who says it does?

</comment></comment></comment></comment></comment></comment><comment><USER18> > The answer is that, despite the dietary claims that are made for all kinds > of foods, actually substantiating how eating influences human health is > notoriously difficult.

This. Have you noticed how recommendations change over years? Nutritionists don't have much of a clue, but press usually takes them by the face value and makes a new truth out of their words.

<comment><USER19> We actually know a lot about nutrition, but if something are good for A and bad for B and you only learn about this stuff through several intermediaries. Then it's going to come across in a very odd miss mash of conflicting reports.

Diabetes, heart disease, and Crohn's are just a few examples where diets can make a huge difference.

Don't beleve me? Feel free to avoid vitamin C. Wait, no that's a bad idea.

PS: Now if you're in the search for optimum heath then yea that's a huge unknown. But, if you ever talk to a nutritionist they can actually back up their advice.

<comment><USER20> I don't think Crohn's fits your pattern here. My expertise/bias is that I've had it for about 35 years.

The topic here is controlling body systems based on the _chemistry_ of what's being consumed.

A Crohn's diet has two important factors, which don't really look at the chemicals introduced into the body very much at all. Most important is a purely mechanical component: because scar tissue and adhesions can cause strictures, areas of limited diameter and stretch in the intestines, it's necessary to avoid stuff that might get stuck, like popcorn and other seeds. A second issue, possibly more important but only very poorly understood, is the environment presented to intestinal flora. There's chemistry to that (like carb mix) but, not with respect to the parent organism.

<comment><USER19> Most people with Chron's disease should avoid spicy food due to chemical irritation and sure the mechanical issues are also important.

However, a nutritionist will suggest a _heathy_ low fiber diet when dealing with a partial obstruction etc. Eggs vs red meat might seem like a simple change, but once a range of dietary restrictions show up a heathy diet becomes a lot more difficult.

Anyway my point was there is a lot of practical diet research out there.

PS: Chrones also frequently causes issues with nutrient absorption and a high protein diet is useful for healing. So, there are some classically nutrition based changes.

</comment></comment></comment></comment><comment><USER21> Even if salt _per se_ isn't bad for you, if you avoid sodium, that forces you to make healthier food choices. There is a correlation between "crap food" and "loaded with salt". Or, more generally, "loaded with sodium".

This is simply because the addition of sodium compounds to food is a processing step. Right off the bat, anything which contains lots of sodium is almost certainly a processed food.

Let's look at it another way: Q: what do a slice of fresh meat or fish, a carrot and an apple have in common? A: no added sodium! No salt, no baking powder, no monosodium glutamate, ...

Salt is also abused by senseless cooks who don't take pride in creating flavor. They just throw stuff together and douse it with salt. You can almost measure a restaurant by how salty are the offerings. Approximately, the saltier the cooking, the more they just care about money (and therefore use lower quality ingredients, which they mask with salt or salt-containing sauces, flavor enhancers like MSG, or excessive spicing).

</comment><comment><USER22> From my own experience, I'd say that the right amount of salt is highly dependent on your diet. For example, when I restrict my carb intake I notice I need to add more salt to my food or I will get cramps and feel generally dehydrated. Drinking more water doesn't help, I just go to the bathroom more often. Adding more salt to my food works, however.

Unfortunately, I can find absolutely no scientific evidence to back this theory up. I just try to listen to the signals from my body, and it works for me.

<comment><USER23> One of the meds I'm on is a potassium-sparing diuretic (spironolactone), so I actually need _more_ sodium than most people lest I mess up my electrolyte balance and get leg cramps.

</comment></comment><comment><USER24> Why salt has to be bleached and what minerals are added to it?

<comment><USER2> I'm not sure what you mean by bleaching. Salt is a mineral (it's sodium chloride - NaCl). The only other mineral "added to it" is iodine in iodized salt. The iodine is added to prevent iodine deficiency.

<comment><USER25> Nothing to do with bleaching, but have you ever bothered to look up the actual ingredients of table salt? Morton's, for instance, is >99% NaCl, yet also contains dextrose and calcium silicate.

[http://www.mortonsalt.com/faqs/food-salt- faqs](http://www.mortonsalt.com/faqs/food-salt-faqs)

</comment></comment></comment><comment><USER26> When I was younger I played competitive sports and used to suffer from cramping relatively often. I cured this condition by adding a pinch of celtic sea salt to a glass of water in the morning.

The only thing dangerous about salt is table salt that is bleached and has chemicals added. If you can get good salts like himalayan pink salt and celtic sea salt, you are in the money.

Salt is the most efficient nutrient for the body. Provides essential minerals as well as a sleuth of other positive health properties.

edit: Pink salt is not pink because more chemicals were added.

Check out this link: [http://healthwyze.org/index.php/component/content/article/11...](http://healthwyze.org/index.php/component/content/article/115-the- truth-about-table-salt-and-the-chemical-industry.html)

 _The more common "refined" table salts have been been stripped of their minerals during processing, which manufacturers then sell to supplement companies. It makes the unmistakable point that the producers of table salts are intentionally stripping what they know to be the most nutritious part of the salt, and actually increasing profits by malnourishing their own customers._

<comment><USER27> > The only thing dangerous about salt is table salt that is bleached and has > chemicals added. If you can get good salts like himalayan pink salt and > celtic sea salt, you are in the money.

You're mixing paranoias here. Pink/sea salt differ from table salt primarily in that they have _more_ chemicals - that's what gives them more color/flavor. If you're concerned with the iodine supplementation, enjoy your goiter...

Fearmongering about bleach in salt is a little weird considering its chemical formula is NaClO and its primary component is used to make your tap water safe to drink. When used, it degrades to water and salt as the oxygen pops off to oxidize impurities.

<comment><USER28> >When used, it degrades to water and salt as the oxygen pops off to oxidize impurities.

Are you saying that the chlorine in drinking water turns to salt through oxidization? How is the Na added, specifically? I'm asking because when I moved to NYC from Denmark, I initially had a hard time _even eating salad_ at restaurants because I could taste the chlorine from the tap water it was rinsed in. Is it just because there will always be pure chlorine remnants in the water?

I'm genuinely curious.

<comment><USER27> The water supply around here uses sodium hypochlorite, not pure chlorine gas.

[http://en.wikipedia.org/wiki/Sodium_hypochlorite#Water_treat...](http://en.wikipedia.org/wiki/Sodium_hypochlorite#Water_treatment)

</comment></comment></comment></comment><comment><USER29> At the end of the day it is utterly irrelevant ... the US has a major food issue, only seconded by the fat Mexicans - and salt is certainly not any major problem here. Most likely the findings simply imply that our body copes well with a bit "too much" or "too little" salt intake from nuitrition. I mean you still get plenty of "salt" from your water.

The problem is sugar, carbonhydrate-based food, red meat and fat, fat, fat - everytime I watch documentaries about the US (f.x. about the fucked up prison system) I wonder about how it is possible that almost every single police guy or warden is that _fat_ \- or the other extreme a bulk of muscles. I mean sorry - but salt - that's nothing the US has to worry about.

<comment><USER30> Go back or forward or sideways a few months and you'll find people authoritatively saying what you just said with all the nouns rearranged (turns out fat isn't so bad! etc). Modern nutrition seems like an endless merry-go- round mindfuck. (Not saying non-modern is any better of course)

<comment><USER29> Of course "fat isn't so bad!" ... but it is, if you live off fast food like a significant part of the US population.

Also "fat <> fat" ... I eat every day at least one tablespoon of linseed oil. And that is very good for me and my brain :)

<comment><USER31> And how exactly do you know that it is good for you and your brain?</comment></comment></comment></comment>


Show HN: My side project - <AUTHOR>

Hello HN!
I've been building the website for my weekend floor hockey pick up group. I wanted your opinions.
http://www.shl-wpg.ca/
The site design is a free open source CSS template that I cut up. It isn't pretty but it works (I am not a designer). I've been building it in my free time for the past few months.
SHL (Sunday Hockey League) is a group of us that have been getting together almost every sunday to play floor hockey for the past 8 years. We keep track of goals and the first assist. The guy organizing it used to hand roll all the stats in excel sheets and email them out to people. It used to take him 3 hours for 1 Sunday's worth of stats. It now takes him about 5 minutes with the site.
OK HN, give me your comments, questions and concerns! braces for impact <comment><AUTHOR> If anything, check out the player list of stats

<http://www.shl-wpg.ca/playerList.php>

Or an individual player

<http://www.shl-wpg.ca/playerDetails.php?playerid=48>

</comment><comment><AUTHOR> Link: <http://www.shl-wpg.ca/></comment>


Recently minted database technologies that I find intriguing - <AUTHOR> https://lucperkins.dev/blog/new-db-tech-1/ <comment><USER2> I edit a database newsletter – [https://dbweekly.com/](https://dbweekly.com/) – so tend to always have my eyes out for new releases, what's coming along, and what not. And I thought I'd share a few more things that have jumped out at me recently in case anyone's in the mood for spelunking.

1\. QuestDB – [https://questdb.io/](https://questdb.io/) – is a performance- focused, open-source time-series database that uses SQL. It makes heavy use of SIMD and vectorization for the performance end of things.

2\. GridDB - [https://griddb.net/en/](https://griddb.net/en/) \- is an in- memory NoSQL time-series database (there's a theme lately with these!) out of Toshiba that was boasting doing 5m writes per second and 60m reads per second on a 20 node cluster recently.

3\. MeiliSearch - [https://github.com/meilisearch/MeiliSearch](https://github.com/meilisearch/MeiliSearch) – not exactly a database but basically an Elastic-esque search server written in Rust. Seems to have really taken off.

4\. Dolt – [https://github.com/liquidata- inc/dolt](https://github.com/liquidata-inc/dolt) – bills itself as a 'Git for data'. It's relational, speaks SQL, but has version control on everything.

TerminusDB, KVRocks, and ImmuDB also get honorable mentions.

InfoWorld also had an article recently about 9 'offbeat' databases to check out if you want to go even further: [https://www.infoworld.com/article/3533410/9-offbeat- database...](https://www.infoworld.com/article/3533410/9-offbeat-databases- worth-a-look.html)

Exciting times in the database space!

<comment><USER3> Has anybody tried using Dolt? It looks quite young.

I think this idea is really valuable, but I usually see it implemented as a time-series extension on top of Postgres or MySQL, like SQLAlchemy-Continuum or TimescaleDB. i.e. you caan get most of the useful git-like time-travel semantics (modulo schema migrations) out of timeseries data with a separate transaction history table.

I'm curious what Dolt's performance profile looks like (i.e. how reads and writes scale vs "branch"-count, row-count, and how they handle indices across schema migrations), since the aforementioned solutions on Postgres are building on an already-very-performant core.

edit: TerminusDB also looks very cool, although it's approaching this problem from a graph-database angle rather than a relational one. Their architecture (prolog server on top of a rust persistence core) also seems super fascinating, I'd love to read more on how they chose it.

<comment><USER4> I work as a SWE at a large AI consultancy. We've been experimenting with "git for data" products for a while, and we've been trying to get rid of them (notably Pachyderm) for -at least- 2 years.

What they all share is a) awful performances, and b) bad design.

Git semantics, ("branche", "merge", "commit") are not well suited for data, because merging dataframes and creating "branches" often leads to misunderstandings and delays. Time travel is very nice to have, but it's often the case where you would like to consume your input datasets at different point in time in the same repository (unless you do one dataset per repository, but then, what's the point ?).

Performances are bad, because all updates needs to go through some kind of coordination mechanism (etcd, zookeeper, or raft directly). In a single instance scenario, you often end-up flooding it or needing additional memory to cope with the load. However, you could deliver high throughput and high availability by using proper sharding and distributing updates to specific masters (like you would do in any actor-based architecture).

As a replacement, we're now using a custom event-sourcing framework on top of AWS S3/Azure blob. It's faster, more reliable, and most importantly, better designed.

<comment><USER5> We're building a very literal "git for data" product, Dolt. (doltdb.com). I'm very curious about this criticism:

> Git semantics, ("branche", "merge", "commit") are not well suited for data, > because merging dataframes and creating "branches" often leads to > misunderstandings and delays.

Can you give a concrete example of what you mean? I'm wondering if this is a failing of the tool you're using or the model itself?

> Time travel is very nice to have, but it's often the case where you would > like to consume your input datasets at different point in time in the same > repository

Dolt supports doing exactly this. See my reply to a child comment below.

> Awful performance

It's not obvious to me why this needs to be true in the general case, unless it's caused by b) bad design. Are you mostly talking about write performance, or are reads also a problem?

<comment><USER4> I don't want you to take it personally, but, from my point of view, Dolt falls in the same bucket as DVC, Pachyderm and some others. The shortcomings are not from the tools themselves, it's a fundamental issue with the design.

First, branching and merging. In git, branching allows you to make uncoordinated parallel progress for the price of a reconciliation step. In a datastore, you want the exact opposite: A single, consistent, available source of truth. Having different branches of the same dataset bring more confusion while solving zero problem.

Then, commits. In git, a commit represent a snapshot of the entire state of your repository. This is particularly attractive because it guarantees that your code will build no matter what kind of update will follow (without incidence: editing a readme ; severely destructive: removing an src folder). In a datastore, this is nice but unnecessary. As I mentioned it in this thread, datasets move at different speeds, and attaching an new hash to something that didn't change doesn't add value. However, I have to recognize, I failed to mention earlier that datasets are often unrelated and not relational. This would be to reconsider if it were the case, of course. Most of the time, a dataset is represented as a single dataframe (or a single collection of dataframes).

There some points where git semantics make sense: immutability of commits, linearizability within branches. Both are extremely important if you want to enable reproducibility of your pipeline. These are traits coming from Event Sourcing.

Reproducibility is also claimed by DVC and Pachyderm, but their issue here is more a problem of trying to do too much things at once but not managing to do it right. Running code within Pachyderm pipelines was a recipe for disaster and the first thing we got rid of.

As for performances, the write side is where it matters, because it needs to be coordinated. Reads almost never are an issue with good caching. In any case, it should be robust enough to fill the gap between csv files sent to s3 and a full kafka cluster, eg: not complaining for a few TB. To my knowledge, the only multi-leader datastore suitable for storing sharded datasets as a continuous log is Kafka.

</comment></comment></comment></comment></comment><comment><USER6> I've always felt it strange that in almost every job I've had databases have been one of the most important pieces of the architecture but the least debated. I've spent hours debating languages and frameworks, but databases always come down to whatever we have a license for/what others at the company are using. Engineering teams will always say they make sure to use the right tool for the job, but no one ever talks about if it's right to keep using the same database for a new product.

<comment><USER7> My experience is places with DBAs tend to keep very tight control over database design than those who do without. I've worked at several places where developers did not touch the database schema. They couldn't even propose changes, instead, you'd give the DBA team the requirements and they would give you a solution.

</comment></comment><comment><USER8> Materialize is neat, but there are other database systems that refresh at least some materialized views on the fly, while being smart about not rebuilding the entire view every time. See for example, Oracle, where FAST REFRESH ON COMMIT does most of what Materialize is advertised as doing, at least for views which that feature can support (restriction list here: [https://stackoverflow.com/questions/49578932/materialized- vi...](https://stackoverflow.com/questions/49578932/materialized-view-in- oracle-with-fast-refresh-instead-of-complete-dosnt-work) ). Mind you, this comes with Oracle's extremely hefty price tag, so I'm not sure I'd recommend it to anyone who isn't already stuck with Oracle, but it is technical precedent.

It would be interesting to compare notes, and see what Materialize does better.

<comment><USER9> Hi folks. Frank from Materialize here.

The main differences you should expect to see are generality and performance.

Generality, in that there are fewer limitations on what you can express. Oracle (and most RDBMSs) build their Incremental View Maintenance on their existing execution infrastructure, and are limited by the queries whose update rules they can fit in that infrastructure. We don't have that limitation, and are able to build dataflows that update arbitrary SQL92 at the moment. Outer joins with correlated subqueries in the join constraint; fine.

Performance, in that we have the ability to specialize computation for incremental maintenance in a way that RDBMSs are less well equipped to do. For example, if you want to maintain a MIN or MAX query, it seems Oracle will do this quickly only for insert-only workloads; on retractions it re-evaluates the whole group. Materialize maintains a per-group aggregation tree, the sort of which previously led to a 10,000x throughput increase for TPCH Query 15 [0]. Generally, we'll build and maintain a few more indexes for you (automatically) burning a bit more memory but ensuring low latencies.

As far as I know, Timescale's materialized views are for join-free aggregates. Systems like Druid were join-free and are starting to introduce limited forms. KSQLdb has the same look and feel, but a. is only eventually consistent and b. round-trips everything through Kafka. Again, all AFAIK and could certainly change moment by moment.

Obviously we aren't allowed to benchmark against Oracle, but you can evaluate our stuff and let everyone know. So that's one difference.

[0]: [https://github.com/TimelyDataflow/differential- dataflow/tree...](https://github.com/TimelyDataflow/differential- dataflow/tree/master/tpchlike)

<comment><USER10> Materialize sounds like it has reinvented Michael Stonebraker's StreamSQL [1] and SAP's Continuous Computation Language (CCL) [2] which was created as part of a StreamSQL competitor named Coral8 and lives on in an enterprise product now named SAP HANA Smart Data Streaming. This space has gone by many names, Streaming SQL, Complex Event Processing (CEP), and Event Streaming.

I think the Continuous Computation Language (CCL) name captures the essence of these systems: data flows through the computation/query.

These systems have always had promise but none have found anything but niche adoption. The two most popular use cases seem to be ETL-like dataflows and OLAP style Window queries incrementally updated with streaming data (e.g. computations over stock tick data joined with multiple data sources).

[1] [https://en.wikipedia.org/wiki/StreamSQL](https://en.wikipedia.org/wiki/StreamSQL)

[2] [https://help.sap.com/doc/PRODUCTION/e1b391d2a3f3439fbab27ed8...](https://help.sap.com/doc/PRODUCTION/e1b391d2a3f3439fbab27ed882618873/2.0.00/en- US/streaming_ccl_reference.pdf)

<comment><USER9> The projects you've mentioned are attempts to address stream processing needs with a SQL-like language. That is fundamentally different from providing incremental view maintenance of _actual_ SQL using streaming techniques (what Materialize does).

If you want to maintain the results of a SQL query with a correlated subquery, StreamSQL in Aurora did not do that (full query decorrelation is relatively recent, afaiu). I have no idea what TIBCO's current implementation does.

If you want to maintain the results of a SQL query containing a WITH RECURSIVE fragment, you can do this in differential dataflow today (and in time, Materialize). I'm pretty sure you have no chance of doing this in StreamSQL or CCL or CQL or BEAM or ...

The important difference is that lots of people do actually want to maintain their SQL queries, and are not satisfied with "SQL inspired" languages that are insert-only (Aurora), or require windows on joins, or only cover the easy cases.

<comment><USER10> > The projects you've mentioned are attempts to address stream processing > needs with a SQL-like language. That is fundamentally different from > providing incremental view maintenance of actual SQL using streaming > techniques (what Materialize does).

With all due respect, CREATE SINK and CREATE SOURCE are SQL-like. I would argue that the pipeline created from the set of SINKs and SOURCEs is the key concept to grasp for developers new to your platform. The purity of the PostgreSQL CREATE MATERIALIZED VIEW syntax and other PG/SQL constructs seems like a minor selling point, in my (very narrowly informed) opinion. I hope I'm wrong.

Our difference of opinion involves marketing language and perceived differentiators. There are some important use cases for continuous SQL queries over Kafka-like data streams that remain unaddressed (as far as I know). I hope Materialize gains traction where others have failed to do so. If PG/SQL compatibility was the only thing holding back this style of solution then kudos to you and your team for recognizing it. Good luck (honestly).

</comment></comment></comment></comment></comment><comment><USER11> I'm working on Redis adapter for DynamoDB - Dynamo is really a distributed superset of Redis, and most of the data structures that Redis has scale effectively to the distributed hash table + B-Tree-like system that Dynamo offers. Having a well known and understood API like Redis is a boon for Dynamo, whose API is much more low level and esoteric.

The Go library is in beta, working on a server that's wire compatible with Redis.

[https://dbproject.red](https://dbproject.red)

[https://github.com/dbProjectRED/redimo.go](https://github.com/dbProjectRED/redimo.go)

<comment><USER12> Will you be able to support Redis-native replication from DynamoDB?

<comment><USER11> It would be super complicated, but technically feasible. DynamoDB has a change log called streams that would technically work, with a lot of aggregation, even with the distributed nature. But I would think about it only as a late stage and very expensive feature.

</comment></comment></comment><comment><USER13> I really wish one of the existing db technologies, Firebird, got a shot in the arm. It has both embedded and server modes which makes it unique as far as I know. Also the database is a single file which with firebirds "careful write" methodology remains consistent at all times so while you can make a backup at any time because it has MVCC, even a file copy of the database file with open transactions should not be corrupted. The installer size comes in under 10 MB. It's being actively improved, is open source with a very liberal licence but sadly it only gets a tiny fraction of the attention that SQLite, postgres etc receive

</comment><comment><USER14> My understanding of TileDB is that it is 100% client-side. There is no server. In a sense it's like handling orc or paraquet or even SQLite files on S3, (except tiledb are fancy r-trees) with a delta-lake-like manifest file for transactions too.

I think in the future there's going to be a sine-wave of smart-clients consuming S3 cleverly, and then smartness growing in the S3 interface so constraints and indices and things happen in the storage again, and back and forth...

<comment><USER15> This is a good description, except that TileDB (the open source client) is not transactional but eventually consistent at least for S3 and other object stores.

I like your point about consuming S3 cleverly, it's often difficult to get good out of the box performance from S3 so abstracting that to the degree possible is good for end-users. The cloud vendors though are always one or two steps ahead of companies that build upon their services. AWS Redshift for instance already can pre-index objects stored on S3 to accelerate queries at the storage layer. It's difficult as a third party vendor to compete with that.

<comment><AUTHOR> This is a very interesting development that I'd like to learn more about. Whenever I've played around with writing databases (just as toy projects) I've always done so using RocksDB or something similar as a backend. This "thick client" model, though, seems to have a lot of potential benefits, most notably no need to worry about disk space or volumes (so say goodbye to a bunch of config parameters) and no need for a tiered storage setup or S3 migration tools (already accomplished!). Not ideal for most use cases but intriguing for some!

<comment><USER15> There are a lot of issues though with S3, latency, poor performance for small reads / writes, timeouts, api rate limits, api costs, and consistency issues poorly understood by third party developers.

A "thick-client" also doesn't perform well unless that client is located on a node in the same region. I think as with everything it works well in some cases and not well in others.

</comment></comment></comment></comment><comment><USER16> I do wonder how databases like Datomic, and Crux are perceived (if at all) in the wider database community

<comment><USER17> I'm frankly shocked by how well these Clojure Datalog DBs work. Both the data- modelling side (datoms) and the query side are extremely expressive and well integrated into Clojure itself as well.

The principles are (from my perspective): How would a database (API) look like when both data changes over time and structural flexibility were first class concepts. The result is almost mindbogglingly simple.

Datalog is already such a powerful language in and of itself and I really wonder why it is still such a niche thing.

Don't get me wrong. SQL is great. It is there for a reason. And it is and should be "the default" for most use-cases. But Clojure Datalog DBs have a fairly clear and large advantage, especially when data is temporal and/or graph-like.

</comment></comment><comment><USER18> I support FoundationDB's approach to databases which is basically provide a consistent, distributed, and ordered Key-Value store then you can build whatever type of database you need on top of it whether that's RDBMS, Document, Graph, etc.

With that said, CouchDB 4.0 (on FDB) is going to be killer. Master-Master replication between clients and server with PouchDB is phenomenal when you remove the complicated eventual consistency on the server side.

And as a plug, I'm building a multi-tenant/multi-application database on top of it.

</comment><comment><USER19> I've found databases fascinating and tried various DB's as they come out.

I always find some issue or caveat or problem and I decide in the end that Postgres gets most of the way there anyway and I return to Postgres.

Whenever I get tempted by a shiny new database I remind myself "don't bet against Postgres".

<comment><USER20> +1000 Postgres. This is exactly why we chose to build TimescaleDB on top of PostgreSQL. Reliability, JSON, mature tooling, tons of connectors.

</comment></comment><comment><USER21> Software is advancing so fast. Interesting to constantly reconsider the things I consider myself ahead of the curve on vs behind the curve on. Prisma looks great so I've updated my I want functional dbs, not ORMs post: [https://github.com/ericbets/erics- designs/blob/master/funcdb...](https://github.com/ericbets/erics- designs/blob/master/funcdb.md)

<comment><USER22> From your blog post and the linked article:

> making a database look like an rpc api

I'd recommend checking out PostgREST for this (if you're using Postgres). We used this approach in my previous startup quite successfully.

We also have plans at Supabase[1] to make Postgres databases semi-ephemeral. You'll be able to spin them up/down using a restful API. The schemas/types will be accessible via a restful API: [https://supabase.github.io/pg- api/](https://supabase.github.io/pg-api/). Not quite as simple as SQLite, but a good alternative.

Databases are cool.

[1] [https://supabase.io](https://supabase.io)

</comment></comment><comment><USER23> > What I have yet to see but always secretly wanted, however, is a database > that natively supports incremental updates to materialized views. Yep, > that's right: Materialize listens for changes in the data sources that you > specify and updates your views as those sources change.

This is precisely one of the features that make ClickHouse shine

</comment><comment><USER24> Does anybody know of a good educational resource on software/best practices that is kept up to date. Ideally something that does not include the latest bleeding edge but things that are battle hardened or getting there. Something that includes open source and commercial software would be ideal.

</comment><comment><USER25> This is only tangentially related, but I rediscovered an old project of mine from years ago today and am rather excited about it:

[https://github.com/skorokithakis/goatfish](https://github.com/skorokithakis/goatfish)

It's basically a 200 line document database in Python that's backed by SQLite. I need to store a bunch of scraping data from a script but don't want a huge database or the hassle of making SQLite tables.

Goatfish is perfect because it stores free-form objects (JSON, basically), only it lets you index by arbitrary keys in them and get fast queries that way.

It's pretty simple, but a very nice compromise between the simplicity of in- memory dicts and the reliability of SQLite.

<comment><USER26> These days I'm guessing it's better to just use sqlites builtin json support and expression indexes, right?

<comment><USER25> Probably so, which means I should adapt Goatfish to work as a layer over that, since its API is much nicer than raw SQL.

</comment></comment></comment><comment><USER27> >What I'm really hoping for is the emergence of extremely "hackable," resolutely non-monolithic DBs that provide a plugin interface for highly use- case-specific data types,

Isn't this basically what FoundationDB is?

</comment><comment><USER28> Interesting notes but I feel like the db itself has been commoditised and the battle is elsewhere now. So anyone building a database engine today, will find out that to make it sustainable they also need an ecosystem on top of it, tooling, community, paid support, active devs, consultants (for which they may have no runway) Finally I find anything that calls itself a database and uses S3 as a backend a bit ridiculous. S3 has eventual consistency so you can't do the operations that differentiate a database from a file system.

</comment><comment><USER29> "What I have yet to see but always secretly wanted, however, is a database that natively supports incremental updates to materialized views"

SQL Server ala 10+ years ago enters the discussion.

<comment><USER30> I've actually used materialized views in production on SQL Server, and they're great when they work, but they have far too many limitations. Most of these make sense, but some of the join limitations are internal constraints of the engine, not a fundamental limit. This prevents their use for a wide range of scenarios where they would be useful...

</comment></comment><comment><USER31> > And it's worth noting that many have tried to do what Prisma does and failed > because they.

Because they what?

<comment><AUTHOR> Derp! Fixed that.

</comment></comment><comment><USER32> I miss rethinkdb. I loved their approach and their tooling.

<comment><AUTHOR> Yeah, very cool DB. I even considered doing a chapter on it in the next Seven Databases in Seven Weeks book but alas...

</comment></comment><comment><USER33> Mandatory mention: RavenDB. Probably the only LINQ native database with lots of performance optimizations squeezed in.

</comment><comment><USER34> I think that the graphql adapters like hasura and goke are also an important innovation, for small mvp projects you can create a graphql api to query your database directly from the frontend, this reduces the development time by a factor of 2 at least.

<comment><AUTHOR> Hmmm. I'm not finding Goke anywhere. Could you provide a link?

</comment></comment><comment><USER35> I'll just throw a note for a new product, AWS's QLDB. It's an internal managed product that combines a replicated, immutable, versioned document database with ACID transactions and an immutable, provable history of every modification. There's some streaming and subset SQL on the back end.

Something this focused should have a few applications where bit level auditability matters, eg financial, chain of events, etc. Of course it comes with some tradeoffs vs a relational or kv db.

I wonder if there would be room for a self-hosted clone?

</comment><comment><USER36> ClickHouse also supports incremental streaming from Kafka into a materialized view.

You can even detach and reattach the view from its backing table.

</comment><comment><USER37> What is the best source to create your own database, just for learning purposes ?

Great resources will be appreciated.

Thank you.

<comment><USER38> [https://github.com/danistefanovic/build-your-own-x#build- you...](https://github.com/danistefanovic/build-your-own-x#build-your-own- database)

</comment></comment><comment><USER39> Hi Luc,

What's your perspective on predictive databases like [https://aito.ai](https://aito.ai)?

I'm one of the Aito.ai founders. If you would like to hear more, I'm happy to talk one-to-one.

Regards, Antti

</comment><comment><USER40> I love these kinds of posts. They're targeted towards what people are finding interesting and they're highly tech related. It's a great way to find new technology.

</comment><comment><USER41> The website didn't load for me. So here it is: [https://web.archive.org/web/20200615193041/https://lucperkin...](https://web.archive.org/web/20200615193041/https://lucperkins.dev/blog/new- db-tech-1/)

Also, I'd like to add one database to the list (I work there for 3 weeks now): TriplyDB [0]. It is making linked data easier.

Linked data is useful for when people of different organizations want a shared schema.

In many commercial applications one wouldn't want this, as data is the valuable part of a company. However, scientific communities, certain government agencies and other organizations -- that I don't yet know about -- do want this.

I think the coolest application of linked data is how the bio- informatics/biology community utilizes it [1, 2]. The reason I found out at all is because one person at Triply works to see if a similar thing can be achieved with psychology. It might make conducting meta-studies a bit easier.

I read the HN discussions on linked data and agree with both the nay sayers (it's awkward and too idealistic [4]) and the yay sayers (it's awesome). The thing is:

1\. Linked data open, open as in open source, the URI [3] is baked into its design.

2\. While the 'API'/triple/RDF format can be awkward, _anyone_ can quite easily understand it. The cool thing is: this includes non-programmers.

3\. It's geared towards collaboration. In fact, when reading between the lines, I'd argue it's really good for collaboration between a big heterogeneous group of people.

Disclaimer: this is my own opinion, Triply does not know I'm posting this and I don't care ;-) I simply think it's an interesting way of thinking about data.

[0] triply.cc

[1] A friend of mine once modeled some biochemistry part of C. Elegans from linked data into petrinets: [https://www.researchgate.net/publication/263520722_Building_...](https://www.researchgate.net/publication/263520722_Building_Executable_Biological_Pathway_Models_Automatically_from_BioPAX)

[2] [https://www.google.com/search?client=safari&rls=en&q=linked+...](https://www.google.com/search?client=safari&rls=en&q=linked+data+and+biology&ie=UTF-8&oe=UTF-8) \-- I quickly vetted this search

[3] I still don't know the difference between a URI and URL.

[4] I think back in the day, linked data idealists would say that all data should be linked to interconnect all the knowledge. I'm more pragmatic and simply wonder: in which socio-technological context is linked data simply more useful than other formats? My current very tentative answer is those 3 points.

<comment><USER42> I recently had to deal with some RDF data expressed as N-triples. So, naturally I loaded it into a proper triplestore and embraced the whole W3C RDF universe and started teaching myself SPARQL, right? Nah, instead I just translated that shit into CSV and loaded it into Postgres, then post-processed it into a relational schema that I can actually understand and query with a language that other people at my company also know. The RDF was just a poorly specified way of communicating that schema to me, along with a data format that's no better than a 3-column CSV. Great stuff from the Semantic Web folks here, real powerful technology.

Edit: Also, to answer your question, the difference between a URL (Uniform Resource Locator) and a URI (Uniform Resource Identifier) is that the URL actually points to something, an object at a particular location, and you can paste it into your web browser to view that something. A URI just uses a URL- like scheme to represent identifiers, such that your domain and directory structure provide a kind of namespace that you control. But as long as it follows the format, your URI can contain literally anything, it doesn't have to be human-readable or resolve to anything in a web browser. It might as well be mycompany_1231241542345.

<comment><USER43> > ...I just translated that shit into CSV and loaded it into Postgres, then > post-processed it into a relational schema that I can actually understand > and query with a language that other people at my company also know. The RDF > was just a poorly specified way of communicating that schema to me, along > with a data format that's no better than a 3-column CSV. Great stuff from > the Semantic Web folks here, real powerful technology.

I'm not sure what's the point you're trying to make, that _is_ exactly what RDF is for! It's not an implementation technology, it's purely an interchange format. You should _not_ be using a fully-general triple store, unless you really have no idea what the RDF you work with is going to look like.

SPARQL is the same deal; it's good for exposing queryable endpoints to the outside world, but if your queries are going to a well-defined relational database with a fixed schema and the like, you should just translate the SPARQL to SQL queries and execute those.

<comment><USER42> Well I'm glad to hear that my solution was sane, but I just don't see what technological innovation was contributed by the RDF. The file was canonical N-triples, AKA a CSV with space instead of comma. The predicates establish relationships between subjects and objects, but those relationships could be one to one, one to many, or many to many. Should a given predicate be modeled relationally as a column, or with some kind of join table? I have no idea from the RDF. Say, those objects, are the types I see attached to the values the only types that could possibly appear for that predicate? Who knows! Sure, the data has been interchanged, but the "format" is so generic that it's useless. Why not just give me a 3-column CSV and tell me to figure it out on my own, rather than pretend that RDF provided some improvement?

<comment><USER41> Thanks for your comment on it by the way. I'm still in the phase of gathering what everyone thinks of it. I've noticed that RDF seems a bit polarizing. I have the suspicion that people who feel neutral about it also don't feel the need to chime in.

</comment></comment></comment></comment></comment><comment><USER44> How does tiledb compares to something similar like milvus

<comment><AUTHOR> I haven't come across Milvus but I'll check it out!

</comment></comment><comment><USER45> whatever became of rethinkDB -- i think it was just too far ahead of its time it; had some really interesting ideas

</comment><comment><USER46> Is tiledb useful for storing ML models?

<comment><USER47> You can certainly store ML models in TileDB. I've been working on an example notebook showing how to store an opencv model in TileDB, its not quite finished yet but will be published soon.

Using python as an example language, TileDB-Py offers simple functions, like "from_numpy" [1] for basic and simple models which we can write directly. For more advanced (and more common) use cases of complex models, its easy to create an array to store the model and all associated metadata. TileDB's array metadata and time travel capabilities allow for you to even see how your model changes over time as you update it.

[1] [https://github.com/TileDB-Inc/TileDB- Py/blob/bcaee16b194675f...](https://github.com/TileDB-Inc/TileDB- Py/blob/bcaee16b194675f10235669fcb615928c0af964d/tiledb/libtiledb.pyx#L3974)

Disclosure: I'm a member of the TileDB team.

<comment><USER46> Really cool, thanks for the reply.

</comment></comment></comment><comment><AUTHOR> REMOVED: I complained about the rewritten title in a way that was excessively harsh and have removed that comment.

<comment><USER48> The article title was linkbait: "you" and "should" are linkbait tropes, especially when combined. The site guidelines call for rewriting such titles. See [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).

When we change titles, we always try to use representative language from the article. I replaced it with a phrase from the article where it says what it's about in a neutral way. I added a hyphen to "recently minted" because it seems to me that grammar requires it. However, if we worship different grammar gods I am happy to let yours hold sway. The hyphen is now toast.

This is bog-standard HN moderation. I dare say the reason you "really really hate it" is probably because you notice the cases you dislike and weight them much more heavily: [https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20notice%20dislike&sort=byDate&type=comment). Meanwhile the ones you don't find objectionable pass over relatively unnoticed. That is bog-standard HN perception bias.

If we didn't meticulously try to keep titles linkbait-free and less-misleading (more hyphens, sorry!), HN's front page would be completely different, and since the front page is the most important thing here, the entire forum would soon be completely different. That requires editing titles all the time. petercooper, who posted elsewhere in this thread, has an HN title-change tracker (oops, I hyphened again!) which is quite nifty. It doesn't show all of them, though, and it can't tell the difference between moderator edits and submitter edits.

There is a power shortage in my neighborhood and my laptop battery is about to expire, so if you don't see a link momentarily, or if I don't respond anywhere on the site for a few hours, it's because shelter-in-place (uh-oh!) prevents me from finding somewhere else to plug in.

Edit: here it is: [https://news.ycombinator.com/item?id=21617016](https://news.ycombinator.com/item?id=21617016). Note how we edited out the bloody pig mask.

<comment><AUTHOR> I apologize for the strength of my language. There are several words I used in that comment that I should not have. It's far too easy to forget in the moment that there are real people making these decisions who may very well read what you say. I understand where you're coming from with the decision and will try to select more appropriate titles in the future. And will be much more mindful about how I register complaints.

<comment><USER48> Aw, thanks. I should have been nicer too. I was making myself chuckle while I wrote some of that, which is one way to mitigate the tedium of writing similar things over and over, but I fear that it comes across as a bit mean sometimes. By the way: nice article!

Battery is at 2%...

<comment><USER49> I hope you're doing alright with the shelter-in-place. Losing power sucks.

If it goes on too long, and someone has a car nearby, you can use that as a power source. (Be sure to keep the engine running though, otherwise you'll end up with two objects that need a power source...)

<comment><USER48> Considering that HN didn't fall apart while I was offline, it was a guilt-free blessing.

I mean, I still had my phone. But moderating HN with a phone is like trying to do surgery with only your thumbs, through a two-inch hole. In the dark.

<comment><USER49> I was always super curious what your browser extension for modding HN is like. If there's such a huge difference between phone vs laptop, it sounds like the extension is doing much of the work. It's a neat power tool.</comment></comment></comment></comment></comment></comment></comment>


Nathan Myhrvold PR piece - <AUTHOR> http://www.wired.com/magazine/2011/02/ff_myhrvold/all/1

<comment><USER2> From the article: "But he's primarily a scientist. Myhrvold has a master's degree in geophysics and space physics and another one in mathematical economics. He got his PhD in theoretical and mathematical physics from Princeton at 23 and did a postdoctoral fellowship with Stephen Hawking at Cambridge. He started a software company that Microsoft bought in 1986, founded Microsoft Research in 1991, and left the company as its CTO and chief strategist in 1999. He has hundreds of patents issued or pending. Oh, and he's also a photographer, a patron of paleontology research, and a world-champion barbecue chef. Seriously."

And he's also the worlds biggest patent troll.

Seriously.</comment>


Show HN: ProsperStack – Use Stripe to automatically prevent cancellations - <AUTHOR> https://prosperstack.com/ <comment><AUTHOR> Hi HN,

My co-founders and I created ProsperStack after working at a SaaS company and realizing how little we knew about why our customers were leaving. We wanted an easy way to collect data and prevent cancellations by incentivizing customers to stay, and realized that hooking into Stripe to automate the process would be super valuable.

The app can automatically present offers to a customer before they cancel using Stripe coupons, collect feedback from cancellations, and use your Stripe data to show meaningful churn metrics.

Thanks so much for checking it out and any feedback you might have!

<comment><USER2> As a customer i would LOVE to exploit this if it gets popular

<comment><AUTHOR> Hah, we've definitely thought about that possibility. Fortunately we do have a few things in place to prevent the most obvious abuse cases, but we need to get popular first!

<comment><USER3> Ha! What would be the counter measures?

I am thinking someone on Reddit posting a trick to save money on your sub.

<comment><AUTHOR> Right now it's fairly basic: we recommend you offer a limited discount (for example, 30% off for three months) and by default a customer can only accept one offer for their lifetime. That would at least minimize most of the risk.

On the roadmap are plans to target offers based on segmented customer data (lifetime value, etc.) so even if you did try to follow a trick posted on Reddit, it might not work for you!

</comment></comment></comment></comment></comment><comment><USER4> How does a flat $79/mo price make sense? Many small companies that could use this don't have that much worth of cancellations in a month assuming something like this will save them all. Medium-small and larger companies could justify paying much more than that. You need to have some kind of flexibility here. I'm thinking if you don't have more than $500 in monthly cancellations you would never be able to break even on something like this.

<comment><AUTHOR> Honestly, it probably doesn't make sense long term! We wanted to get the product out the door with simple pricing to see how it works and adjust from there.

We're mostly worried about the sales cycle being too long with performance- based or scaling pricing, since none of the founders are trained salespeople. I'm realizing we're probably going to have to adjust that mindset and learn how to sell.

</comment></comment><comment><USER5> Congratulations on your launch, and best of luck to you, but...

As a customer, I don't want to be "saved". Treat me right in the first place and I will remain loyal. Otherwise, let's part ways amicably without you wasting more of my time.

<comment><USER6> As a customer, I can imagine unsubscribing because some service was quite good, but not worth the full price for me. Maybe this service is still figuring out its pricing model. If they, for example, give me cheaper price and then keep it, I do not mind being "saved". Not sure how often this scenario will be considered though.

</comment></comment><comment><USER7> Congrats on launching. Very interesting. Does it support localization / customizing the look&feel? I couldn't work out if it's something that runs directly on our site, or we need to redirect to yours... I think some more documentation/info before you sign up for a trial can help give better confidence about what's involved and how it actually works (although the homepage is awesome and explains the value proposition super well).

Like others, I'm a bit on the fence about the ethical aspects of it. Yes, there's a lot to say about giving real value, listening to customers, but it does start going down the path towards darker patterns like Amazon Prime (there's a looong way to go down that path, but still feels like a step there). I'm not trying to criticize, but just voice my personal feeling around adding friction to cancellation.

<comment><AUTHOR> The customization is limited right now (you can add your company logo, and customize the text for offers), since our initial focus was on getting the design and UX right. Localization and/or complete customization of the look and feel is definitely on the roadmap.

We'll get to work on adding some more documentation for sure, but the short answer is that it's a JavaScript widget that runs everything for you on your site. You can check out the technical docs on the NPM package here: [https://www.npmjs.com/package/@prosperstack/flow](https://www.npmjs.com/package/@prosperstack/flow)

Thanks so much for the honest feedback. I definitely agree about steering away from dark patterns and adding friction to cancellation. We want the cancellation process to be super easy, and hope to try achieve a balance that actually benefits customers instead of trying to trap them into not leaving.

</comment></comment><comment><USER8> Interesting product! Have had to implement this before and certainly would check it out next time.

Have you thought about pricing based on performance?

At the low end, it could be "pays for itself": A monthly fee of max($79, mrr_preserved_that_month). When the fee cancels out the preserved mrr, the customer still gets data features of the product for free. Thinking mostly of the indiehacker crowd here.

At the high end, I suppose you could flex up to something like a percentage of mrr recovered with a cap.

(Always find subscription pricing economics interesting, especially to learn how others do it.)

<comment><AUTHOR> Yeah, we've definitely discussed a pricing strategy like that. For now, we're just trying to keep it super simple until we get more data on how people are using it.

I know that virtually no startup gets pricing correct right out of the gate, so I'm sure we'll be tweaking it!

</comment></comment><comment><USER9> Most of the subscription based saas products make easy money on inactive users who are okay losing money for prospect on using the tool in near future.

Even though that is easy money, saas companies should offer "inactive account maintenance" fees rather than full subscription fees, when the user starts using it, they could charge them full. This is win-win situation where user gets to keep the account for smaller fees and companies can retain more customers.

ProsperStack like tools can offer these by default.

<comment><AUTHOR> This is exactly what one of our first customers is using ProsperStack for. They use it to offer an "on hold" option to maintain the account data in read- only mode at a lower price.

</comment></comment><comment><USER10> Just let people cancel imo.

<comment><USER11> I don't disagree, but I don't see any harm in asking questions as to why they cancelled.

Sometimes all people want is a discount, and as a business losing $20 a month is better than losing a customer.

<comment><USER12> > ... and as a business losing $20 a month is better than losing a customer.

This is some serious MBA-speak right here. Losing $20 a month is worse than losing a customer. The only time there's a difference is when you're looking to capture enough market in an unsustainable way so that you can paint a good picture for someone dumb enough to acquire you to try to shut down competition.

If you're well-capitalized, then this is just a straightforward monopolization tactic; if you're not well-funded, this is just gaming the numbers so that a well-capitalized monopolist can come in and use you to play the same game.

If you're a company that is trying to be successful and make money, then you're better off using this as a signal about your pricing.

<comment><USER13> > This is some serious MBA-speak right here. Losing $20 a month is worse than > losing a customer.

I don't think the GP meant the classic "lose money on each sale but make it up on volume" nonsense, but rather "it is better to forgo $20 of your margin than to lose a customer".

<comment><USER12> I think your read is more accurate than mine. To be honest, the article gave me a bit of indigestion because these sorts of discounting antics always sit poorly with me. I don't have the time or energy to haggle over pricing; and it really bothers me when squeaky wheels get all the grease.

</comment></comment></comment></comment></comment><comment><USER14> Coming from a SaaS background on the product design and development side of things, I think churn is something many companies have given up on successfully remedying within the product, or have sourced to other departments in the company to help solve the issue. While user interaction with Customer Success or Support is definitely necessary in many circumstances, from my perspective, this could help battle churn for a myriad of reasons which can be addressed and designed for a specific product or with a specific user type in mind without being too abrasive or causing major headaches for the user. Cool idea. Good luck!

</comment><comment><USER15> Ive definitely noticed that one of the biggest inhibitors of growth in SaaS companies I've worked with is just letting high amounts of unnecessary churn happen, or throwing way too many resources at the problem only to reduce it by a small among. Giving your customers the tools to prevent themselves from churning seems like no-brainer and a very strong way to combatting that.

<comment><AUTHOR> Yeah, that's exactly what we were seeing. Retention with customer success programs is helpful, but many small companies just don't have the resources for it. We're hoping to provide something that can make an impactful dent on churn in an almost entirely automated way.

</comment></comment><comment><USER16> This is a good idea. It seems like it would help eliminate a lot of the inherent guesswork in feature forecasting (as I've experienced it). "We have lost x amount in annual recurring revenue due to the absence of feature y..." It could also provide valuable insight into how well your product is serving different markets.

</comment><comment><USER17> Love the idea. Churn reduction is one of those unsexy parts of the funnel (much like cart abandonment) that has a huge ROI but is traditionally neglected because it's not as visible as top of funnel work. Of course, it's all part of the same flywheel, which is why tools like this are so valuable.

</comment><comment><USER18> Great launch! This looks similar to www.raaft.io which has been around for a couple of years and supports Recurly in addition to Stripe. How do you differentiate?

I think we would have used something like this (instead of rolling our own) if it integrated with Chargify.

<comment><AUTHOR> Thanks! I think the main differentiator is our deep integration with your Stripe data. The cancellation flow is obviously an important part of the equation, but ProsperStack can also give you insights into past cancellations, with the goal of being able to win back subscribers from before you integrated the flow into your app. We also want to make churn analytics a core part of the value prop.

We'd love to integrate with more payment providers, and Chargify is definitely on the list. If you'd be interested in helping us get a Chargify integration going, I'd love if you'd send me an email (address in profile)!

<comment><USER19> Could you help us understand a few things about your service? How deep is this "deep integration"? When we sign up with you, what are we agreeing to hand over and/or to give you access to? Do you make copies of this data? Do you sell data about our Stripe data to others? Are you training your ML models based on our data? Do you have measures in place to detect or prevent internal leaks of such data and external exfiltration (via security attacks, for e.g.) of such data?

<comment><AUTHOR> We request read/write access to Stripe via Stripe Connect in order to receive webhooks on your behalf and to create coupons. We do copy a small amount of data (customer and subscription details for cancellations) for the reporting and metrics features.

We do not and never will sell your Stripe data. We're not using any ML, so we're not training any models on your data.

We understand having access to your Stripe account comes with a lot of responsibility, and we're taking that seriously. I'd be more than happy to discuss security if you want to shoot me an email (address in profile).

</comment></comment></comment></comment><comment><USER20> Are you eating your own dogfood?

If I sign up for a month then quit, what will it then cost me?

<comment><AUTHOR> We are dogfooding the cancellation flow, of course. We don't have any offers active since we kind of assumed people would know to look for them. :)</comment></comment>


Why I like Java  - <AUTHOR> http://blog.plover.com/2014/02/01/

<comment> chris-martin "write a program that copies standard input to standard output":

org.apache.commons.io.IOUtils.copyLarge(System.in, System.out);

I despise the Java language as much as the next dev, and the core library is drastically underfeatured - But if you can't manage to copy one stream to another because you don't use libraries, you have no one to blame but yourself.

<comment><USER2> > I despise the Java language as much as the next dev

It's not so much the language that I despise - I never touched the language because of the end-user experience I got from installing the runtime: the nagging updates and the constant security headlines involving JVM. _That 's_ why I will never take the language (or the JVM languages) seriously: I simply would never put my users through what I am somewhat forced to go through (for the select few Java apps I do have to use).

<comment><USER3> And the prize for least informed opinion goes to...

Let's review : 1) "I never touched the language" 2) Almost without exception Java vulnerabilities are related the the applet sandbox and not the core JVM

Also, find me a single engineer how understands how the JVM works, what it does, how it does it and how it compares to alternatives that also thinks it's sub par software. I'll wait.

</comment></comment></comment><comment><USER4> > So yes, I enjoyed programming in Java, and being relieved of the > responsibility for producing a quality product. It was pleasant to not have > to worry about whether I was doing a good job, or whether I might be writing > something hard to understand or to maintain. The code was ridiculously > verbose, of course, but that was not my fault. It was all out of my hands.

Yes, that's it, blame the language when you write poor quality software. If only I'd used language X instead of language Y, my code would've been easy to read, well-architected and thoroughly tested.

...and if language X in this instance is supposed to be Perl.... come on. It has built-in functions that change behaviour depending on whether or not you're assigning them to something.

<comment><USER5> > built-in functions that change behaviour depending on whether or not you're > assigning them to something.

Are you suggesting that's a bad thing?

If so, consider this code:

        a[2] = a[2]

(where a is an "array", [n] an "array index", = "assignment")

The behavior of the code 'a[2]' changes entirely depending on whether it's on the LHS or the RHS. Languages and their compilers can easily support this, without a notable downside (short of religious arguments) and most ordinary folk consider it a good thing that it writes to the array when on the left, and reads from the array when on the right.

The same argument applies to functions used in a similar fashion (and, in P6, code such as a[1] etc. is in fact a function call).

<comment><USER4> > Are you suggesting that's a bad thing?

Yes. Your example doesn't apply. In both instances a[2] is a reference to a position in an array.

I was referring specifically to context-aware functions in Perl, for example, keys called in a list context returns the keys, in a scalar context, the number of keys, in a void context, it resets an internal iterator.

This is terrible, it's like Perl decided that the principle of least surprise was too boring.

<comment><USER6> It's only a surprise if you don't understand it. Every Perl programmer needs to fully grok and embrace it because it's a core language feature.

For others, this is what _EdwardDiego_ is referring to:

      my %hash = (a => 1, b => 2, c => 3, d => 4);

      # list context (plural)
      my @keys = keys %hash;
      my ($key1, $key2, @rest_of_keys) = keys %hash;

      # scalar context (singular)
      my $number_of_keys = keys %hash;
      say scalar keys %hash;

      # An example of iterator usage
      my ($first_key, $first_value) = each %hash;
      my ($second_key, $second_value) = each %hash;

      # void context
      keys %hash;    # resets iterator

</comment></comment></comment></comment><comment><USER7> What an utter load of crap. You can write excellent code in Java, you can write crap in Java. Due to its popularity, java has had everyone and their dog learning how to "code in java" and hence there are many poor "Java developers". That doesn't make it a bad language.

I quite like Java too, but without the mealy-mouthed backhanded compliments.</comment>


I *heart* Technical Debt - <AUTHOR> http://baberuth.posterous.com/i-heart-technical-debt

<comment><USER2> Wow, I can't imagine the nightmares that this guy has left others to deal with in the future.

Yes, a startup needs a 'get it DONE' attitude, but that HAS to be tempered with doing things in a maintainable way, and not just duct-taping it together. If you don't, you're forcing a complete rewrite of the entire system, and that is a really dangerous thing to do.

So let's give some better advice for startup programmers:

1) Get it done. Just hack out that code and make it work.

2) Write some tests for the poor thing. If you -can't-, you'll need to do step 3 first and then come back.

3) Refactor/Rewrite that horrid, horrid code you wrote in step 1. Make it readable, first of all. Then make it intelligible. Then make it pretty.

If you work at that company in the future, you'll thank yourself. If you don't, the owners and your predecessors will thank you.

And best of all: Writing good code is a habit. Once you get into the habit, it will horrify you if you ever have to stop, even temporarily.

<comment><USER3> And often step 1 is a valuable learning experience, as well, both long-term and also for the immediate needs of the project at hand.

But, sadly for the OP, the very name "debt" clearly indicates there is no escaping step 3.

<comment><USER2> Actually, no I don't think it does indicate that. He's saying that he loves technical debt because it means things get written fast and furious, and he can just leave the technical debt to someone else. If he hated the debt, he'd take care of it.

</comment></comment></comment><comment><USER4> The number of times I got hired to pick up after you because your technical debt technically bankrupted the company and you got fired. My only hope is that innocent new coders reading your piece will not feel "inspired" by your little bracelet waving, but instead learn how to get good at her craft. That's the real reason it takes you 5 days of "procrastination". What you need is not to "just get it done", is to learn and gain experience before you tackle something out of your league, so that you don't leave other people picking up the pieces. Please.

</comment><comment><USER5> The point of Technical Debt isn't procrastinating about perfection - the point is when you get into a situation where you've dug yourself in so far that you end up screwed.

For example, I consider the entirety of the Virtualization industry to be primarily caused by technical debt surrounding legacy Windows programs. Simpler to convert an old physical server into a VM than to redo the application.

The fact that you actually have the code and can change the codebase = you're far from incurring any insurmountable technical debt.</comment>


Google thinks Emacs is pure spam - <AUTHOR>

I've heard all these stories about Google smashing websites with some penalties for nothing but I never though it is serious.
I really though the penalties are reserved for spammers, scams and generated garbage content.
Imagine my surprise when I find an email in my inbox saying my humble blog with a single post about Emacs autosave configuration is "having pure spam" and the
manual action has been applied to the entire website.
http://i.imgur.com/GCUDlzp.jpg
How do you deal with it?
What next? Just simply having a domain will be considered spamming by big G? <comment><USER2> It sounds like some algorithm messed up. It happens. Nobody and nothing is perfect. I imagine you generally appreciate the results of that very same algorithm (a spam filtered experience) as you search the web.

File the reconsideration request. If that doesn't work, THEN you've got something to complain about.

</comment><comment><USER3> Google is the web's policeman, judge, jury and executioner. You have no right of appeal. Kafka would be proud....

#DontBeEvil

</comment><comment><USER4> This looks like a new site. Did you just recently develop this domain? Any chance it was used for spam in the past? If that's the case, then just file for reconsideration and let Google know that you are the new owner and they'll lift the manual action.

Otherwise, file for reconsideration and explain your plans for developing the domain and you should be fine.

I do admit that it's a bit strange for a brand new site with one post to be given a pure spam penalty...unless, again, the domain was previously used for spam.

</comment><comment><USER5> Use [http://duckduckgo.com](http://duckduckgo.com)</comment>


Rohrabacher confirms he offered Trump pardon to Assange - <AUTHOR> https://news.yahoo.com/rohrabacher-confirms-he-offered-trump-pardon-to-assange-for-proof-russia-didnt-hack-dnc-email-131438007.html <comment><USER2> Title is misleading.

In the article, Rohrabacher says "I spoke to Julian Assange and told him if he would provide evidence about who gave WikiLeaks the emails I would petition the president to give him a pardon."

Petition is quite different than offering.

<comment><USER3> Didn't Assange already make claims that that data trove did not come from Russia?

<comment><USER4> Repeatedly.

<comment><USER5> You are correct, but just to clarify he specifically stated it did not come from the Russian government, not that the source was not from Russia (I'm not implying that, just clarifying).

</comment></comment></comment></comment><comment><USER6> is it legal to offer presidential pardons on condition of the person doing something unrelated to the offence?

<comment><USER7> There's very few constitutional limits on the power to pardon. I suspect abusive use of the power would fall under the scope of impeachment, but we'd be unlikely to ever see that play out.

Pardons are also interesting because they have to be affirmatively accepted, and they have to be for an actual crime that was committed — so there is endless debate about whether accepting a pardon is an admission of guilt.

<comment><USER8> Your last paragraph has absolutely no basis in US law at least.</comment></comment></comment>


Tank Kee's Library: The adventures of a Chinese imperial encyclopedia - <AUTHOR> https://www.laphamsquarterly.org/roundtable/tank-kees-library <comment><USER2> Down.</comment>


Vagga is a containerization tool without daemons - <AUTHOR> https://github.com/tailhook/vagga <comment><USER2> I don't understand this point:

      - Fully userspace containers, no need for elevated privileges

The most basic Linux container is constructed with chroot and namespaces, both of which require root privileges (or at least CAP_SYS_CHROOT and CAP_SYS_ADMIN respectively). Additionally managing layers with a union filesystem, unless utilising FUSE, will also require elevated privileges.

<comment><USER2> A more extensive look at the code, it requires the host root user to set `kernel.unprivileged_userns_clone=1` after which Vagga can perform privileged operations as a "root" user inside a user namespace.

<comment><USER3> Yes. But that's on debian (IIRC) kernel, i.e. the patched one. On stock kernel it requires CONFIG_USER_NS setting enabled, and it just works.

</comment></comment></comment><comment><USER4> Excellent avoidance of elevated privileges with CONFIG_USER_NS and it's easy to deploy. Great stuff!

</comment><comment><USER5> I just had a brief look at the tutorial, but it looks great! Kudos to the author!

</comment><comment><USER6> ..and it's implemented in Rust, w00t!

<comment><USER4> I wonder where they get their Rust musl static releases from? As you cannot bootstrap 1.7 with 1.6 you always need to use the officially tagged nightly snapshot for the particular release when building rust, which happens to be for glibc. So it's a pita to build and use rust with musl, unless it's part of the official release channels already.

<comment><USER3> vagga is built by vagga itself, so you can look at how to make musl rust here: [https://github.com/tailhook/vagga/blob/master/vagga.yaml#L23...](https://github.com/tailhook/vagga/blob/master/vagga.yaml#L23-L56)

There is already a musl libc distributed with rust since 1.5: [http://static.rust-lang.org/dist/index.html](http://static.rust- lang.org/dist/index.html) [http://static.rust-lang.org/dist/rust- std-1.6.0-x86_64-unkno...](http://static.rust-lang.org/dist/rust- std-1.6.0-x86_64-unknown-linux-musl.tar.gz)

But we had not used it yet.

</comment></comment></comment><comment><USER7> Hey look , jails on Linux .</comment>


With 'Downsized' DNA, Flowering Plants Took Over the World - <AUTHOR> https://www.quantamagazine.org/with-downsized-dna-flowering-plants-took-over-the-world-20180111/ <comment><USER2> Imagine a species with a version controll system in there DNA. What epigenetic wonders it would allow for - to revert forward, backward- or fast forward to a diffrent branch.

<comment><USER3> We sort of have that, though it's like the age of development before revision control. Old versions of code are still lying around and are sometime activated via epigenetic triggers if they can be found.

This is why I was so annoyed when "the" genome was first sequenced: they saved time by disregarding the "junk dna" — cargo cultism at its finest!

This mechanism isn't terrible btw — your environment is likely to be quite similar to recent environments; how often do you really go back and extract a git revision from a year ago?

Also humans have an additional more powerful mechanism, memes, to supplement genes.</comment></comment>


The Apple-Intel-Samsung Ménage à Trois - <AUTHOR> http://www.mondaynote.com/2012/05/13/the-apple-intel-samsung-menage-a-trois <comment><USER2> This article is missing a couple of facts:

First, Apple has been designing its own "Ax" series of ARM chips with its purchase of PA Semi, currently with the A5/A5X. If Apple switched to an Intel chip, they would no longer have the flexibility of a custom design or marketing claim to a custom chip in their product.

Second, though Apple contracts with Samsung to fabricate their ARM chips, they could presumably go to other companies to do the same thing. There have been rumors of a future partnership with TSMC. If Apple switched iOS to Intel's architecture, Apple would have much less flexibility with fabrication.

Third, switching CPU architectures means that your old software doesn't work immediately (we used to say "out of the box"). When Apple previously switched CPU architectures on the Mac, they had an emulator to allow running old apps, but this has a huge performance penalty that wouldn't fly on iOS: apps wouldn't be silky smooth on the latest product. The situation here is a bit different than with the Mac because developers sell directly through the App Store, but Apple would have to take a temporary hit to their huge app selection while developers recompile their apps, and some developers may not have the resources to do so (because the work was done via contract, for example). Perhaps static recompilation to retarget the architecture could be done by Apple for each app, but reading the EFF's copy of the iPhone Developer Program License Agreement, I don't see where Apple granted themselves the right to do this (correct me if I'm wrong).

To me, it makes more sense that Apple would want Intel to manufacture Ax ARM chips for them. But given that Intel has shown huge resistance to ARM (probably due to the lack of manufacturer lock-in), it's unlikely that they would partner with Apple to do this. The key advantage for Apple would be the use of Intel's cutting edge fabs, which would make their ARM chips the undisputed champions.</comment>


What does "expressiveness" via LOC per commit measure in practice? - <AUTHOR> http://redmonk.com/dberkholz/2013/03/26/what-does-expressiveness-via-loc-per-commit-measure-in-practice/

<comment><USER2> Good article, but I'm even more skeptical of using LOC as a measure of expressiveness (whatever that means). I think expressiveness has more to do with how "native" a language feels to you. Just like a hispanic might think in Spanish, I think in English, and we are each more expressive in our home language. I would probably butcher Scala code, but a Python guy would butcher C#. I also think this metric ignores boilerplate code. In C#, I make a new class and it pre-fills a ton of boilerplate. One could debate that this is "expressive", but it's something that a native speaker doesn't even notice; our eyes ignore the framework and go straight to what matters. Same for long function prototypes and object types. We're not typing every line of code; most of them are typed for us.

It also ignores coding standard guidelines that many people follow, including hungarian notation, or expressive variable names, which can make lines of code get split up even though the naming conventions themselves might be considered more understandable because of it. Established languages are more likely to follow this pattern than the arcane notation used by most modern functional languages.

In the end, languages to the "more LOC" side of the list feel more native to me than those on the "less LOC" side of the list, and so I feel I'm more expressive in them, despite the statistic. I think LOC is not a useful measurement for anything, really, except for linkbait.</comment>


Persuasion Triggers in Web Design - <AUTHOR> http://www.smashingmagazine.com/2010/11/29/persuasion-triggers-in-web-design/ <comment><USER2> Uh?? I thought they gave you a sample chapter so that you can see if the book interests you, not so that you'll feel obliged to buy the whole book to return this "favor".</comment>


Words in Other Languages with No Direct English Equivalent - <AUTHOR> http://twistedsifter.com/2014/05/words-with-no-direct-english-equivalent/ <comment><USER2> Ha ha! Most amusing!

But what about the other way around? That is, words in english with no direct foreign language equivalent. That, too, would be of some psycho-linguistic interest.

Also, what about words or categories of words missing in English and all other languages? For instance, there's no single english word for "the person who names artificial flavors". Which engineer or marketeer designated that weird artificial candy flavor as "watermelon"? It bears only the faintest of semblance to watermelon-the-fruit. So, who decided, what do we call that job? I presume Yupik, Inuit, Japanese, Maori, German, Spanish and Mahashtri don't have that word, but it would take a far smarter person than me to be sure.

</comment><comment><USER3> I should know this word:

      Tsundoku (Japanese)
      The act of leaving a book unread after buying it. Typically
      piling it up together with other such unread books.

Oh that's never happened to me before... And I would have know this word if I had only read the book I bought on learning Japanese.

BTW, excellent artwork.</comment>