Then please enlighten us and tell us what you feel the article is about rather than a snarky "rtfm" comment.
Because I started reading. I got pretty far, and it was _still_ talking about integer types. The article is very long, and I gave up, not having any idea why I should keep reading. So saying the article isnt about them "at all" is wrong.
Maybe, the int type thing is an intro to some other thing? But thats a long intro. So, tl;dr, at least not all the way. Why don't you tell us the point so we have desire to actually read it.
Conveniently, there's a table of contents at the start that hints at the later topics:
Different kinds of numbers
Conversions and type inference
Generics and enums
Implementing traits
Return position
Dynamically-sized types
Storing stuff in structs
Lifetimes and ownership
Slices and arrays
Boxed trait objects
Reading type signatures
Closures
Async stuff
Async trait methods
The Connect trait from hyper
Higher-ranked trait bounds
Afterword
So 17 sections, 16 technical (excluding the Afterword) and only the first two focus on the int/float stuff. So to answer your question:
> Maybe, the int type thing is an intro to some other thing?
No, it's not an intro, it's just the first two sections.
> I hope I was able to show, too, that I don't consider Rust the perfect, be-all-end-all programming language. There's still a bunch of situations where, without the requisite years of messing around, you'll be stuck. Because I'm so often the person of reference to help solve these, at work and otherwise, I just thought I'd put a little something together. [emphasis mine]
As you can also see from the table of contents at the top of the article page, it goes through a great breadth of topics. And you can use that table of contents to jump to the afterword.
Since you don't seem to have commented on the article without reading it, my comment was not addressed to you. I'm not the article police; if you find something too long to read, decide not to read it, and move on with your life, we have no quarrel.
Honestly, I don't even mind the folks who do comment without reading. Comments are free, do what you like. I just find it mildly hilarious that 100% of the comments are about (the first) 3% of the article.
I did read the beginning of the article and I wasn't too impressed. So I went through the comments, looking for bits of wisdom that might hint reading the whole article was worth it. Still, I wasn't impressed.
I'm curious how this can both avoid the average-of-averages problem (presumably by using the original full-rate data to compute multiple aggregates) and also supports backfilling. Is there a danger of the full-rate data expiring and having a different behavior for backfills past that horizon? Or am I wholly misunderstading both these features?
Great question. We support average of averages by storing the intermediate state of the aggregate (for average that's the sum and count) so we could cleanly re-aggregate.
Eventually, we'll be able to incrementally update the aggregate if we backfill even if the raw data is no longer available. That's not implemented yet though, so backfill only updates the aggregate if the raw data is still around by re-computing the intermediate state of the aggregate off the raw data for affected buckets. For most cases that isn't actually an issue since most people have a longer data retention period than backfill horizon.
Thanks for the answer! I'd love to know more :) Also, I'm not following, how you guys deal with issues with unique counts? For example, lets say you've got 100 unique visitors on Monday and 100 on Tuesday. The unique visitors for both days might be anywhere between 100-200 and averaging counts between days doesn't work.
Not sure about this specific implementation but normally you handle this with approximations that support merging. i.e HyperLogLog
You can merge 2 HyperLogLog counters to maintain proper distinct counts.
And in fact, that's exactly what TimescaleDB supports - things like hyperloglog to support approximate count distinct, including as part of continuous aggregates. [0]
This blog post - "How PostgreSQL aggregation works and how it inspired our hyperfunctions’ design" - provides a really nice description of how our the API design of some of our analytical functions are motivated by the ability to "split" processing into the "pre-aggregation" and "finalization" steps, with the blog post focusing on the example of percentile approximation. (I think it was on HN a while back as well.) [1]
There exists a message board called "Credit Cards and Consumer Debt" within the Motley Fool. I commented there for a few years on a variety of subjects, under a pseudonym (which is laughably transparent to anyone who knows me but please don't take that as a challenge, HN).
I was originally there because my credit report suddenly got $100k+ of debt added to it due to a series of errors. I researched the CRA and FDCPA and, in the process of doing so, found that forum. Many folks with different fact patterns needed relatively similar resolutions to mine or ones which were predictable based on information I had access to, so I started writing replies like "Yeah just write your bank and tell them $FOO." It turns out that the types of folks who end up deep in credit card debt often have some difficulty in banging out a quick professional letter. I didn't, and I had a lot of free time on my hands, so I drafted perhaps a few hundred letters.
This is one of my more esoteric hobbies, but it has been occasionally useful over the years.
so is the capital gains tax only on the profit from the stock? wouldnt it be better just to sell instantly and not have so much of your money tied up into one asset anyway? Sorry if these are basic questions
What about ion engines? I'm extremely not sure I have this math right but NEXT claims 4190 second ISP [0]. Plugging that into the rocket equation I get:
Total vehicle mass: 482,646.89 kg
Fuel to add: 63,046.89 kg
Dragon 2 launches: 19
Total cost: $1,178,000,000.00
Not what you'd call cheap but at least in the realm of the possible. I'm assuming the ISS' solar panels (~120 kW [1]) is sufficient to power the thruster, that a dragon launch costs no more than a falcon launch (certainly false), and that the ion engine is already on board the station.
Car ownership is extremely broad across all income groups in the United States, see http://www.newgeography.com/content/002666-how-lower-income-.... The overwhelming majority of income taxes are paid by high earners, with the the top 10% paying close to 70% of all income taxes. If roads are subsidized by income taxes in addition to gas taxes, they are being paid for in an extremely progressive way. Effectively, roads are provided for free to over half the population.
Or maybe I misunderstood and you are trying to make a different point?
Half the population doesn't pay gas taxes? You're aware that they do. That was a silly thing to say. Gas taxes may be trivial to the portion of the population that pays most of the income taxes, but I doubt the bottom half thinks of them that way.
You need to show what portion of the road cost is paid for by income taxes before you can claim the rest.
I don't understand why you brought any of this up. A subsidy is a subsidy no matter who pays.
You are correct that I made an error in my calculation, but my point still largely stands.
I took the parent at face value for the claim that 50% of roads are funded by use fees. That means the other 50% are paid for with general income taxes. Nearly all income taxes are paid for by the top half of earners. If we assume that everyone drives about the same amount, then the bottom half of the country gets the full value and use of roads while only paying for 25% of the total cost.
I bring this up because the parents point seemed to be that road subsidies are an implicit subsidy to oil companies. But people need to get around somehow, and the current way of funding roads should be perfectly compatible to conventional morality.
At the same time, I oppose all subsidies and can only imagine the amazing methods of transport that would exist if the government did not actively interfere and manage this market.
Hint: it's not about integer types at all