But how do you deal with communicating that some library you maintain has a behavior change? People already need to know to look at your code in order to read your comments.
End users? Other Devs? These two groups are not the same.
As an end user of something, I dont care about the details of your internal refactor, only the performance, features and solutions. As a dev looking at the notes there is a lot more I want to see.
The artifact exists to inform about what is in this version when updating. And it can come easily from the commit messages, and be split for each audience (user/dev).
It doesn't change the fact that once your in the code, that history, inline is much much more useful. The commit message says "We fixed a performance issue around XXX". The inline comment is where you can put in a reason FOR the choice made.
One comes across this pattern a lot in dealing with data (flow) or end user inputs. It's that ugly change of if/elseif/elesif... that you look at and wonder "why isnt this a simple switch" because thats what the last two options really are. Having clues as inline text is a boon to us, and to any agent out there, because it's simply context at that point. Neither of us have to make a (tool) call to look at a diff, or a ticket or any number of other systems that we keep artifacts in.
This is kind of a fundamental issue with release notes. They are broadcasting lots of information, and only a small amount of information is relevant to any particular user (at least in my experience).
If I had a technically capable human assistant, I would have them filter through release notes from a vendor and only give me the relevant information for APIs I use. Having them take care of the boring, menial task so I can focus on more important things seems like a no brainer. So it seems reasonable to me to have an AI do that for me as well.
I read a lot of release notes in my job and the idea that that is some kind of noticeable time sink that needs to be streamlined is bizarre to me. Just read the notes.
It dipped during the covid recession and then recovered to an all time high. Is this your first time looking at an economic chart? It doesn't need to increase every quarter for it to have a very strongly increasing trend.
You're looking at what percent of the total wealth pie do the poor get. But the pie itself is growing, and so is _everyones_ slice of the pie.
Maybe you think its an inherent problem that some people get a bigger percent of the pie than others. But its objectively untrue to say that the poor are getting poorer.
> They are illustrations of a general principle: the legal inheritance channel compounds while the biological one reverts.
All this pseudo-math relies on the fact that family wealth strictly compounds and does not decrease or revert to the mean. But that is not true. Economists study this, and the exact numbers differ but family wealth _does_ revert back to the mean in just a few generations. Wealth does not stay in the same family compounding forever.
Fair point on the rhetoric: "no regression, no noise, just compounding" overstates it a bit. Individual family wealth does dissipate across generations. The model actually reflects this: η=0.85 inheritance fraction, threshold gating that blocks compounding below ~$20k, and a residual term that captures the noise and bad luck - which your sources are measuring.
The stronger claim of the essa is different from "any given dynasty compounds forever." It's Piketty's r > g: capital returns have systematically outpaced economic growth, so the wealth class maintains and grows its share even as specific families within it churn.
Being able to avoid an extra copy is actually a huge performance gain when you can safely do it. You shouldn't discount how useful mmap is just because its not useful in every scenario.
You shouldn't replace every single file access with mmap. But when it makes sense, mmap is a big performance win.
This reads like complete nonsense. If HTTP is involved, lets just give up and make the system as slow as possible?
The HTTP request needs to actually be actioned by the server before it can respond. Reducing the time it takes for the server to do the thing (accessing files) will meaningfully improve overall performance.
Switching out to JSON will meaningfully degrade performance. For no benefit.
> If HTTP is involved, lets just give up and make the system as slow as possible?
Did i write that? Please leave flamebait out of these discussions.
The original author (today) answered why they wanted to use this approach and the benefits from it. This has been missing in this entire discussion. So i really do not understand where you get this confidence.
> Switching out to JSON will meaningfully degrade performance. For no benefit.
Without knowing why or how the system was used, and now we know it is used as a transport medium between the db/nodes, its more clear as to why json is a issue for them. Does not explain how you conclude it will "meaningfully degrade performance" when this information was not available to any of us.
The differential on an EV is the same as on an ICE car. It does the same job either way, it doesn't care whether the power source is gas or electricity.
But on an EV, that's basically the only thing that needs somewhat regular "oil changes". Whereas ICE motors & transmissions also need fluid changes regularly.
reply