ChrisSD

If you use highly unstable, nightly only, Rust features then experiencing breakage is almost a certainty. That's why they're highly unstable, nightly only, features.

But in that case they're Firefox "users", not Rust users. This distinction matters because the use of Rust is just a technical detail which ultimately the user doesn't really care about. They're benchmarking Firefox, not Rust.

Therefore the onus is on Firefox to provide a good user experience.

The only thing that bugged me enough to change it are the tiles on the new tab page. The new default is an absurd degree of nested padding so that the tile icons were tiny relative to the space given for each tile.

If each and every tile is 60% whitespace then there's too much whitespace for me.

For legacy reasons, any drive path that ends in a special name, such as `AUX` will be rewritten by Win32 as the NT path `\??\AUX`. This `AUX` is a special device, not a file on the filesystem.

So, for example, `C:\Users\ChrisSD\AUX` will be resolved to `\??\AUX`.

Even more surprisingly, any filename that starts with `aux.` will also be affected by this. E.g. `C:\Users\ChrisSD\aux.txt`.

Indeed. And Win32 even gives you a way to bypass the legacy behaviour. You can use `\\?\` paths, which get automatically translated to `\??\` NT paths but are otherwise left untouched.

Note that UTF-8 wasn't actually standardized until Unicode 2.0 in 1996. This was at the same time as the surrogate pairs needed for UTF-16. And UTF-8 didn't find its final form until 2003, which was around the time when it really started to gain legs.

However, as you say, by 1996 people were already using the older UCS-2 standard.

Tbh, I don't think you're the first person to think that but the trouble with making a "safer C" is that it's not C. Or to be more precise, it looks like C but isn't C compatible. This has ended up killing most attempts. Apparently nobody actually wants an almost-C language (alternatively, nobody has yet managed to successfully market one).

There seems to be an uncanny valley effect with C-like languages. The best you can do is have non-standard compiler extensions on top of ISO C.

This is why we have judges. They can look at the totality of the evidence to determine if Shell has actually complied.

Note that `from` and `try_from` are generally preferred to using `as`, where possible. This also allows casting between non-primitive types.

https://doc.rust-lang.org/std/convert/trait.TryFrom.html#exa...

I think the real problem stems from the mismatch between modern processors and the processors C was originally designed for.

C programmers want their code to be fast. Vanilla C no longer gives them the tools to do that on a modern processor. Either the language needs to be extended or the compiler needs to get more creative in interpreting the existing language. The latter is the least disruptive and it doesn't stop judicious use of the former.

So, in short, UB is what gives room for the compiler to be more creative without the programmer having to change their code. It wasn't a reading error, it was an opportunity the compiler devs enthusiastically embraced.

Interestingly, this was a mistake even the creators of UTF-8 wanted to make

> The 4, 5, and 6 byte sequences are only there for political reasons. I would prefer to delete these

Obviously 5 and 6 byte sequences are consigned to history but 4 byte sequences turned out to be useful for more than "political reasons".

http://doc.cat-v.org/bell_labs/utf-8_history

(scroll right to the bottom)

To be technical, by "character" I mean "user-perceived character" or (in Unicode speak) "extended grapheme cluster". This is the thing a user will think of as one character when looking at it on their screen.

A code point is the atomic unit of the abstract Unicode encoding. By "abstract" I mean it is not an actual text encoding you can write to a file.

A code unit is the atomic unit of an actual text encoding, such as UTF-8, UTF-16LE or UTF-32LE (and their BE equivalents).

---

So to put it together a "user-perceived character" is made up of one or more "code points". When implemented in an application, each "code point" is encoded using one or more "code units".

Not really. Unicode is a variable width abstract encoding; a single character can be made up of multiple code points.

For Unicode, 32-bit bytes would be an incredibly wasteful in memory encoding.

Validating should be pretty trivial. Explicitly handling all cases would look something like this:

    #[inline]
    const fn is_valid_scalar(c: u32) -> bool {
        match c {
            0..=0xD7FF => true,
            0xD800..=0xDFFF => false, // surrogate pairs
            0xE000..=0x10FFFF => true,
            0x110000..=u32::MAX => false, // outside of Unicode range
        }
    }

But this could be reduced down to a simple if statement that tests for the invalid ranges.

Turn the gcc version up to 11.

I don't think Rust has been a "Mozilla-centric" organization in a long time. Or at least the Foundation has no bearing on it.

Very early on Rust was made independent of Mozilla. And since the layoffs it's hard to argue they had much indirect influence left even before the Foundation was started. Well, no more than other companies using Rust.

I think you're talking past each other.

To be clear, the noscript tag "disappears" when javascript is enabled in the browser. When javascript is disabled it behaves like any other tag and can be styled accordingly.

Extension can disable scripts selectively but in that case javascript is still considered enabled for the purposes of the noscript tag.

It's much simpler to develop complex libraries outside of the stdlib. And given Rust's strong stability guarantees, it can't stabilize any APIs until they're finalized anyway. So development of new APIs often happens outside the stdlib and then if a third party library proves itself and can commit to a completely stable API then it might be uplifted into the stdlib, so long as there's a very strong case to do so.

I should also add that most applications won't even be using the TCP/UDP primitives directly. They'll likely be using a third party library. Rust's stdlib is intentionally minimal and lacking a lot of higher level features that are practically necessary for many applications.

Implementing crypto is much much harder than simply providing abstractions over the OS' TCP/UDP APIs.

Far better to let the experts do it.

Your last paragraph is assuming they'd be interested in imposing their will upon us. They may simply not care. Meeting us may just be an interesting diversion or pure curiosity.

Or they may be reluctant to get involved but sympathetic enough to offer a select few technological advances, if we want them.

There are a lot of possibilities which don't result in full surrender or a fight to the death.

Huh? That was exactly my point.

But that's just playing with definitions. Rephrase it as "zero runtime cost abstraction" and you get back to the intended meaning.

Incidentally your first question is one that's very amenable to testing. When does the Rust compiler spend most of it's time? Is it at the checking stage?

sscache has pre-built binaries on their releases page. Or you can do:

    cargo install --no-default-features 

To avoid building support for all storage backends. You can then add back any backend you're actually using.

Nothing modern about it. This is basically the C philosophy in a nutshell. Assuming "indirection" means "pointer indirection".

Sorry, I can't speak confidently on this because I can't read Japanese (or Chinese or Korean). I can only report what I've been told by users.

Including language metadata with text was felt to be especially important for Japanese and Korean users. I was told the difference was like having "595 kg" displayed as "5P5 kg". That is, it's possible to decipher the intended meaning but it looks wrong and it takes a moment to work out what was meant. Depending on the language some glyphs can be mirror images, have extra strokes, strokes missing or in different places or at different angles.

Given the context, I think they simply mean that a-b is interpreted the same as a - b.

It can't be interpreted as a single identifier.

As far as I'm aware one problem is displaying text. Japanese readers generally need a Japanese font to correctly display Japanese text if it's Unicode. This becomes a problem when you potentially have text that can come from different languages. E.g. a Japanese font will display Chinese incorrectly.

On the web you can work around this using the lang attribute to tell the browser how text should be interpreted.

It's notable that, for example, traditional and simplified Chinese does not have this problem because they are encoded separately.

Another problem is missing characters. Some people have complained of not being able to write their own name. I'm not sure to what extent this has been solved through Unicode updates.

UTF-16 is a variable length encoding. As is UTF-32 for that matter. A single character can be made of multiple code points.

> I would want it to be implicit.

Then simply use the `lossy` function. Or create an alias to it if you don't like the name.

The standalone installer is quite old and frankly weird. You're meant to use `py -3` or something like that. I don't know why it works this way. Tbh I think the official store installer works much more sensibly.