fluffything

I thought one of the main point of Firefox would be to not do this :D

I don't think they are talking about memory management here, but simple API design.

In C++ you can write:

    template <typename Animal>
    void roar(Animal animal) { ... }

and call it like this:

    roar(airplane); // How do Airplanes roar?

You can try to fix that with an "Animal" concept, but it turns out that if someone adds a roar method to a Vehicle, you can still:

   roar(truck); // Trucks can roar... but roar expected Animal

In Rust, these things just cannot happen. If you write:

    fn roar(animal: impl Animal); 

then trying to call it with anything that's not an animal will fail to compile.

That's a good thing, but maybe somebody did wanted to call roar with a truck, and now you have to invest time into more precisely thinking which types should roar actually take, which types constraints make sense defining, how you categorize types, etc.

In Rust thinking about these things costs time. In C++ it also costs time, usually more than Rust, because you have to go way out of your way to prevent mistakes like the above. In Go you don't have to think about these issues at all because the language does not allow you to do most of this (except for interfaces, but that's another story).

> It can block competing apps such as Spotify/Apple Music for example. One could argue the same for YouTube music vs Spotify.

No it cannot. That's anti-trust.

To be clear, the problem here is not that Apps can only be installed via the App Store on Apple devices. That is ok, and not very different form having, e.g., and "Installer" package format in your OS.

The problem here is how Apple is using its App Store to gain an unfair advantage.

In my experience, Rust compiles orders of magnitude faster than similar C++ code for initial compiles. For incremental compiles, Rust is infinitely faster. C++, even if you use Modules, needs to re-compile, re-instantiate, re-check all the templates all the time. I speculate that this alone is what probably is responsible for the largest difference in compile-times.

Comparing Rust with C here is hard. As others have mentioned, with C, you typically only use libraries that are installed in your system. Rust does not have a global system cache for libraries, and I don't think there is any package manager installing pre-compiled Rust libraries, so at least for the initial compiles, Rust needs to do much more work than C, for Rust dependencies at least. If your Rust project only depends on C libraries, then there is no work to be done of course.

For incremental compiles with C, it is hit or miss. If your C project is properly "modularized" (split into a lot of small enough TUs), then when you change a TU, C only needs to recompile that one TU. In our benchmarks, Rust is faster for that situation, and speculating, this is because the Rust compiler only recompiles the parts of a TU that actually changed.

In practice, however, Rust is much slower than C, because people do not write small Rust TUs, but absurdly huge ones, at least, by C standards. A Rust TU (crate) usually is mapped 1:1 to a C library, which often contains dozens or hundreds of TUs. Just the cost of testing what changed in a Rust crate is often larger than the cost of blindly recompiling the C TU that has a newer timestamp.

If people would split Rust code like they do with C, then this wouldn't happen. But Rust people are too optimistic in that one day the compiler will be able to somehow auto-magically split a crate into multiple TUs as good or even better than what people do for C manually. And do that determination + the incremental compile faster than what takes a C compiler to blindly recompile a tiny amount of code.

From these products, most of them, since NVEnc doesn't really support many formats (AV1, VP9, Speex, ...).

None of the ones I know are. They are all proprietary.

I'm not sure they are for sale either (probably for the right price), since they sell these "as a service", which pays better. I also don't think these are on sale for "small" customers.

Most (all?) Linux distros (Debian, Arch, Ubuntu, Fedora, ...) use their packaged Rust and cargo to build other packages like Firefox, ripgrep, etc.

Which challenges are not showing up there ? There are packages, and they are usable to build other packages.

Sure, but which distro does not package Rust and use the packaged Rust to build Firefox ?

Debian, Ubuntu, Fedora, Arch, ... all do this.

In Germany, if your partner doesn't work, your income tax is essentially divided by 2 for taxation purposes, which is huge given that ~45% of your income will be paid in taxes otherwise, a big part of which are income taxes.

Also, charitable donations, which includes working for charities for free, as well as voluntary work, are tax deductible for the "tax entity", which if you are married you can choose to be your marriage.

So depending on what your partner does, and likes to do, if you are in a very high paying job, it might make more economic sense for your partner to "work for free" donating their work to a charity.

This essentially would mean that you get 100% of your income, free of taxes.

Example A: your salary 200k, your partner salary 50k. Combined taxes: 250k * 0.45 = 112k. Earnings: 250 - taxes = 138k.

Example B: your salary 200k, your partner exercises a 50k job for a charity for free. Taxes: 200*0.45/2 - 50k = -10k = 0k. Earnings 200k > 138k.

I'm not suggesting that your partner shouldn't work, only mentioning that if you are moving to Germany for a high-paying job, that is just one part of the equation. IANAL, nor a tax advisor, so I'd recommend you explore the options and evaluate the package "as a whole".

For a lot of people, being able to work for a charity for free for a couple of years can be much more rewarding than a 8-5 office job at a FAANG.

> not as long as people don't introduce Rust into the base system

If your base system uses Firefox or ripgrep, Rust is already there.

Reading WSBs, those buying Hertz right now know they are idiots, and do it anyway, knowing that they will probably lose all their money, but hoping that if they do not, they can buy a lambo.

If my software could afford a garbage collector, I would write it in Python or a JVM language, not in D.

My software that can afford a garbage collector typically doesn't need a high level of safety either. If it fails, I restarted, and if it gets compromised, so be it.

> D's GC isn't a Java or JavaScript or Go GC, it doesn't have overhead-inducing write barriers.

I wouldn't use D for any application. If my application requires high-performance and/or correctness, I'd use Rust or C++.

D buys you memory safety with a garbage collector, but it doesn't buy you thread safety, so from the safety POV, it is not enough. It also isn't free. If you disable it, you can't use most libraries. And if you enable it, you pay for a big runtime. Also the performance that D does buy you comes with the cost of being a language at the same level of complexity of C++.

Rust gets you much better safety than D, no run-time by default and all libraries support this, better meta-programming than D, etc. all at a lower complexity cost than D.

Sure D is better at prototyping than Rust, but Python and many other languages are much better at prototyping than D. If I need to write a prototype, I'll use python. And if I need to make my prototype fast, I'll just write that part in Rust and call it from python. Gives me the best of both worlds.

Picking D would mean picking something that's not bad but not great at anything either.

> After spending thirty days on the scope in late May and early June of 2020, the team of auditors considered the general code quality really good and can attest to a solid impression left consistently by all scope items. Naturally, this is partially thanks to the usage of Rust as the preferred language for the entire implementation of the rustls project.

> They think "people aren't going to stop renting cars"

Do they? Nobody buying this stock thinks Hertz is going to recover.

They think "I'm bored and buying this worthless stock is risky and fun".

That is valuable to some people, and hence why the stock price is up.

Hertz selling more shares to try to save the company is pretty dumb, because that is not what it share holders want.

Hertz new share holders want to see the company and stock burn as much people as possible in the most spectacular way possible. That's what Hertz has become.

> A funny thing is that if Hartz indeed issies new shares, it makes the game a lot less favorable for those gamblers...

These gamblers are irrational. They might double down, or manage to find new gamblers, or sell before this even happens. Nobody knows what will happen, and it doesn't really matter.

And that point is wrong, since there are some cloud providers using normal GPU cores for exactly this.

The codecs that NVEnc supports are just a few bunch, there is no real-time audio, no nothing.

All of this is implemented in CUDA, using normal CUDA implementations of audio and video codecs, and running on normal GPUs using normal GPU cores. In real time. Supporting thousands of audio and video channels concurrently.

Also, even for NVEnc and NVDec themselves, in some of the GPUs they do not use any specialized hardware and use normal GPU cores instead (e.g. see the older GM20x GPUs).

An off-the-shelf GPU can encode / decode thousands of channels of video and audio in real-time.

There are some cloud providers that offer this as a service, allowing you to have the end-points of, e.g., video calls to use different audio and video codecs.

This is quite useful, e.g., when some people join the call only using audio via a cell phone in a different country using a different audio standard (or a land line, etc.). Or when somebody joins the video call from laptop tethering from a phone on a train. Or for switching video codecs depending on whether somebody is sharing their desktop or using a webcam to record their face.

The client can picks the codecs that are the best fit for the current situation (content, bandwidth, latency, etc.) and a could server transcodes the video from everyone else in the meeting to their clients format.

glibc is not what I would use for statically linking

musl works just fine for that

> Is there any published rationale for the RISC-V instruction encoding?

Computer Organization and Design, RISC-V edition, goes into these. R-types have opcode = 0b0110011, SB (branch) types have opcode = 0b1100011, etc.

The lower bits also have extra meanings (16 bit, 48 bit, etc. instruction).

This allows hardware to just branch on these bits in sub-groups. The hardware pipeline for 16 bit is different than that of 48 bit, and the 48-bit is probably even optional.

Really? Citation needed.

Compilers are programmed by humans. You are claiming that somehow compilers have learned to produce better assembly than the humans that programmed them.

I am a compiler writer, and know many compiler writers. I have yet to find one that would stand by your claim. When I look at the output of LLVM or GCC, I am ashamed.

I wish I had more time to make LLVM much better, but actually, 99% of my time is spent in fixing bugs filled by users that are neither compiler writers nor assembly programmers, and they too realized how bad the machine code emitted by these tools is.

So sure, a compiler emits better assembly than a human that hasn't learn assembly programming. It also emits better assembly than all humans that do not know how to program.

But no, it does not produce _by far_ better assembly than any programmer that actually cares about machine code enough to just take a look at it and check it.

> MISRA C is a subset of C / set of rules that is used in the auto industry, and supported by many tools.

That's true, and I know you are not claiming this, but MISRA C is neither memory nor thread safe, which is what we are talking about here.

Writing MISRA C code with data-races is trivial, and no "linter" for it finds those.

> C and Ada variations have done so for many years, way before Rust was a thing.

Not giving any concrete examples is just proving my point.

Which C variations are both thread and memory safe? Which Ada variations are both thread and memory safe ?

AFAIK, such variations do not exists, and people claiming that they do on the internet and then failing to provide a simple link when requested multiple times by others to do so just seems to confirm that.

Because people like you, who suggest that there are alternatives, fail to mention them.

Which other languages close to C, without a run-time, and without a garbage collector, give you proven memory and thread safety?

Not C, not C++, not D, not Nim, not Go, not Swift, not Ada, ...

The 3 big fabs that you'd like to use are fully booked until 2023 or so. So you kind of forgot the "wait 4 years" part.

Why cite another source:

* this article acknowledes that while open-source hardware requires an open-source ISA, this requirement is not sufficient

* this article mentions open-source hardware that implements the open-source RISC-V ISA, and the type of applications and research that this hardware is used for (e.g. eliminating Spectre-like timing attacks). It also mentions how such research is pretty much impossible to publish for non-open-source hardware using non-open-source ISAs.

Because compilers almost never write better code than humans ?

There are literally tens of thousands of bugs in the GCC and LLVM/Clang bug trackers about that.

I don't remember the last time I read some compiler-generated asm and thought "wow, that's great code".

Just take any operating systems course and try to implement your own.

Or try to program a micro-controler "hello world" that actuates an LED ?

The problem is not whether its bad or not, but rather, having to learn a completely-different second syntax for one architecture.

Most Rust code is quite portable, targeting ARM, x86, MIPS, PPC, WASM, Sparc, s390x, riscv, ... That means, that for many snippets of inline assembly, you might encounter ~8 of them, one for each architecture, all using different syntaxes.

Intel syntax is quite similar to that of other popular architectures `op dst, args...`.

Adding another second syntax for x86 just doesn't add that much value IMO, and adds quite a bit of cost: now everybody dealing with x86 assembly needs to learn 2 syntaxes... and everybody dealing with portable code now needs to be at least able to read 2 syntaxes for x86... Without talking about the cost of implementing a second syntax in the compiler, etc.

If you prefer AT&T, you can always write a proc macro that translates it to Intel, and use that in your projects.

If I ever need to deal with such code, I'd just expand the macro to read the actual Intel syntax, modify that, and either fork the project, or submit a patch with a fix using Intel syntax.

Notice that you can quite easily implement a Rust proc macro that takes whatever DSL you want to use for inline assembly, and generates an `asm!` expression from it.

So better syntaxes are possible, as long as they can be built on top of the proposed inline-assembly feature.

They can, however, just be implemented as normal Rust libraries, and do not need to be part of the compiler.

> I don't have to specify clobber registers,

So how does the compiler know that these are clobbered then ?