But I understand that if this proposal makes the cut, other compilers would implement it too and make this universal. Seeing this seems to implement all of Rust’s safety features, this would seem like a win here.
It is, although "nobody's going to rewrite millions lines of code" applies to C++ too, not only Rust.
You won't be able to just slap `#pragma safe` on top of every file and have the problem solved. It does require use of different design patterns and structuring data in a way that works with borrowing.
In the article, it says "The Rust *struct* has a smaller size compared with the C due to the usage of smart pointers instead of allocating item memory inside the *struct*. We use *pahole* to identify that Rust *struct*s use fewer cache lines than their C counterpart."
As far as I know, you can also use pointers (not smart ones, that's a C++ thing) inside structs in C, right? Like this:
It's located in Spain, a country not known for its vast wealth. Plus, it's in a special administrative region in Spain, the Basque Country. They enjoy subsidies and favorable treatment from the regional government.
I'm from Spain, so I'm quite sure of what I'm talking about. Spain might be a highly developed country, but its gdp per capita is not too high compared to the likes of Germany, UK, France, Denmark, US, et al.
Basque country is, again, rich because it has an special tax treatment and could be considered a tax heaven to some extent.
The Basque Country has a GDP (PPP) of 108 [1]. Higher than France (101), as an average, or Italy (97).
I'd say its a well developed region comparable to Northern Italy. Both were badly hit by the Euro. Had they kept their own currencies, they'd be closer to Sweden or Southern Germany.
Indeed. All they got was inflation. Just like our government flooding the country with printed money. Same cause, same effect It's not a mystery what causes inflation, and inflation does not result in prosperity.
It is not. It is not implemented in std::string::String, but (as pointed out elsewhere in this thread) there are other string implementations that have it.
It was decided explicitly against for the standard library, because not every optimization is universally good, and keeping String as a thin wrapper over Vec<T> is a good default.
This is one of those things that I wish people would speak more carefully about. I've seen it in every programming language community I've participated in, so it's not a language-specific thing, but... one should not say "language X does not do a thing" when they mean "language X's standard library does not do a thing". That the "language" doesn't do a thing should be reserved for the cases where the language itself really does preclude some particular thing for some reason. Otherwise the relatively inexperienced programmers end up coming away with some really weird mental models of what programming languages can and can not do, just like here. Of course Rust qua Rust can store strings like this, it's basically built for things like this. Any mental model of Rust that thinks Rust qua Rust can't do this is a weird mental model of Rust.
The "small string optimization" makes the strings harder to manipulate with `unsafe` code. However, being easy to manipulate with `unsafe` code is in fact a priority for most std types, so that they are easily understood, extended, rearranged, passed over FFI and then later reconstituted, etc.
You can tear apart these types and reassemble them very easily. For many C++ std types, you cannot do this.
Rust APIs use string slices (&str) extensively. With its current design, converting from a String to a &str is a no-op; if String instead did small string optimization, converting to &str wouldn't be free. Furthermore, thanks to the borrow checker, Rust code tends to avoid copying strings around, so the benefit of SSO is reduced. C++ does more string copying and didn't have a standard string_view for a long time, so considering the tradeoffs both languages made reasonable decisions.
It adds a branch every time you access the string (to check if it is small or not), and can stop various optimisations. g++ used to have small string optimisation, but (eventually) removed it.
Everyone around here keeps talking about how the problem of Intel is that it was a Business guy running the company and not an engineer, and it feels so similar to when people claimed Phil Spencer was going to save Xbox.
Truth is, Pat is doing nothing despite the generous government subsidies
Not everyone is cut from the same cloth. Look at AMD, their CEO history has been staffed exclusively by people with engineering backgrounds, but their performance has had more than a few rocky points.
This is simply not true. They are building giant fabs in Arizona and Ohio from those subsidies.
It takes YEARS to realize the benefits of these changes.
The problem is, to stopgap TSMCs growing lead, Intel resorted to cranking up voltage on the last two generations of chips leading to what will be an imminent gigantic ass lawsuit.
This is where I see that Intel Processor are pushing the cart for Intel Fabs by small iterations to sell new processors and mother boards. Intel Fabs needs to push it's own cart like TSMC and actually focus on long term quality and gains.
The previous CEO was going to shut down the fabs. Maybe it would have been the right strategy but Pat Gelsinger had reoriented towards fab manufacturing for what it’s worth.
>it feels so similar to when people claimed Phil Spencer was going to save Xbox.
Well, he did. He bought up a ton of studios and focused on games again. in 2014 they were completely tonedeaf to the state of not just games, but media as a whole. Cable box subscriptions even in 2014 for their 8th generation console was just horrible optics.
Now, is it his fault directly that the game development per studio is slow, or the releases uneven? He's probably not blameless, but MS isn't really known to intervene nor micromanage their studios. IMO that's a much bigger issue than any single MS studio.
reply