UCS32 is certainly an option. It would probably turn me off from Rust entirely, though, at least for my current work. When your device only has a few KB of RAM, quadrupling the size of your strings would be really painful. I'm unhappy that my pointers and register-sized integers are each 8 bytes, so a slice consumes 16 bytes (pointer plus length), minimum. I hate it so much I might consider creating my own string type that only handles strings < 64kb in length, so I could use an 8-byte pointer and a two-byte length -- but ARM has pretty strict alignment requirements so the compiler would pad the u16 out to eight bytes anyway. And all of my strings are error messages which are seven-bit ASCII.

As for your abstracted version... note that in my code I not only don't have GC, I don't even have a heap... no dynamic allocation :-)

With Rust as-is, that means I don't actually have String, but I *do* have &str.

You can certainly argue that one language shouldn't try to address the requirements of tiny microcontrollers to servers with hundreds of GB of RAM... but it's actually really nice that it does.

Rust doesn't try to prevent devs from writing bad code, it tries to prevent devs from writing unsafe code (i.e. code that can exhibit undefined behavior), and the approach to strings is safe. If you index a string at byte offsets, and try to use that data as a string and it's not valid UTF-8, your program panics in a safe, well-defined way :-D

Perhaps not "as easy", but certainly not hard. Spend some time thinking about what kinds of covert and overt pressures might be brought to bear.

Aside: As an American, I think it's very sad that people lump the US and Russia together in this way. I think it's even sadder that I can't honestly argue that they're wrong. At most I can try to argue that there is still a significant difference of degree, if not kind, but it's not really worth making the argument because the degree of different is heading rapidly to zero. I deeply hope we can turn it around, and I'm doing what I can in that direction, but...

The latter. I'm pretty confident that TLS is secure. The modern ciphersuites are tight and things like the certificate transparency log make it so that while the TLAs might be able to subvert the CA process, they can only do it in small-scale, tightly-scoped ways. If you are a personal target of interest of any national security agency, you're screwed. They absolutely can get into every aspect of a private citizen's life if they want to put some effort into it. But the transparency log means that if they attempted to do this in any kind of large-scale way it would be discovered and publicized, so the fact that we don't hear about it truly does mean that they're not doing TLS penetration at scale.

However, even if they can't get the content of the connections, they can see where you're connecting to, and when. That sort of traffic analysis provides a surprising amount of information, and it can be done at scale -- and using a third-party VPN generally makes it easier, not harder. Layering VPNs can help a lot. Done carefully, you can structure it so that someone would have to control all of the layered VPN servers in order to track your connections. Layering plus multiplexing (using multiple providers and picking different routes and exit nodes for every connection) could make it really hard.

And if you don't really believe that traffic analysis is a concern, then there's really no point to using a VPN at all (except for location shifting), because TLS really is quite secure. It's definitely silly to, for example, fire up a VPN before connecting to your bank while at a coffee shop or an airport, which is exactly the pitch that many VPN services make. "Be wary of untrusted networks" is their pitch, and it's stupid[*]. If you're concerned about your online activity being tracked it's the "trusted" networks you're on most of the time that are the point of concern for traffic analysis. And the "trusted network" that may be the biggest concern is your VPN provider.

[*] Note that it's not stupid to be frightened of untrusted networks, but kinds of risks that exist with untrusted networks are generally not mitigated by VPNs. The best solution to those risks is keeping your device patched up.

There are a few ways to do it. The most common is to use the chars() method, which gives you an iterator over characters. So, for your example, something like "s.chars().skip(5).take(5).collect()". If you really need to do heavy unicode text manipulation (e.g. you're writing a text editor or something), you probably want to use some of the available crates, e.g. unicode-segmentation.

Clearly, as you say, this isn't what a lot of people would consider full, native support for UTF-8. Really doing it right would impose a heavy runtime penalty on the vast majority of simple string usage that doesn't need it, so Rust compromised: If you have a &str or a String in Rust, you know that what it contains is valid UTF-8 -- which means that when you create one you're paying the validation penalty, even if you don't need it... however, the penalties scale in an unsurprising way. When you create a string from bytes, the validation is an O(n) operation, but you also have to copy the bytes, so it's already O(n). When you slice a string, the slice validation only has to check the first and last characters of the slice, so it's O(1), as you would expect slicing to be. You might not naively expect slicing to panic with a UTF-8 validation error, but you should expect that it might panic with a bounds-checking error so the fact that it might panic isn't surprising. And, of course, you can use the get() method to get Err() instead of a panic.

Full native UTF-8 support would be a lot heavier. Many common String operations would be O(n) rather than O(1) -- including indexing! The APIs would be quite confusing to people accustomed to C-style strings, too, another cost. So, Rust doesn't do that. Instead, if you want the length of a string in Unicode characters, you use s.chars().count(). If you want a substring with character offsets you use s.chars().skip(n).take(m).collect(), or similar. These operations do not look like they're O(1) which is good, because they're not. They're also not nearly as slow/heavy as they look.

Like most compromises, this one makes no one really happy, and many people will disagree that it's the right choice. But I don't really see a better option, do you? Keeping in mind that everything from device drivers and bare-metal microcontroller code to browsers and editors is included in the target space, and that having different wide and narrow string types has proven to be a bad idea.

I should have included organized crime syndicates in that list, though thanks to Google's TLS-all-the-things push traffic sniffing is less useful for stealing money, and criminals generally have less interest in spying on people by doing traffic analysis.

Because Russia and the US are incapable of compromising or suborning providers from elsewhere?

Those are all ways to avoid installing questionable software on your primary machine, which is good, but they don't address the fact that you're still routing all of your traffic through someone else's server -- a server that tends to concentrate lots of potentially interesting traffic in one place, making it a much higher priority target than your typical ISP.

If the various intelligence and law enforcement agencies around the world don't own or at least have significant hooks into all of the major VPN service providers, someone should be fired for not doing their job.

Really? I've never, ever heard that pitch for AI.

Also, the amount of energy required to reverse it... it's hard to see where that could possibly have come from.

The name of the product is "Bomb", and "Bomb" is the default Bluetooth name.

I don't know whether that makes you advice invalid, or all the more salient.

ROTFL

Social engineering redux... except now you only have to convince a sycophantic and overly helpful AI.

Many people incorrectly think of proxies and VPNs (especially VPNs) as a security and privacy enhancement, but unless you're operating the proxy/VPN server yourself they're just as likely to be a massive security and privacy risk. The problem is that they concentrate all of the traffic you'd most like to keep secret in one server, and depending on exactly how the system works, may require installing software on your local machine with ~root permissions. If the operator is malicious, this is a really dangerous combination.

These are useful tools for location shifting and -- in fairly rare cases, and with VPNs only -- from hiding traffic from malicious. But third-party proxy/VPN services should always be viewed with suspicion. Obviously this is even more true when the provider is Russian... though it's pretty likely that wasn't made clear to the people who used the service.

A person can be sane and immoral, sane and moral, insane and immoral or insane and moral. "Orthogonal" is perhaps a little too strong, since it implies the absence of any relationship, but certainly all the combinations are possible.

Sanity and morality are orthogonal.

heapless is quite useful in many contexts, yes.

As for what my design goals are, it's a pretty typical LRU map. I assumed that the name would tell you what the purpose is, but perhaps not. Please excuse me for belaboring if you are already familiar with these concepts; I don't know what you know, so I figure it's better to be clear. If you do, skip the next paragraph.

An LRU (Least Recently Used) cache is a cache that has a fixed maximum size and when a new item is added that would cause it to exceed that upper bound, it discards the "oldest" entry in the cache, where "oldest" is defined as least-recently used. An LRU map is similar but it is "primary storage" not cache, but still with a fixed capacity so when you try to put more in it than it can hold it has to discard something, and it does that by discarding the least-recently used item.

In my case, I'm writing code that services client code running on other CPUs in the same SoC. The client transactions are moderately long-running, each involving a sequence of requests delivered over the course of a few seconds, though some sessions legitimately go much, much, longer, and each such session requires me to track a non-trivial amount of state, not so much for efficiency as for security; I can't hand the internal state back to the caller because that might allow an attacker to mutate it or roll it back (if rollback weren't a concern, I could outsource a MACed copy of the state). I keep the operation state in a map structure, keyed by an operation ID. But clients can die and clients can misbehave, so I can't safely rely on the clients to always send me the termination message that allows me to clear the operation state.

So, I need some way to ensure that my map doesn't fill up with stale operation data, preventing new operations from being started. LRU eviction is a cheap and effective method. But this means that sometimes clients are going to send a request for an operation that I have evicted, so I have to return an error message. I could just always say "Operation ID not found", but then clients have no way to distinguish between cases where they just waited too long and cases where I suffered a failure or was reset. The clients often respond to these different failure modes in different ways.

For that reason, I keep a "recently-evicted" list -- but that also has to have a fixed size limit. In practice, my recently-evicted list consists of two lists, an "old generation" list and a "new generation" list, both with fixed size limits. Every time an operation is evicted, it's added to the "new generation" list. When the new-gen list is full, I move it to the old-gen list (in practice, I really just change which list is considered new and which old; no need to copy it). This is a cheap way to "age" the eviction records, without actually having to track their age in an LRU fashion (which would ~double the per-entry storage required, halving the number of evictions I can track). When a request for an unknown operation ID comes in, I search both lists to see if the ID has been recently evicted. If so, I remove the ID from the list and report the error to the caller. The reason for removing is to make space for a new eviction record, to maximize the scenarios in which I can notify clients.

Regarding your comment about encapsulation being overused... this is not such a case. The purpose of encapsulation, properly applied, is invariant maintenance, and there are some important invariants that have to be maintained for the LRU map to work. One of those is that insertion must execute the eviction logic, so even if I could move the map out temporarily, that would create an opportunity for bugs if the calling code does not correctly handle eviction and maintenance of the recently-evicted list. Another (less crucial, but still important) is that the recently-evicted list should only contain entries for clients that haven't yet been notified.

That said, there actually a good argument that the `recently_evicted` method is conceptually non-mutating and I should use interior mutability. Either that or I should rename it to "remove_eviction_record", so it's clear that it is inherently a mutating operation. I will do one of those two things on Monday -- thanks for helping to improve my code. I would prefer the rename for clearer semantics, but interior mutability will allow me to avoid the extra map lookup, so I'm leaning that way.

One other comment about something you said, which you might find interesting: You said that in Rust, moves are cheap. This isn't really true. More precisely, it isn't any more or less true in Rust than in any other language. Regardless of language, when you move data, you must copy it, and you're paying the cost of that copy. What makes moves so useful in Rust is not that they're cheaper in time or space but because of the marvelous move invariant that is enforced by the compiler. Namely, that moved-from values cannot be referenced.

To see how important that is, compare with C++, which also allegedly supports move semantics. The modern C++ style makes heavy use of move semantics. But C++'s move semantics are broken in a way that makes them less efficient and more difficult to use safely, and that's because C++, like C, always allows code to reference any value that has a name. That means that moved-from values can be referenced, which means it's critical that moved-from memory not be left in an invalid state when interpreted under the invariants of its type. So the rule is that moved-from C++ objects must be left in a "valid but unspecified state". In practice, this translates into the move ctor/optor having to do work in the moved-from memory, zeroing pointers and whatnot, in order to ensure that what's left behind upholds the invariants of the type, and it means that C++ structs that support move-from must have some valid but not semantically-significant state they can be in.

What makes Rust's move semantics easier to work with, more efficient and safe is that there's no need to ensure that the moved-from memory is in any kind of valid state, because the compiler will not allow the moved-from memory to be accessed. Another way to think about it is that the moved-from memory no longer has any type, so no longer has to maintain any type invariants. It's fine to leave behind bit patterns that used to be pointers or whatever, because those bit patterns will never be used.

Coming from 35 years of C++ programming, this was something of a revelation to me when it hit me a few months ago. And it's the real meaning of "moves are cheap", which isn't a comment about time or space, but a comment about invariant maintenance.

Since Windows never supported this unusual 32/64-bit hybrid, it will have no impact on WINE.

It's actually kind of a cool idea, though. To someone like me who grew up on 8-bit and 16-bit architectures and is regularly taken aback at the size of data structures on 64-bit platforms -- 16 bytes just for a pointer and a length? -- being able to cut those down while still being able to run at full speed [*] on modern hardware sounds really useful.

[*] Assuming it's really full speed. I suspect there's some overhead.

Sure, if you want to run a system with hundreds of known vulnerabilities. Better keep it airgapped.