Given now bad things are, for those who don't eat too much meat, if you don't correctly supplement every single essential nutrient, and even many conditionally essential ones, you could be in a sea of trouble. Even then they won't get you sufficient phytonutrients. To make things worse, food is packaged in harmful plastics, and contains toxic pesticides, also PFAS containing pesticides.
What does the age of the style have to do with anything? You can ask them to write like Dickens or the King James bible or in Caesar's Latin, too, and these are even older.
In fairness, some of those older styles could alienate a reader, whereas mid-20th century style is practically like our own. To emphasize, this is narrowly about applying the style from an era, not the English from an era.
> 10g of sugar is 10g of sugar, regardless if it came from a strawberry, fruit juices, or HFCS.
From a biological pov, that is wrong on so many levels. It is why labels now have Added Sugars listed separately. Sugars as whole fruit aren't unhealthy in moderation, whereas HFCS is one if the unhealthiest added sugars. There is no way to equate them except in pure chemistry with no relation to biology.
>Sugars as whole fruit aren't unhealthy in moderation
That's why I specifically mentioned the processing part. Sugar in apple might not be comparable to sugar in a coke, but all of that goes out the window when you're comparing the sugar content of jellies.
>whereas HFCS is one if the unhealthiest added sugars. There is no way to equate them except in pure chemistry with no relation to biology.
Ok, you might not know this, but sucrose (white sugar) is a di-saccharide consisting of a molecule of glucose and one of fructose, which your body splits during digestion. So the amount of fructose you get from HFCS is almost identical to the amount you get from white sugar. Your body can't tell the difference.
That's why I don't get the US hype about Coke with actual sugar. It's still 50% fructose, what do you think will happen if you drink several cans every day?
I can tell the difference, but I couldn't tell you which is which.
This usually pops up around Passover, when Coke switches to an all sugar formulation for reasons I'm unqualified to explain. It's an "oh hey, this Coke tastes different", I'll check the label, and see that it's sweetened with sucrose instead of HFCS.
I'll handwavingly claim that this is close enough to a blind study/anecdote as I'm not Jewish and haven't a clue when Passover falls. As I buy cans, not bottles, it's not the yellow caps giving it away either.
I'd be wary of what people say they prefer in tests. People also prefer Pepsi to Coke in blind taste tests but they don't prefer it to drink an entire can.
Pepsi tastes much sweeter than Coke and I wouldn't be surprised if corn syrup Coke was sweeter than sugar Coke.
That's not metabolically true. Fructose by definition doesn't have glucose which is present in sucrose. Metabolically, your body absolutely reacts differently.
A core issue is that isolated fructose and its derivatives, e.g. HFCS, don't sufficiently trigger satiety. In contrast, regular sugar and glucose trigger satiety. This has been known for over a decade:
- Dissociable Behavioral, Physiological and Neural Effects of Acute Glucose and Fructose Ingestion: A Pilot Study (2015) (DOI: 10.1371/journal.pone.0130280)
- Attenuated hypothalamic response to fructose via a dedicated gut-brain pathway (2026) (DOI: 10.1016/j.neuron.2026.05.013)
Your body can't certainly tell the difference between glucose and fructose, but that's not what we are talking about. HFCS is typically either 42% or 55% fructose, which is very similar to sucrose (50% fructose).
If HFCS is problematic, white sugar is problematic in exactly the same way.
It is problematic that the ingredient label doesn't list which types of HFCS are used in the product. It could be HFCS-90 for all I know. The manufacturer could also keep shifting the formula. 90% fructose would be disastrous to one's health.
In fact a 2014 study found 60% fructose, not 55% as is expected with HFCS-55. This suggests a blending of HFCS-55 and HFCS-90 in a ratio that yields 60% fructose. This thuggery by hiding it from the label is bad for health. As a consumer, I am within reason to make the pessimistic assumption of HFCS being up to 90% fructose via HFCS-90, which for all practical intents and purposes is fructose. In any event, your claim of the product containing up to merely 55% fructose is falsified.
Fructose content in popular beverages made with and without high-fructose corn syrup (2014) doi: 10.1016/j.nut.2014.04.003.
The claim isn't that HFCS isn't bad for you, it's that it isn't worse for you than just regular sugar. Linking a bunch of articles about how HFCS is bad doesn't refute that.
Isolated fructose and its derivatives, e.g. HFCS, don't sufficiently trigger satiety, while stressing the liver and the heart. In contrast, regular sugar and glucose trigger satiety. This has been known for over a decade.
Whether you use 3.15 or not, if your project already passes a modern type checker, one thing that you can do easily using AI is to significantly tighten (narrow) the type annotations of your functions. Run this two or three times until the annotations are sufficiently but not excessively narrowed. This prevents a whole lot of bugs, and increases clarity of the code for AI.
This matters more for newer versions of Python which actually offer the constructs needed for it. Python 3.15 extends this with sentinel and enhancements to TypedDict.
I've been running a bunch of benchmarks comparing typed python to untyped python, and untyped python actually performs better now. I don't think it's the case anymore that types improve clarity to the LLM.
My hunch: The LLM has already been trained on the library, already knows the types. The annotations are just wasted noise/tokens at this point. (Also, majority of python is untyped, so probably has better "training data")
To be clear, you mean that the LLM performs better at working with un-annotated code?
(If you were talking about the runtime performance of the same code with and without annotations, then it's actually pretty obvious. The bytecode compiler doesn't use them to perform optimizations, because they can validly be complete garbage; and it adds overhead to have runtime `__annotate__` and `__annotations__` attributes, calls to do-nothing functions like `typing.cast`, etc.)
Huh. Your comment makes no sense, since types are ignored at runtime. Your performance benchmarks seems all noise. If it's about LLM speed, that's an atrocious thing to even compare. Writing code carelessly is fast, but it's also fast at adding bugs.
Types improve clarity to humans. Types also prevent future bugs by disallowing incompatible modifications. If you're not religiously writing types in function signatures, you're not developing professional software, just throwaway janky unprofessional scripts. I suggest looking at the OpenAI package to see just how well typed it is.
There is nothing stopping creation of rust implementations of tools or things that support these specs and protocols. But in DBMS world the centre of gravity is C/C++ mostly with some exceptions.
If I was writing a DBMS today, I'd consider Zig, never C/C++, as the latter continue to remain fraught with memory-safety footguns. So no, I don't concur with what's your center of gravity.
Fair enough. You wouldn't be the first (Tigerbeetle is famously implemented in Zig).
As someone who's personal spare time tinkering project is writing DBMS + storage engine in Rust I will say the language choice or it's memory safety is not that consequential.
If you're doing anything dealing with an actual storage engine you will be writing a bunch of unsafe code and using raw pointers all over the place. My hypothesis is once the guts are in place then I can go a lot faster with Rust but it's very much swimming against the tide and it is not magically safe out of the box once you are dealing with raw storage and paging.
But nonetheless if you go around the industry and do a count of commercial and Open source DBMS systems that have any kind of significant adoption it'll be about 95% C/C++ even if you filter to recent systems and there are legitimate reasons for that being a common choice.
TL:DR The hard part of a DBMS implementation is not picking the language
I don't buy your claim of "high-paying". If you don't pay as per US resident and urban standards, good domestic candidates obviously won't bother applying.
