Comment by rdpintqogeogsaa | Hacker News Reader

Comment by rdpintqogeogsaa | Hacker News Reader

Parent Full thread

rdpintqogeogsaa

I understand why people are angry and that portability is a worthwhile goal in many scenarios. I also understand that Rust is far from the ubiquity that C has achieved. I also understand that people feel betrayed by a library they depended on drastically altering its dependency structure.

On the other hand, there's a group of developers with limited resources and perceived moral high ground in terms of security that fits right in with the trends that I've observed in the cryptography community.

Both sides have valid arguments. Which sides of this split you fall on depends on your personal values and immediate needs.

Ultimately, the whole debate is fruitless bickering because you cannot reconcile differences in values. This doesn't just apply to the Python "cryptography" library, but also other places where a switch to Rust was enforced by upstream.

The alternative is to define "closer" portability (iOS, Android, Windows, macOS, desktop/server Linux) and "wider" portability (BSDs, illumos, QNX, custom embedded OSes, architectures that aren't x86_64 and ARM). Then make it clear from the get-go which one of these you're aiming for.

The people that are angry about it should feel free to take the last source code that worked for them and fork it and maintain it.

There is a happy middle ground[1]. Someone could build a Rust->C compiler and then packages meant for releases could be bundled with pre-compiled C sources.

[1] of course the question of who is responsible for building such a compiler potentially becomes a new value-based conflict.

The author correctly, IMO, points out that this is not possible currently because there's no Rust Specification, so the exact behaviour of such a compiler cannot even be described.

I was surprised by how informal the Rust language semantics are when I was trying to find out how the `?` operator works, exactly. There's no official description anywhere except for an RFC which was created before the feature was introduced, but from which the feature has diverged significantly since it was added to the language!

The Rust Book, normally assumed to be the "true" description of the language, is quite incomplete in places as it's not a formal specification. For example, the section about `?` does not mention that different error types will be auto-converted if there's a `From` implementation between them. This is quite important information missing from the documentation. Just from reading that page, you would be writing really verbose type conversions yourself, everywhere.

But the Rust Book does mention this elsewhere[2] (if you're careful enough reading the first link, you can see that it says `?` is "more or less" equivalent to `try!`, and reading the docs for `try!` you could actually find out what it does, and hope they didn't change anything when implementing `?` - but that's a quite a lot of assumptions). You just need to read the whole book, or at least be lucky enough to look at all the right places, to make sure you understand how a language feature works, precisely.

[1] https://doc.rust-lang.org/edition-guide/rust-2018/error-hand...

[2] https://doc.rust-lang.org/book/ch09-02-recoverable-errors-wi...

Of course it’s currently possible, even in the lack of a formal Rust specification. One particularly obvious implementation is a C backend for LLVM.

Compiling to C, althought a common approach used by many that want to save the effort to implement a full backend, always has the issue that it might not be possible to express 1:1 the desired source language semantics in C, and some subtle bugs depending on which C compiler is used.

Can you give some examples of language semantics that cannot be expressed in C?

One I can think of is doing coroutine / stack swapping stuff. Though even that is not insurmountable if your sequential code is rendered into C in a “CPS” style.

Another related one is exotic manipulations of the instruction pointer beyond what goto/switch provide. This can be solved too, but inefficiently (put all jump-to-able lines of code in a big switch statement). GCC provides computed goto but that is not standard.

In either case, it’s worth pointing out that Rust does not do these types of things and it would be relatively straightforward for a machine to create a 100% semantically equivalent C program from a rust program.

Naively, I imagine it's hard to implement (efficient) overflow semantics for integers in C, without any UB. Rust provides operators for [wrapping overflow](https://doc.rust-lang.org/nightly/std/primitive.isize.html#m...), [saturating overflow](https://doc.rust-lang.org/nightly/std/primitive.isize.html#m...), etc. You can't use UB because then the C compiler can miscompile your code.

Semantics of loops might also be tricky. In fact rust struggles with LLVM's optimizer already on some infinite loops because C++ and rust diverge in semantics there.

That’s actually trivial using unsigned arithmetic and two’s complement representation for signed integers, its also equally efficient[1]. Unsigned arithmetic is fully defined in c, including checking for overflow.

[1] gcc for example generates optimal code when doing checked addition: https://godbolt.org/z/9jnesx

But that's my point; how can you be sure the compiler will emit the right code instead of assuming that the addition does not overflow and then proceed on pruning the test, since overflow on signed integers is not defined?

You implement it by using unsigned arithmetic, then checking that the sign bit flipped. See https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/... .

It's a bit more subtle than that, but that is completely devoid of Undefined, Unspecified, and Implementation-Defined Behavior.

Were you looking for this?

https://doc.rust-lang.org/stable/reference/expressions/opera...

I mentioned that there are other places in the Book where this information is mentioned, but it's funny how the `?` is described in at least 3 places (your link plus my two other links), but the section you would expect most information about it, called "The ? operator for easier error handling" which is fully dedicated to explaining the operator, does not mention that fact.

My point, above all, is not tied to this specific example, by the way, hope you understand how an informal tutorial about the language does not replace a strict specification - and pointing out that such information is available somewhere if I look hard enough does not disprove anything.

> pointing out that such information is available somewhere if I look hard enough does not disprove anything.

I didn't look very hard, I went to the language reference and searched for "?" in the Tokens section.

Reply on news.ycombinator.com