Lots of major companies like Microsoft and IBM also contribute to Linux, it doesn’t make them saints nor even necessarily compare to what they get for using the volunteer dev work inside Linux.

Most of those companies actually contribute to the kernel or to foundational software used on servers, but few contribute to the userspace for desktop consumers on the level that Valve does.

No, macros can see only the tokens you give them. They have no notion of the fact that crate::functions is a module, that PluginFunction is a trait and that functions_map is a variable. Not even the compiler may know those informations when the macro is expanded.

If you really really want to do this, you can use something like inventory. Note that inventory uses a special linker section to do this, which some consider a hack. This is also not supported on WASM if you want to target it.

CEO bonuses should be awarded 10 years after their mandate

Would it makes sense to provide a “share nothing” runtime implementation that can be injected at startup?

Isn’t this tokio::task::spawn_local?

The reputation loss is probably worse than whatever fine they end up paying

Time to pull a Meta/X and change name

Unfortunately some things will IMO always remain a natural monopoly. For example good luck trying to convince developers to write their apps for all those different operating systems.

Luckily Apple strictly controls the App Store and will never allow apps to abuse this, right? Right?

Your parent comment was mentioning the fact that their store still does not support user reviews, which should be one of the most basic features.

compile rust 0.7 in scala

Not sure if there was another rewrite, but AFAIK (and the article agrees with me) rustc was originally written in Ocaml

Epic chose not to try and compete with Steam on that front

Forget competing, they lack even the basics.

Have you actually measured a performance impact from RefCell checks?

Where’s the punch?

In the face of everyone expecting an upgrade

To be fair trees still use energy for doing this, but that energy is conveniently provided by the sun.

High or low level doesn’t matter. Mathematically it just makes more sense to use 0-based indexing https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

It’s mentioned in footnote 6:

As an example, to make this work I’m assuming some kind of “true deref” trait that indicates that Deref yields a reference that remains valid even as the value being deref’d moves from place to place. We need a trait much like this for other reasons too.

It would only work for references that are stable after the value they reference is moved. Think for example of a &str you get from a String.

Jokes on you, I subscribed to my mobile plan 8 years ago and I still pay 6€ for unlimited calls/sms and 30GB (Italy, Iliad)

Isn’t there already Box64/Box32? Not to mention most Linux software is already compiled for ARM thanks to being open source.

They used to, but they weren’t very good.

They tested the same strings on that implementation

The code they were looking at was used for writing the table, but they were testing the one that read it (which is instead correct).

though judging by the recent comments someone’s found something.

Yeah that’s me :)The translation using an associated const also works when the const block uses generic parameters. For example:

fn require_zst<T>() {
    const { assert!(std::mem::size_of::<T>() == 0) }
}

This can be written as:

fn require_zst<T>() {
    struct Foo<T>(PhantomData<T>);
    impl<T> Foo<T> {
        const FOO: () = assert!(std::mem::size_of::<T>() == 0);
    }
    Foo::<T>::FOO
}

However it cannot be written as:

fn require_zst<T>() {
    const FOO: () = assert!(std::mem::size_of::<T>() == 0);
    FOO
}

Because const FOO: () is an item, thus it is only lexically scoped (i.e. visible) inside require_zst, but does not inherit its generics (thus it cannot use T).

They tested the same strings on that implementation

The strings were the same, but not the implementation. They were testing the decoding of the strings, but the C function they were looking at was the one for encoding them. The decoding function was correct but what it read didn’t match the encoding one.

though judging by the recent comments someone’s found something.

Yeah, that’s me :)