Dr. Michael Greger's books (and website: https://nutritionfacts.org) boast an astonishing amount of citations of medical studies. He readily acknowledges the vast volume of literature around nutrition, with more and more studies being published every year. He and his volunteers have taken on the mission of wading through it and making sense of it.
His books, in order of publication:
- How Not to Die (2k citations)
- How Not to Diet (5k citations)
- How Not to Age (13k citations)
I experienced a similar change (more energy and steadier energy levels throughout the day) after switching to a plant-based diet, which has been shown to change one's gut microbiome over a few weeks.
I find it very intuitive, but maybe it's because of a missing link or two.
Boolean arithmetic sometimes uses + for OR and * for AND. When considering only zero and non-zero values, the semantics are the same. 1 + 1 + 0 is non-zero, 1 * 1 * 0 is zero. Substitute + for OR and * for AND, and you wind up with the "same" result.
From the linked article:
> one is „and data“, the other is „or data“.
Structs/records/product types fit the description of "and data", because it's a compound value comprised of this type AND that type AND that other type, etc.
Unions/sum types fit the description of "or data" because it's either this type OR that type OR that other type.
They switched to microservices written in Kotlin, resembling the rest of their backend stack. They had an easier time hiring and retaining Kotlin developers than Erlang/Elixir developers.
Woolly mammoths were a geoengineer species that have no living proxy. Bringing them back is definitely a controversial project, but there's a case to be made that de-extincting the woolly mammoth could help prevent permafrost from melting.
> I look at the reddest part of the chart, I look at the peaks
Neither of these are really the places I look at when examining flame graphs. I tend to look at the bottom, and work my way up.
The key thing (imo) to look for are wide pieces that are not a core part of what the code you're profiling is supposed to do.
In the first example of your first link, you have a flame graph of code that seems to draw an image. There are a bunch of functions like 'CopyPixels' and 'RasterizeEdges'. Those seem to be a core part of drawing an image. In contrast, there's a 'KiPageFault' function that's pretty wide that does not seem to be important to the code's overall goal. I think a bit more context is needed to arrive at the author's conclusion, though.
I think flame graphs, like all graphs, are more helpful when the reader has a lot of context about what's supposed to happen, or some intuition about how the chart is supposed to look.
These properties are explained in great detail in volume 1 of Christopher Alexander's The Nature of Order.
Reading about these with accompanying images of spaces or objects demonstrating the presence or absence of these properties is what made it stick for me.
Marcus Aurelius's Meditations is a wonderful guide on how to apply various principles of Stoicism, especially principles around cultivating resilience in the face of circumstances beyond one's control.
However, to read only Meditations and go on to make claims about the philosophy as a whole is a bad idea that ignores hundreds of years worth of philosophers who also contributed to Stoicism.
For those interested in a more broad treatment of Stoicism, a wonderful follow-up to Meditations is Donald J. Robertson's Stoicism and the Art of Happiness
The Stoics had plenty to say on what constitutes a good life. They might have also cautioned that a 'joyful' life may not be the same thing as a 'good' life, if that joy is derived from vice or a lack of virtue.
Are you sure? My understanding is that people who live in dense cities rely less on automobiles, have their waste treated more efficiently, and consume less energy per capita in order to enjoy clean air and water. Those factors are more important than the land mass required to feed someone.
The current SCOTUS seems to be fine with coaches coercing teenage athletes into public prayer sessions, overturning a previous SCOTUS ruling.
Meanwhile, I find it ironic that the same state enacting this "intellectual diversity" law has specifically banned teaching critical race theory in public schools.
A voluntary survey invites participation bias; respondents will likely skew heavily toward the "I feel I am being indoctrinated/I feel uncomfortable voicing my beliefs". The spirit of the law aside, this law looks like a lever to pull funding from universities where the median Floridian, who votes Republican, would feel like their views are being challenged.
Chiming in with 6 years of professional Erlang experience. I'm somewhat familiar with Elixir, having worked on some Elixir codebases for a few months.
> The notion that to learn a language you also need to learn a second one is not great. [...] It's just bizarre.
I disagree. I don't think it's bizarre. I expect to sometimes have to poke around in C code when writing Erlang or Python. It's also fairly common for C/C++ developers to look at the assembly output of some piece of code using https://godbolt.org/.
> Reading the code is NOT an answer.
Again, I disagree, and I think this perspective is harmful to career development. Knowing how things work on a deep(er) level is a superpower. When you're writing Elixir, do you never open up a .ex file in the standard library to see how something is implemented? Are you not at all interested in what powers things like Phoenix.PubSub?
> I don't know what a solution is, but perhaps a concerted effort to create a documentation and library ecosystem that never links back to Erlang would help.
I suspect that a library ecosystem that doesn't require Erlang would be a huge effort to implement and test, and would wind up pulling in all of the ideas from Erlang that you haven't learned/mastered yet. A better alternative would be to accept the fact that Elixir builds on top of Erlang, and understand that a deeper knowledge of Erlang is going to help you improve as an Elixir developer.
> And where there are critical systems that use an Erlang library, perhaps rebuilding it in Elixir is in order?
I'm definitely biased, but I would be much less trusting of an Elixir copy of a 'critical' Erlang library. Many of the selling points of Elixir that lead to very concise code (read: macros, 'using', and others) are things that make it difficult for me to develop a deep understanding of a library. It's cool to use DSLs like Ecto and Plug, but I have a much harder time understanding those libraries as a result. Erlang's unambiguous syntax and its basic text-substitution-based macro system are much easier for me to understand, and while it takes more effort to write APIs and code that are as concise as what's available in Elixir, I know that I can open up an Erlang file and trust that much less is hidden from me.
> What the WSJ describes would not be possible with our privacy practices today, practices we proactively implemented two years ago
> Grindr takes the privacy of its users extremely seriously, and we have put privacy before profit
> Grindr does not share users’ precise location, we do not share user profile information, and we do not share even industry standard data like age or gender
I implemented and deployed a state synchronization protocol based on CRDTs at my last job. It replaced a protocol that needed a fully connected mesh to function properly, and the entire cluster would suffer a grey failure if a connection was broken or slow. The new protocol was much more resilient, and was able to take advantage of the transitive property of state-based CRDT operations.
My solution for garbage collection was pretty boring. Occasionally, a JSON file was rsynced to each service node with the 'true' state of the system at some time in the past, and the CRDT maintained the new state on top of that JSON file, until the next file got rsynced.
His books, in order of publication:
- How Not to Die (2k citations) - How Not to Diet (5k citations) - How Not to Age (13k citations)