Google's OpenSK Offers An Open-Source Rust-Written Security Key Implementation

[xinorom]

Examples? Rust is advancing rapidly on that front and, even if that weren't the case, if you don't give examples, I can't point you to either the instructions that you missed because they really do still need better documentation or the issue tracker entry keeping track of requests to add them.

The most glaring one is the ABI problem. Rust doesn't even have a defined ABI, let alone a stable ABI.

If you read between the lines of this comment and also this comment, I think it's fair to assume that Rust will not have any ABI stability for a very long time, if ever. If you don't understand why that's a showstopper for many use cases then you're probably out of your depth.

80% of software can afford to pay the overheads of garbage collection, in exchange for a vastly simpler and safer programming experience. The remaining 20% is typically low-level, performance-sensitive stuff. Rust's sweet spot and main niche should lie in that 20% (since despite being "safe", it's most definitely not simple) -- but not having any ABI stability completely and utterly gimps it for most of those use cases.

It's competing with language where ABI stability is absolutely rock solid and the best they can come up with is "maybe we'll define an ABI in a few years -- but probably not". It's fair enough if that suits their own use cases, but lets not delude ourselves into thinking it's even remotely as general purpose as C.

Also:

• It produces comically bloated binaries.
• All standard library functions panic on allocation failure (!!).
• The rustc command-line interface is considered "unstable" and can change at any time, so the only reliable build system is Cargo (which you're basically forced to use).
• The compiler is SLOW. Like, even slower than heavily templated C++.
• The Node.js-style "micro-dependency" mindset that pervades the ecosystem is wrong and braindead.
• Did I mention that THERE'S NO ABI STABILITY WHATSOEVER?
• It's been demonstrated that developers will use "unsafe" to escape the checker and then vehemently try to gaslight people who point out the bugs. Even developers of widely used, high profile projects. As nice as checked lifetimes are, there's no silver bullet for stupidity.

[ssokolow]

The most glaring one is lack of a defined ABI, let alone any ABI stability guarantees.

A fair argument, but bear in mind that Rust is quite young. Also, there's currently mutterings in the C++ standardization community about the current "not ABI stable, but we've allowed people to act as if we are for too long" state of things.

If you read between the lines of this comment, I think it's fair to assume that Rust will not have any ABI stability for a very long time, if ever. If you don't understand why that's a showstopper for many use cases then you're simply out of your depth.

I do understand why that's a showstopper for many use cases, and discussion is ongoing in the Rust community for ways to support more use-cases without prematurely freezing in a specific ABI.

Also, I think that, aside from C, Swift is the only language that is even trying to achieve an intentionally stable ABI at the moment.

(Bear in mind that things like the Itanium C++ ABI don't specify enough of the library-side details to guarantee ABI stability.)

Rust's biggest problem with regard to ABI stabilization is generics, a problem equivalent to C++'s own history of troubles regarding the intersections of templates and stable ABIs.

As for plugins and other things you'd want to dlopen, one community member has already come up with a mildly clever workaround which involves using Rust's procedural macro system (ie. compile-time code execution) to do ABI-stable Rust-to-Rust calls via the C ABI support without having to manually write all the marshalling code.

On the compiler side, there's also a semi-relevant experiment in progress around using WebAssembly as a way to distribute procedural macros in a precompiled but platform-independent form to speed up compilation.

90% of all software can afford to pay the overheads of (tracing) garbage collection, in exchange for a vastly simpler and safer programming experience. The remaining 10% is typically low-level libraries (or large, monolithic apps that incorporate such libraries). That means Rust's sweet spot and main niche ought to be writing low-level library code -- but not having any ABI stability completely gimps it for that use case. So that just leaves big, monolithic apps (e.g. Firefox).

Actually, from what I've seen, Rust's biggest appeal comes from three things you're not touching on:

1. Consistent performance. (This is what I tend to see most in articles like that Discord one that was linked. Companies like Discord rewriting their services in Rust so they don't have to provision CPU or RAM slack to allow performance to remain steady during the GC spikes or companies like Tilde, who rewrote their Skylight monitoring agent for Ruby web apps in Rust so it would impose a consistent resource demand on their customers.)
2. The ability to encode domain rules into the type system for strong compile-time guarantees. (This is why I use it. I came from Python and was perfectly happy with its near-worst-in-class performance for my tasks but got fed up with how much energy I have to pour in to verify correct function using unit tests and aftermarket type checkers and the like.)
3. The ability to move the hot portions of a Python/Ruby/Node.js/etc. codebase into something faster without requiring someone who's spent the blood, sweat, and tears to become skilled at safely writing C or C++.

What a surprise that Mozilla would design a language tailored almost exclusively to their own use and then try to shill it as a general purpose language.

That's such a loaded and vaguely-defined statement that I'd spend far too much time addressing every possible interpretation, so I won't bother wearing myself out to probably no benefit.

90% of projects would be better off done in a simpler (if less performant) language and another 9% need features that Rust doesn't offer.

[citation needed] for those percentages.

It also produces comically bloated binaries.

Please compare apples to apples.

$ touch *.c *.cpp
$ make hello-c CFLAGS='-Os -flto -Wl,--gc-sections -static -s'
cc -Os -flto -Wl,--gc-sections -static hello-c.c -o hello-c
$ make hello-cpp CXXFLAGS='-Os -flto -Wl,--gc-sections -static -static-libstdc++ -s'
g++ -Os -flto -Wl,--gc-sections -static -static-libstdc++ hello-cpp.cpp -o hello-cpp
$ ls -al hello-c hello-cpp
-rwxrwxr-x 1 lifthrasiir 758704 May 31 20:50 hello-c*
-rwxrwxr-x 1 lifthrasiir 1127784 May 31 20:50 hello-cpp*

C and especially C++ (which is more feature-comparable to Rust) perform significantly worse than Rust in comparable configurations.

[bug77]

The most glaring one is the ABI problem. Rust doesn't even have a defined ABI, let alone a stable ABI.

Which languages do have a stable ABI? Is everything not having an ABI rubbish in your opinion?

[xinorom]

Which languages do have a stable ABI?

C, C++, Swift and a few others have a well defined ABI, which allows forward compatibility if you follow a certain set of rules.

Is everything not having an ABI rubbish in your opinion?

No. Far from it. For many languages, ABI is not even relevant at all. I use several of them myself when performance is not a big issue.

But for a language that's trying to position itself as being "for systems programming" and competing directly with C, I'd say such claims are quite rubbish if they don't even have a defined ABI.

OpenBSD recently stopped updating non-LTS Firefox packages specifically because of issues caused by Rust. Those kind of problems will only get worse as more and more foolish people write open source software in Rust and expect distros to package it.

[bug77]

C, C++, Swift and a few others have a well defined ABI, which allows forward compatibility if you follow a certain set of rules.

I don't know, I consider the lack of forward compatibility a plus. It promotes open source by the way of pushing people to distribute source code instead of binaries.

[ssokolow]

[...]

Since I don't want to edit my previous reply and risk getting it auto-Unapproved again, here's an example link for a real-world case of a company (Deliveroo) using Rust's FFI support to incrementally migrate Ruby code to Rust.

As for the rest of your message, which was added after my message was already posted and locked for being auto-Unapproved:

All standard library functions panic on allocation failure (!!).

They're working on it. Rust 1.0 was intended as a "minimum viable product", not the language's final form.

There's a working group that's putting together an allocator API and there are already experimental APIs available in nightly builds of the compiler to solicit feedback.

The rustc command-line interface is considered "unstable" and can change at any time, so the only reliable build system is Cargo (which you're basically forced to use).

You misunderstand the roles of the commands. Not all languages even allow attempts to invoke compilation of individual files independently. to use Git terminology, "cargo" is the porcelain and "rustc" is the plumbing. How often do you use Git's plumbing commands like ls-remote and rev-parse?

rustc is exposed for two reasons:

* As a tool for debugging problems with complex build.rs scripting.
* As a build system equivalent to the unstable language features that can be opted into in nightly builds of the compiler. (ie. As a way to prototype experimental additions to Cargo.)

It might have made more sense to call Cargo "rustc" and call "rustc" something like $PREFIX/libexec/rust-build-file.

Also, they're actively working with people who need to support integrating cargo into other build systems.

Are you really arguing that Mozilla made Rust over-focused on their own needs in one moment, then saying that they don't care about integrating into a larger build system the next?

The compiler is SLOW. Like, even slower than heavily templated C++.

I'm going to need a citation on this. There's been a lot of progress made in the last few years (and there's still a strong focus on making more) and I want to be sure you're not working from stale information.

They're even working on a whole new backend for rustc based on their in-development Cranelift code generator rather than LLVM so that they can speed up debug builds beyond what is easy to do with the LLVM backend.

The Node.js-style "micro-dependency" mindset that pervades the ecosystem is wrong and braindead.

I'll need something a little more empirical than that. I could easily argue that the "throw everything including the kitchen sink in a big pile because we have no dependency management" approach used in C and C++ is wrong and braindead with just as much authority.

(That which can be asserted without evidence, can be dismissed without evidence -- Christopher Hitchens)

...and, before you point to left-pad, note that Rust's package system specifically disallows deleting packages. (You can "yank" them, but they'll still be available as dependencies for existing projects to download.)

Also, the Rust ecosystem is developing tooling to help with the proliferation of packages. See things like cargo-geiger and cargo-crev.

Did I mention that THERE'S NO ABI STABILITY WHATSOEVER?

See my previous response.

It's been demonstrated that developers will use "unsafe" to escape the checker and then vehemently try to gaslight people who point out the bugs. Even developers of widely used, high profile projects. As nice as checked lifetimes are, there's no silver bullet for stupidity.

Yes. Bad developers show up in any ecosystem. Here's an example in C that's used as the basis for Samsung's Tizen.

One data point does not a trend make, so what's your point?

The Rust ecosystem got upset three times he tried to get away with it without clearly advertising Actix as disagreeing with Rust standard practice on proper use of the unsafe construct and, the third time (the time he tried to gaslight people), he ragequit.

See also my previous mention of cargo-geiger and cargo-crev.

[xinorom]

I don't know, I consider the lack of forward compatibility a plus. It promotes open source by the way of pushing people to distribute source code instead of binaries.

That's a completely separate issue and barely relevant at all.

What ABI stability allows distros to do is update a single library packages (e.g. with a security fix) without needing to rebuild each and every dependant package. Users of that distro then benefit by getting a single package update, instead of dozens or hundreds of pointless extra updates. Some libraries have literally 1000s of indirect dependants.

Honestly, it's completely obvious at this point that you are way out of your depth. Just stop trying to counter with irrelevant points and go do some reading.

[xinorom]

here's an example link for a real-world case of a company (Deliveroo) using Rust's FFI support to incrementally migrate Ruby code to Rust.

Like I've already said. I think Rust as a language is mostly very nice. It's no surprise at all that commercial companies are using it. My point about ABI stability mostly affects the open source world -- especially OS distros.

The overwhelming majority of distro packages are currently written in C, C++ or some dynamic language where ABI is a non-concern. Distros benefit massively from being able to update a single library package with a security fix without the need to also update 5000 dependant packages. Not only do they save countless CPU hours on build servers, but end users only have 1 package to update instead of whatever subset of the other 5000 they happen to have installed.

As a counterpoint to this, Haskell is another language with no ABI stability. I have exactly 2 Haskell programs installed via my distro package manager (Shellcheck and Pandoc), which each pull in several dozen Haskell libraries. There was a time when easily 60+% of my package updates were coming from the huge amount of rebuild churn caused by just those 2 main packages. This is less of an issue for "stable" (as opposed to rolling-release) distros, but it's still a problem.

They're working on it. Rust 1.0 was intended as a "minimum viable product", not the language's final form.

I'm willing to bet money that Rust will never have any kind of generally useful ABI stability. It's very obvious from reading the issue threads and blog posts from various core Rust developers.

There's a working group that's putting together an allocator API and there are already experimental APIs available in nightly builds of the compiler to solicit feedback.

Great. Another useful language feature. We're still stuck with a half-baked toolchain though, no matter how many features they add to the language.

How often do you use Git's plumbing commands like ls-remote and rev-parse?

Very often.

Also, they're actively working with people who need to support integrating cargo into other build systems.

OK, wake me up when it's done.

Yes. Bad developers show up in any ecosystem. Here's an example in C that's used as the basis for Samsung's Tizen.

No shit. I'm well aware that there are tons of terrible C developers out there. That's not a counter point at all.

The point is, those same people will eventually make their way into the Rust ecosystem and the same stupidity that causes most buffer overflows and use-after-frees in C will then become "unsafe { fuck_it_well_do_it_live(); }" in Rust.

Rustbots want people to believe the language itself helps to head off stupidity, but it doesn't do so to nearly the same degree that they naively want to believe. The Rust community at the moment is mostly early adopters and experts. If it ever becomes mainstream, the deluge of morons will rapidly make them question the premises of their original hype and selling points. At some point, it all comes down to the programmer. A tool is only as reliable as the person using it.

One data point does not a trend make, so what's your point?

My point is that the oft trotted out selling point of "Rust programs are safer because unsafe code has to be marked" is very oversold. The borrow checker is definitely a very useful tool, but you can't infer much about the quality of a piece of software just from it being "written in Rust". It could still have 10,000 logic bugs in there.

The other point I've heard quite a few times from Rustbots is "if it compiles, it's probably correct". That's just so laughable, I don't think I even need to say anything about that one.

[bug77]

That's a completely separate issue and barely relevant at all.

What ABI stability allows distros to do is update a single library packages (e.g. with a security fix) without needing to rebuild each and every dependant package. Users of that distro then benefit by getting a single package update, instead of dozens or hundreds of pointless extra updates. Some libraries have literally 1000s of indirect dependants.

Honestly, it's completely obvious at this point that you are way out of your depth. Just stop trying to counter with irrelevant points and go do some reading.

Well, to many things seem to be "completely obvious" to you, so I guess there's no point trying to debate anymore. A good day to you, sir.

[ssokolow]

Like I've already said. I think Rust as a language is mostly very nice. It's no surprise at all that commercial companies are using it. My point about ABI stability mostly affects the open source world -- especially OS distros.

The overwhelming majority of distro packages are currently written in C, C++ or some dynamic language where ABI is a non-concern. Distros benefit massively from being able to update a single library package with a security fix without the need to also update 5000 dependant packages. Not only do they save countless CPU hours on build servers, but end users only have 1 package to update instead of whatever subset of the other 5000 they happen to have installed.

As a counterpoint to this, Haskell is another language with no ABI stability. I have exactly 2 Haskell programs installed via my distro package manager (Shellcheck and Pandoc), which each pull in several dozen Haskell libraries. There was a time when easily 60+% of my package updates were coming from the huge amount of rebuild churn caused by just those 2 main packages. This is less of an issue for "stable" (as opposed to rolling-release) distros, but it's still a problem.

No argument. I've kept my eye on that ever since distros started wanting to incorporate Rust packages. I think we just have different outlooks on how things will unfold.

I'm willing to bet money that Rust will never have any kind of generally useful ABI stability. It's very obvious from reading the issue threads and blog posts from various core Rust developers.

I'm subscribed to /r/rust/ through RSS (ugh. Lost /r/playrust/ users who get into the RSS feed before their posts can be deleted), as well as keeping an eye on various things like This Week in Rust and I don't get that impression.

It's more that a lot of Rust's "ABI" at the moment is basically "whatever the compiler winds up doing as long as it satisfies the build test suite" and there's a lot of inconsistency surrounding what a Rust ABI would even mean, so they're following their usual "don't rush things and stabilize something with glaring flaws" approach to solving the problem.

Great. Another useful language feature. We're still stuck with a half-baked toolchain though, no matter how many features they add to the language.

The language teams and the different toolchain teams are disjoint. For example, rustc people are working on polonius (the next iteration of the borrow checker, which rejects even fewer valid idioms as "not provably safe") at the same time that cargo, rustfmt, etc. people are working on other things. Give it time.

Heck, because RLS embodies quite a few hacks to get IDE support quickly (eg. the RLS approach to partial and/or forgiving parsing is quite shonky), there's an alternative project named rust-analyzer which is on the way to being its properly designed successor while it serves current needs.

Very often.

Then you're, by definition, a niche git user. Same thing with Rust. As a young project fighting to gain market share, they try to prioritize the improvements that affect the largest swathes of users.

OK, wake me up when it's done.

That's not my job but I'm sure that, once it's done, you'll hear of it sooner or later.

No shit. I'm well aware that there are tons of terrible C developers out there. That's not a counter point at all.

The point is, those same people will eventually make their way into the Rust ecosystem and the same stupidity that causes most buffer overflows and use-after-frees in C will then become "unsafe { fuck_it_well_do_it_live(); }" in Rust.

Rustbots want people to believe the language itself helps to head off stupidity, but it doesn't do so to nearly the same degree that they naively want to believe. The Rust community at the moment is mostly early adopters and experts. If it ever becomes mainstream, the deluge of morons will rapidly make them question the premises of their original hype and selling points. At some point, it all comes down to the programmer. A tool is only as reliable as the person using it.

My point is that the oft trotted out selling point of "Rust programs are safer because unsafe code has to be marked" is very oversold. The borrow checker is definitely a very useful tool, but you can't infer much about the quality of a piece of software just from it being "written in Rust". It could still have 10,000 logic bugs in there.

That is a point of contention. (Since the beginning, there have been people pushing for crates.io to badge any crate which depends on unsafe code outside the standard library and pushback against that because it would stigmatize the unsafe keyword) .

The current state of things is the cargo-geiger tool I mentioned, which allows you to do your own audits, err, stigmatize unsafe privately, the cargo-crev tool which people are trying to build a distributed, Web of Trust-based dependency auditing system around, and projects like safety-dance where volunteers are auditing popular crates and contributing patches to minimize the use of unsafe without statistically significant drops in performance.

The other point I've heard quite a few times from Rustbots is "if it compiles, it's probably correct". That's just so laughable, I don't think I even need to say anything about that one.

You're taking that out of context. The context it's used in is "Compared to the C/C++/Python/Ruby/JavaScript/etc. I used to write these things in, I spend far less time chasing down frustrating runtime bugs in Rust. I'm surprised how often it is that, when I get my code to compile, it works as I intended the first time".