Finally we can rewrite all the Rust in C. ;)
As long as we rewrite all the C++ in Rust first.
Starting by the compiler infrastructure rustc depends on.
crustc: entirety of `rustc`, translated to C
91–99 of 99 posts
Re: crustc: entirety of `rustc`, translated to C
#92Earlier quoted context omitted.
Wake me up when consoles officially support Rust. Until then there's no real way around C/C++ if you want to publish a real game to real consoles. But there's https://akaganite.com so it might become possible soon™
They don’t need to “officially support” Rust in order to ship code written with Rust. Just target the applicable architecture and ABI. It’s a lot easier now that the ABI’s are mostly standard now too. Source: I wrote a compiler and runtime that ran .NET code (AoT compiled with LLVM) on PS3/Xbox360/Wii and shipped a few games with it.
As does Capcom with .NET and others.
Still it is a matter of sinergy and culture sharing across studios, hence why despite gains achieved by engines like Unity, the huge success made by Minecraft, or Android owning a big chunk of casual mobile games market, most studios end up using C, C++ and the engines that get tier 1 support from platform owners.
The culture in the games industry has always been that IP is what matters, the pain points getting it out there not only are secondary, they are also proudly used at some random GDC talk.
Re: crustc: entirety of `rustc`, translated to C
#93Earlier quoted context omitted.
Wake me up when consoles officially support Rust. Until then there's no real way around C/C++ if you want to publish a real game to real consoles. But there's https://akaganite.com so it might become possible soon™
They don’t need to “officially support” Rust in order to ship code written with Rust. Just target the applicable architecture and ABI. It’s a lot easier now that the ABI’s are mostly standard now too. Source: I wrote a compiler and runtime that ran .NET code (AoT compiled with LLVM) on PS3/Xbox360/Wii and shipped a few games with it.
Then why aren't there any public statements about games written in Rust being officially published on consoles? I know that it's technically possible but that does not help you when Nintendo, Sony or Microsoft just say "no" to you because you misuse their toolchains.
Re: crustc: entirety of `rustc`, translated to C
#94Earlier quoted context omitted.
They don’t need to “officially support” Rust in order to ship code written with Rust. Just target the applicable architecture and ABI. It’s a lot easier now that the ABI’s are mostly standard now too. Source: I wrote a compiler and runtime that ran .NET code (AoT compiled with LLVM) on PS3/Xbox360/Wii and shipped a few games with it.
Then why aren't there any public statements about games written in Rust being officially published on consoles? I know that it's technically possible but that does not help you when Nintendo, Sony or Microsoft just say "no" to you because you misuse their toolchains.
Who did they say no to?
Re: crustc: entirety of `rustc`, translated to C
#95Earlier quoted context omitted.
FWIW, Rust can also do a lot of things that do not easily map to C (at least standard C) constructs. For example: - You can compare any two pointers, while in C they must point to the same allocation. This is possible to solve by converting to integers first. - Signed integer overflow is UB in C, defined to wrap/panic in Rust. - Type-based alias analysis is a big one, does not exist in Rust.
> You can compare any two pointers, while in C they must point to the same allocation. This is possible to solve by converting to integers first. Indeed specifically Rust defines that pointer comparisons are done by address, whereas C doesn't specify what the rules are exactly. This gets sticky if the pointer was invalidated (e.g. you free'd the memory it was pointing at). Rust says - as you might expect - that you c…
It makes a big difference if you want to translate Rust to C. TBAA means you cannot translate a Rust struct to a C struct if you want to stay in standards-compliant C.
Re: crustc: entirety of `rustc`, translated to C
#96Earlier quoted context omitted.
Then why aren't there any public statements about games written in Rust being officially published on consoles? I know that it's technically possible but that does not help you when Nintendo, Sony or Microsoft just say "no" to you because you misuse their toolchains.
Who did they say no to?
Nice try Nintendo/Sony/Microsoft lawyer :)
Re: crustc: entirety of `rustc`, translated to C
#97Earlier quoted context omitted.
> You can compare any two pointers, while in C they must point to the same allocation. This is possible to solve by converting to integers first. Indeed specifically Rust defines that pointer comparisons are done by address, whereas C doesn't specify what the rules are exactly. This gets sticky if the pointer was invalidated (e.g. you free'd the memory it was pointing at). Rust says - as you might expect - that you c…
It makes a big difference if you want to translate Rust to C. TBAA means you cannot translate a Rust struct to a C struct if you want to stay in standards-compliant C.
Can you say more, maybe with an example of what goes wrong? I can't picture this in my head, when I picture translating some struct it feels like this works just fine, clearly I am missing something from what you're imagining.
Re: crustc: entirety of `rustc`, translated to C
#98Earlier quoted context omitted.
It makes a big difference if you want to translate Rust to C. TBAA means you cannot translate a Rust struct to a C struct if you want to stay in standards-compliant C.
Can you say more, maybe with an example of what goes wrong? I can't picture this in my head, when I picture translating some struct it feels like this works just fine, clearly I am missing something from what you're imagining.
E.g. you cannot translate `#[repr(C)] struct Foo { v: i32, u: i32 }` to `typedef struct { int32_t v; int32_t u; } Foo;` because in Rust it's entirely valid to take a `&Foo` and view it as `&[i32; 2]`, while in C this is UB.
Re: crustc: entirety of `rustc`, translated to C
#99Earlier quoted context omitted.
Can you say more, maybe with an example of what goes wrong? I can't picture this in my head, when I picture translating some struct it feels like this works just fine, clearly I am missing something from what you're imagining.
E.g. you cannot translate `#[repr(C)] struct Foo { v: i32, u: i32 }` to `typedef struct { int32_t v; int32_t u; } Foo;` because in Rust it's entirely valid to take a `&Foo` and view it as `&[i32; 2]`, while in C this is UB.
Isn't the alignment for the struct and the array the same, because it is determined by the inner type?