ryeguy

This doesn't answer the question being asked.

How do RFCs and ADRs play together? Would you consider a finalized RFC (all comments/concerns addressed in some way) to be an ADR?

It's pretty well established that calories alone, not macronutrient composition, are what is responsible for weight loss: https://examine.com/nutrition/what-should-you-eat-for-weight.... There are plenty of studies comparing low-carb diets to not and no difference in weight loss was found when controlling for calories.

> This is a straw man, because the point that is trying to be refused is that "insulin is bad", not "carbs are bad".

I don't see how this is a strawman. Click through to the source article, that bullet point in particular is refuting the common belief that carbs alone are what spike insulin. Most insulin-centric discussion on fitness forums (which is where this was posted) tends to mention insulin spikes in the context of high-GI carbs.

> Also of concern is impinging on the glucagon cycle, and in the linked-to post there is no mention of the important function of glucagon, which is typically considered as having effects opposite to insulin.

Read the linked "part 1". It specifically mentions that newer research shows that glucagon does not counteract insulin as previously thought, and links some studies.

> The article makes a point about how "Insulin is not needed for fat storage", but omits the fact that in reality, practically all fat storage is mediated by insulin and its effects on glucose.

That isn't really relevant to the core point, which is debunking the idea that insulin is what makes us fat.

I just want to restate the fact that the above reddit post is a summary of articles, which themselves are a summary of studies. It is targeted at fitness people who are discussing insulin only in the context of weight loss. There is of course an oversimplification here due to omitting details the target audience might not need as well as being 2 steps removed from the source material.

Calorie count _is_ the key. This is incredibly well established in studies. Weight loss does not occur without caloric deficit, no matter what you eat. Likewise, weight loss will occur in caloric deficit even when eating what people would consider "junk", including sugar. See The Twinkie Diet, for example: http://www.cnn.com/2010/HEALTH/11/08/twinkie.diet.professor/...

Avoiding food because "we didn't evolve to eat" is not sound science, either.

Insulin does not lead to increased weight gain. If this approach does work, it's because it's a roundabout way of eating lower calorie foods and thus lowering daily caloric intake.

Yes really. Keto still follows calories in/out. Low carb diets are just a way of restricting calories without counting them. People naturally restrict calories when eating low carb -- this is the sole reason it works. You can eat twinkies and mcdonalds and still lose weight if you eat little enough. You can eat no carbs or sugar and still gain weight if you eat more calories than your body needs.

Every diet that doesn't involve directly counting calories tricks you into restricting them in some way, putting you in a caloric deficit. Period. This is how every diet works.

Insulin is not required for fat storage. Insulin spikes do not create energy out of nowhere and don't suddenly make the same number of input calories multiply. Also, insulin spikes are nearly unpredictable anyway. Carbs aren't necessarily the trigger, protein and fat can be too. Sometimes foods are synergistic and spike insulin together more than eaten separately. Insulin spikiness is also determined by food in your stomach, further complicating things. For example, having fiber with a meal can "smooth out" an insulin spike.

I summarized some articles that dispel insulin voodoo here, if you're interested: https://www.reddit.com/r/Fitness/comments/j853z/insulin_an_u...

Nothing is wrong with this picture. Your thought process boils down to "OP should be making enough money at their day job, why would they try to make more?" which is ridiculous.

I agree you should do this from the user's perspective, but what about when a message handler (which is already async and not blocking the user) needs to call into an api? You could rewrite it to use queues for the request and response, but then you're convoluting control flow.

Why not use spot fleets to solve this? You can specify multiple acceptable instance types.

As you gain more experience in software development, you'll look back at this post and laugh.

Not satire, just hacker news.

I'm not sure where you're getting that idea. Are you thinking the target audience of this content is only for people developing JVM languages? It's not, it's how the vm and compiler work at a low level and optimize your code.

Zeromq is just a bit of sugar on top of tcp sockets. It isn't a message queue or anything close. You would be wasting a ton of time reimplementing a lot of basic features like retries, persistence, service discovery, dead letter queues, priority, and a ton of other stuff.

Pulsar wouldn't be the thing that stores the view, it would be the canonical data store used to rebuild the views.

The idea is you have an event sourced view and can rebuilt it at any time by resetting the stream pointer to the beginning.

> micro-aggressions

We're adults here, can we please not talk like tumblr blog posters?

Kafka can scale and distribute individual streams across the cluster. That is, the entire "database" is distributed across nodes. With postgres, your unit of scalability is the entire database. You can't natively have some tables on one node and some tables on another node, for example.

Kafka is also just more optimized for what it does. Postgres is a superset of what kafka does, so kafka is unsurprisingly better able to optimize for its usecase. It has a zero-copy protocol that can shuttle data to/from disk to/from the network without bringing it into memory (using the sendfile syscall). It doesn't wait for disk writes when doing writes, because it achieves durability via replication.

Also, don't forget the things you'd have to do when implementing consumers. How will you load balance streams between consumers? Meaning, if you have a stream and you want multiple consumers to burn it down at a time, how can you make sure they aren't duplicating work and they can handle the consumer group growing/shrinking? How will you handle checkpointing where each consumer tracks what they've done so far? What about streams' data rolling off?

All of this is doable with pg, but you'd have to implement it yourself. With kafka and its client drivers, this is handled for you.

It's much easier to scale kafka than a relational db. There's also an advantage to offloading the read load to another system instead of hitting the db for that, too.

Doesn't that mean you need to bubble up every dependency up the stack? Like if function a calls b which calls c which calls d, and d needs a new dependency, wouldn't that involve modifying a, b, and c's function signatures and all call sites?

I'm confused by what you mean. DI doesn't introduce any more dependencies compared to a non-DI approach (like hardcoding dependencies via module import or static methods), so how does it change the unit of work? DI doesn't add additional things to mock. DI simply means that dependencies are explicitly passed in. In a non-DI approach, they are implicit but still exist.

The "computer language benchmarks game" does not support this. Erlang is more than 2x faster than Ruby in cpu intensive tasks across their benchmarks.

The vast majority of people using a package manager in the PHP ecosystem are using composer. It makes sense to call it "the" package manager.

No it doesn't. All you have to do is search <language> <package> and you get relevant results. Look through your library list, it's pretty common for the names to only make sense in context.

Any language that doesn't have generics, including C and Go, have to work around that limitation. In C, people get around this by using void* (equivalent to using interface{} in Go) or code generation via macros.

I'd flip what you said and say that most of the people arguing against generics in Go don't have much or any experience with them. Which makes sense because a large number of users came from dynamically typed languages.

But like I said, Go doesn't have an answer for generics. So the complexity just lives in userland code instead of the language itself. The problem and complexity doesn't go away.

Coincidentally, here's Rust's getting started workflow:

- Install Rust

- Install VSCode + Rust plugin

- Start working

I really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance.

I suspect a lot of the generics hate is due to a large chunk of the community coming from dynamically typed languages. In which case they're just have a negative reaction to unfamiliarity.

It's an exception, not a crash.

But I want things.