The comment probably refers to data races over memory access, which are prevented by usage of `Send` and `Sync` traits, rather than more general race conditions.
I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.
I'm not sure I understand the point of your comment at all.
Rust does, successfully, guarantee the lack of data races. It also guarantees the lack of memory-unsafety resulting from race conditions in general (which to be fair largely just means "it guarantees a lack of data races", though it does also include things like "race conditions won't result in a use after free or an out of bounds memory access").
If by address it you mean "show how C/C++ does this"... they don't and this is well known.
If by address it you mean "prove that rust doesn't do what it says it does"... as that point you're inviting someone to teach you the details of how rust works down to the nitty gritty in an HN comment. You'd be much better off finding and reading the relevant materials on the internet than someones off hand attempt at recreating them on HN.
The point of my comment is that in my experience, incompetently written, overly-cautious code tends to be more safe at the expense of maintainability and/or performance.
Sadly, I don't know rustlang, so I can't tell if the inability to describe its features in more commonly used terms is due to incompetence or the features being irrelevant to this discussion (see the title of the thread).
The thing is you aren't really asking about a "feature" of rust (as the word is used in the title of the thread), unless that feature is "the absence of data races" or "memory safety" which I think are both well defined terms† and which rust has. Rather you're asking how those features were implemented, and the answer is through a coherent design across all the different features of rust that maintains the properties.
As near as I can tell to give you the answer you're looking for I'd have to explain the majority of rust to you. How traits work, and auto traits, and unsafe trait impls, and ownership, and the borrow checker, and for it to make sense as a practical thing interior mutability, and then I could point you at the standard library concepts of Send and Sync which someone mentioned above and they would actually make sense, and then I could give some examples of how everything comes together to enable memory safe, efficient, and ergonomic, threading primitives.
But this would no longer be a discussion about a rust language feature, but a tutorial on rust in general. Because to properly understand how the primitives that allow rust to build safe abstractions work, you need to understand most of rust.
Send and Sync (mentioned up thread) while being useful search terms, are some of the last things in a reasonable rust curriculum, not the first. I could quickly explain them to someone who already knew rust, and hadn't used them (or threads) at all, because they're simple once you have the foundation of "how the rest of rust works". Skipping the foundation doesn't make sense.
† "Memory safety" was admittedly possibly popularized by rust, but is equivalent to "the absence of undefined behaviour" which should be understandable to any C programmer.
> The point of my comment is that in my experience, incompetently written, overly-cautious code tends to be more safe at the expense of maintainability and/or performance
Well, yes, but that's the whole value of Rust: you don't need to use these overly-cautious defensive constructs, (at least not to prevent data races), because the language prevents them for you automatically.
Safe Rust does. To the extend Rust interfaces that wrap kernel APIs will achieve safety for the drivers that make use of them remains to be seen. I think it will indeed do this to some degree, but I have some doubts whether the effort and overhead is worth it. IMHO all these resources would better be invested elsewhere.
Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)
And from what I can see, rustlang mutability is also a type system construct? I.e. it assumes that all other code is Rust for the purpose of those checks?
> rustlang mutability is also a type system construct?
Yes
> I.e. it assumes that all other code is Rust for the purpose of those checks?
Not exactly, it merely assumes that you upheld the documented invariants when you wrote code to call/be-called-from other languages. For example that if I have a `extern "C" fn foo(x: &mut i32)` that
- x points to a properly aligned properly allocated i32 (not to null, not to the middle of un-unallocated page somewhere)
- The only way that memory will be accessed for the duration of the call to `foo` is via `x`. Which is to say that other parts of the system won't be writing to `x` or making assumptions about what value is stored in its memory until the function call returns (rust is, in principle, permitted to store some temporary value in `x`s memory even if the code never touches x beyond being passed it. So long as when `foo` returns the memory contains what it is supposed to). Note that this implies that a pointer to the same memory isn't also being passed to rust some other way (e.g. through a static which doesn't have a locked lock around it)
- foo will be called via the standard "C" calling convention (on x86_64 linux this for instance means that the stack pointer must be 2-byte aligned. Which is the type of constraint that is very easy to violate from assembly and next to impossible to violate from C code).
That it's up to the programmer to verify the invariants is why FFI code is considered "unsafe" in rust - programmer error can result in unsoundness. But if you, the programmer, are confident you have upheld the invariants you still get the guarantees about the broader system.
Rust is generally all about local reasoning. It doesn't actually care very much what the rest of the system is, so long as it called us following the agreed upon contract. It just has a much more explicit definition of what that contract is then C.
Also we can (in 2024 Edition) say we're vouching for an FFI function as safe to call, avoiding the need for a thin safe Rust wrapper which just passes through. We do still need the unsafe keyword to introduce the FFI function name, but by marking it safe all the actual callers don't care it wasn't written in Rust.
This is fairly narrow, often C functions for example aren't actually safe, for example they take a pointer and it must be valid, that's not inherently safe, or they have requirements about the relative values of parameters or the state of the wider system which can't be checked by the Rust, again unsafe. But there are cases where this affordance is a nice improvement.
Also "safe" and "unsafe" have very specific meanings, not the more widely used meanings. It's not inherently dangerous to call unsafe code that is well written, it's really more a statement about who is taking responsibility for the behavior, the writer or the compiler.
I like the term "checked" and "unchecked" better but not enough to actually lobby to change them, and as a term of art they're fine.
Yes. Just like C++ "const" is a type system construct that assumes all other code is C++ (or at least cooperates with the C++ code by not going around changing random bytes).
As far as I can tell, ANY guarantee provided by ANY language is "just a language construct" that fails if we assume there is other code executing which is ill-behaved.
a data race is specific kind of race condition; it's not rust parlance, but that specificity comes up a lot in rust discussions because that's part of the value
> since Rust is not the only language susceptible to data races.
The point is rather that it’s not. The “trait send sync things” specify whether a value of the type is allowed to be respectively move or borrowed across thread boundaries.
I mean, reliably tracking ownership and therefore knowing that e.g. an aliased write must complete before a read is surely helpful?
It won't prevent all races, but it might help avoid mistakes in a few of em. And concurrency is such a pain; any such machine-checked guarantees are probably nice to have to those dealing with em - caveat being that I'm not such a person.
When I'm familiar with the source, the headlines are enough for me to know if I want to read, navigating the folders is super quick, and the feed indicator makes adding new ones very easy too.
Or you can adblock and donate on Patreon etc. to your favourite channels. Not every channel you watch will benefit, but a much higher percentage of your money goes to creators, who generally get a less than fair deal from platform holders. Same goes for buying music on Bandcamp + pirating, versus a music streaming subscription.
Measuring GDP adjusted by purchasing power parity, but not per capita, seems like an odd metric.
PPP-adjusted GDP per-capita gives an indication of the level of goods/services affordable by an individual citizen. Total GDP, unadjusted, is an indicator of a country's economic power. What does PPP-adjusted total GDP indicate?
Yeah, take something proportional to how big (population) AND rich a country is. Divide this by a metric that grows with how rich a country is. This way poorer but bigger countries score better. But that doesn't tell much.
The US is a country with rich people in it, it’s not a rich country.
( I live in New Orleans, 35% of kids don’t have enough calories per days to have a proper brain development. And New Orleans is fine compared to the rest or Louisiana )
> in New Orleans, 35% of kids don’t have enough calories per days to have a proper brain development
Source? I find that hard to believe, considering how cheap and plentiful calories are and how numerous the various public assistance programs exist relating to feeding the poor.
I know it’s intense. Those people must be stupid. Or it’s their fault and they deserve it. ( :s ! )
My bad for the figure, I had a third in mind. It’s less. Can’t find a general population figure in the short amount of time. 20 ish % of black kids is enough or it’s fine ?
What was eye opening to me was volonteering in a random school. And noticing how the breakfast was a important and respected steps. Like.. not everyone had dinner last night.
Been to new orleans. Didn't see anyone with 'caloric deficit' issues.
And you have it backwards. Louisiana has a problem with an overabundance of calories, not a lack of calories. Louisiana is one of most obese states in the country after all.
Or “no kid hungry Louisiana”, that the one I noticed here. Giving breakfast out in school. My first reaction was to wonder why. Digging I realized that a fair amount of kids were coming to school on a empty belly.
That’s it.
Also “been to New Orleans” is a funny statement! Congratulations on seeing Jackson square and the French quarter. It’s a city, not 10 historical blocks.
I find it utterly bizarre that this kind of ignorant hand-wringing is so pervasive. The US median household income is ~6x the global median. The average US household in the bottom income quintile has an income above global median before accounting for 10s of thousands of dollars in in-kind transfers (i.e. welfare).
> 35% of kids don’t have enough calories per days to have a proper brain development.
The article says nothing about children lacking the calories required for brain development. It says 23% of black households self-reported "not having enough food in the past week". Which is weird, because when I go looking for objective data that might support the assertion that a significant percentage of the population isn't getting enough calories, I don't find anything. I did find an article that obtained weight data on both whites and blacks nationwide, and broke them down in Underweight, Normal, Overweight, and Obese categories... but the number of underweight individuals was so low that it rolled them into the 'Normal' category, and didn't even report the Underweight category. It's almost like everyone is getting more than enough to eat!
Neither your anecdata on "visible poverty" nor the US Gini index contradict the obvious fact that the USA is, by any serious measure, a rich country.
So everything is fine and my experience is anecdotal.
It truly makes me feel better.
I should do the same exercise you did with Swiss data.
That what come to my personal mind when I think of “rich country” not the lower 9th ward, or New Orleans East.
But since the US is rich like demonstrated.
I should actively start to reframe those place into “rich”. And look more at all those fat people in the street.
One area it can come up is the country's ability to self-supply things.
To take a example that is currently of interest, Russia's ability to manufacture weapons is far greater than that if a country with the same nominal GDP but is closer to its PPP GDP (plus the effects of being more self sufficient than most countries other than the big two).
I liked a russian hacker's story of building an IR camera by repurposing an old scanner: at one point he tries to source a detector from China but is unable to order it because of (he says) US export rules; then he remembers he's from a country that builds its own air-to-air missiles, and finds a Russian supplier who sends him the part...
I believe the rationale here is that if you can source some gadget from China, it's going to be ten times cheaper than any alternative, since there's an enormous stock of those there used to to make other gadgets, therefore low margins and high turnover.
Yep, maybe GDP is not a great measure if one country can produce a box of cookies for $1 while another $4. Turns out physical output is important (bushels of wheat, pounds of steel, # of cars, etc).
As we're seeing now, it's an even bigger problem when a country produces an advanced military gadget for $1 and the other country can't match it in terms of production for even $50.
> Measuring GDP adjusted by purchasing power parity, but not per capita, seems like an odd metric.
Depends on what you want to compare.
If you want to understand the "heft" of the country in terms of the sheer size of the economy (adjusted for exchange rates) then you do country GDP on PPP basis.
If you want to understand the size taking into account currency rates then you do plain GDP.
If you want to understand how well off a citizen is THEN you do per-capita GDP.
When countries play on the world stage for influence, their overall heft i.e. total GDP (whether on a PPP basis or not) is essentially the main determinant.
"Heft" is how much weight a country can throw around to affect other countries. Stuff like fighter jets & aircraft carriers, aid deals, trade deals, purchasing assets in other countries, et cetera. Most of that is in trade currency, so no PPP adjustment. Building fighter jets is cheaper in low-PPP countries, but only partially. So, no I don't think you should PPP adjust if you want to measure heft.
> Building fighter jets is cheaper in low-PPP countries, but only partially.
Even that holds only true if all other things are equal. But low PPP countries are strongly correlated with less industrialization, less educated workforce etc. That's why most (low-PPP) countries, even large ones, don't produce their own jets - it's cheaper to buy them.
> Most of that is in trade currency, so no PPP adjustment.
It's non-trivial to make that cut. I'd say things PPP for stuff like food doesn't count, but PPP for even rather basic industrial products already does.
PPP-adjusted total GDP indicates ability or capacity to work on commodity-industries industries, like construction, or furniture, where establishing new industries doesn't need as much new research.
PPP-adjusted GDP is an indicator of the level of goods/services affordable by all citizens together.
The treemap shows how global total purchasing power is divided between countries.
A treemap of GDP PPP per capita would show the breakdown of purchasing power if you put one citizen of each country in a single room. I think a bar chart would be a better choice in that case.
If you plot the US' nominal GDP over time in terms of USD, it looks pretty smooth, while other countries bounce around a lot more.[0] That's because other countries' USD nominal GDPs are affected by exchange-rate fluctuations.
If you plot in terms of PPP GDP, other counties suddenly appear much smoother.[1]
Refrigerators and automobiles usually cost the same. Rich countries may be buying fancier ones, while mid-tier countries may sometimes have significant tariffs on cars.
But eating out, getting education, child care costs and foremost real estate, are all deeply PPP corrected.
As always, remember to consider humidity when compararing locations - it can make both cold and hot weather feel much harsher. I'm more comfortable in 40c at low humidity than 25c at 90%. The UK experiences much more of the latter.
Could "energy density" not refer to energy-per-volume rather than mass? Then that headline might make sense per this quote from someone at Honda: "Simply, the energy density would be doubled. So same energy, same volume base, kind of half [the weight]"
Although the author himself confuses the matter, suggesting volume is also reduced: "If Honda's solid-state batteries truly do cut weight and size in half without reducing performance, there could be quite a bit more space in the floor of future Honda vehicles."
