Gccrs is valuable for various reasons (bootstrapping, refining the spec, etc), but for the main purpose of "compiling to targets supported by gcc but not llvm", it's definitely not as promising as https://github.com/rust-lang/rustc_codegen_gcc. It's a rustc backend, at the same level as llvm or cranelift, it's much further along than gccrs (already available as a rustup component and can compile any rust code) and will not suffer from lagging behind rustc.
But OP has wider ambitions: the real niche targets are supported by neither gcc nor llvm. A rust-to-c transpiler that can adapt to weird C compilers should have a very wide reach.
From a "trusting trust" point of view, compiling rustc-translated-to-C with a C compiler (and comparing the result to normally-compiled rustc) is a valid demonstration, because we're again starting from code and can eliminate the possibility of a binary-resident compromise.
The actual issue here is that the translation was done using a rustc backend, and therefore an existing rustc binary which could be compromised and inject a "if (user=="wmanley") {...}" that isn't present in the original Rust code. If cilly was completely standalone (like mrustc), or if you had a rustc+cilly build you trusted, there would be no issue.
Yes, but all else being equal it is a higher bar in Rust than in Go. There are fewer things left for the human to check after a clean build+lint in Rust than in Go. The issue of over-engineered AI output is orthogonal to that.
The verbose error handling diluting the interesting parts is one thing, but the main issue is the weak type system. Having to read the callee's code to check if it deviates from `res xor err`, or if it mutates its arguments. Figuring out which interface that `func (o *Obj) ()` is implementing, if any. Dealing with documentation that is a wall of 100 disappointing oneliners all repeating the function name.
Rust is information-dense and takes longer to master, but it's not inherently cryptic, there's a finite amount of things to know. Memory management sometimes take a bit of thought to write, but it's straightforward to review, you can trust it's correct if it compiles, you just keep an eye out for optimizations.
> Gettext is functionally limited to source code being English (or alike). It handles all translation languages just fine, and competently so.
The *ngettext() family of functions take two strings (typically singular/plural) and rely on a language-wide expression to choose the variant (possibly more than 2 variants). There's no good reason for taking two strings, this should be handled in the language file, even without a DSL. Ngettext handling a single countable makes some corner-cases awkward, like gendering a group with possibly mixed-gender elements. The Plural-Forms expression not being per-message means that for example even in English "none/one/many foo" has to be handled in code, and that a language with only a rare 3rd plural has to pay the complexity for all cases.
Arguably, those are all nitpicks, Gettext is adequate for most projects. But quality translations get cumbersome very quickly.
> You can’t reasonably expect translators to write correct DSL expressions.
This feels demeaning. Translators regularly have to check the source code, and often write templates, they're well able for a DSL like MessageFormat's, especially when it's always the same expressions for their language. It saves a trip to the bugtracker to get developers to massage their code into something translatable. You can't reasonably expect a English-speaking developer armed with ngettext to know (and prepare their code for) the subtleties of Gaelic numerals.
It's not hard to make a case against gettext, despite its maturity and large ecosystem.
IMHO pluralization is a prime example, with an API that only cleanly handles the English case, requires the developer to be aware of translation gotchas, and honnestly confusing documentation and format. Compare that to MessageFormat's pluralization example (https://github.com/unicode-org/message-format-wg/blob/main/s...) which is very easy to understand and fully in the translator's hands.
But OP has wider ambitions: the real niche targets are supported by neither gcc nor llvm. A rust-to-c transpiler that can adapt to weird C compilers should have a very wide reach.