I keep seeing this argument, but nobody actually names those platforms. Name one platform you need to run a TLS stack on that LLVM doesn't have support for.
> Rust is also (generally) more memory intensive than C for similar programs
[citation needed]
With all the usual disclaimers about the inaccuracy of benchmarks:
https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
As a side note, can you guarantee you are not allocating memory (calling malloc) with Rust? I know how to do it in C, but Rust has another layer of indirection.
> Name one platform you need to run a TLS stack on that LLVM doesn't have support for.
Have a look yourself:
$ llc --version # CPU architectures supported by LLVM
Of particular interest to me are the AVR ATMega line of microprocessors, popular in Arduino boards and IoT devices everywhere. I'd personally love to see more IoT communication secured with TLS.
I do see a github repo for providing a LLVM backend for AVR processors, but it's not part of the LLVM project, nor is it even passing its own test suite at the point I'm writing this.
There are so many variables here that using the benchmarks game will not give you an accurate picture. You may well just be benchmarking jemalloc vs. glibc's allocator. jemalloc is tuned for speed of allocation in threaded contexts (with e.g. TLABs), not minimum memory usage. If you want, you can use the system allocator with Rust; for the benchmarks game we use jemalloc since it's faster.
> I know how to do it in C, but Rust has another layer of indirection.
How? Any function you call from some other library can call malloc under the hood.
> $ llc --version # CPU architectures supported by LLVM
I know there are architectures out there that LLVM doesn't support, but that doesn't mean anything unless people actually need those architectures. Not having PDP-11 support (one of the architectures on that list) doesn't make Rust a "non-starter".
> I do see a github repo for providing a LLVM backend for AVR processors, but it's not part of the LLVM project, nor is it even passing its own test suite at the point I'm writing this.
AVR support is coming along well.
AVR isn't exactly a first-class citizen among commonly used projects like OpenSSL. The reason why AVR support is immature is that few people need it. Not having that support isn't enough to make Rust a "non-starter", any more than it makes OpenSSL a "non-starter".
Hence the comment "With all the usual disclaimers about the inaccuracy of benchmarks". But it still gives a good, practical starting point for discussions. You're welcome to provide a counter data set to further the discussion.
> Any function you call from some other library can call malloc under the hood.
We're discussing low level libraries which aren't really calling out to other libraries, allowing you to quite easily control your memory allocation. It's also fairly easy to grep for 'malloc' in a C codebase, or inspect a compiled library for the malloc syscall.
I took a few minutes and looked at the current state of Rust with memory allocation as well, and it certainly does seem possible to remain within the stack only, by avoiding Box, Vec, String, and the various reference counted containers. Great to see.
There do seem to be some lingering limitations with stack-based data primitives and generics, but it's nothing you couldn't work around if you wanted to.
> unless people actually need those architectures
Like ATMega? If an architecture is supported in modern versions of GCC, there's a good chance that it's needed by somebody. And that doesn't count the dozens of specialized C compilers for other non-standard architectures. Modern banks are still running Cobol on mainframes, after all, and microcontrollers are everywhere.
> AVR support is coming along well.
Mind pointing me at a reference on, say, LLVM's roadmap? I see a fairly constant level of activity on the avr-llvm github repo, but nothing that appears to state it's ready for inclusion in LLVM in any defined timeframe.
Also curious about MSP430 moving out of experimental, Microchip's PIC, the Intel 8051, Hitachi's SuperH...
> make Rust a "non-starter", any more than it makes OpenSSL a "non-starter".
Wait, you're comparing a programming language to a heavy duty crypto library? Quite the literal version of comparing apples and oranges. Or apples and an Orange Julius.
There are other plenty of other crypto libraries that are aimed at microprocessors that aren't OpenSSL; wolfSSL as an example.
Ultimately, with enough time and money, Rust is capable of competing with C for the embedded space, making a lot of embedded developers happy. But not in the forseeable future.
There is nothing you can do in C++ that you can't do in Rust as far as memory is concerned. The compiler backends are even identical! You can drop libstd if you want in Rust, which you probably would in the microcontroller use case. You can even translate C to Rust [1], which should result in virtually identical LLVM IR!
That's what's so frustrating about throwing out benchmarks game numbers: the languages are isomorphic, so you end up ultimately comparing things like jemalloc implementations.
> Like ATMega? If an architecture is supported in modern versions of GCC, there's a good chance that it's needed by somebody. And that doesn't count the dozens of specialized C compilers for other non-standard architectures. Modern banks are still running Cobol on mainframes, after all, and microcontrollers are everywhere.
Why is COBOL on mainframes relevant? We're talking about C++ here. (Anyway, if you want to bring up mainframes, IBM has a working SystemZ backend for LLVM.)
Talking about "microcontrollers" is too broad of a brush. A lot of microcontrollers are ARM (or MIPS, etc.). Rust runs just fine on those.
> Ultimately, with enough time and money, Rust is capable of competing with C for the embedded space, making a lot of embedded developers happy. But not in the forseeable future.
This is again way too strong of a statement, because we have people using Rust right now for embedded IoT use cases (including some at Mozilla!) It all depends on what you need. If LLVM supports your architecture (which is probably does) then great! If it doesn't, then let's talk about the specific architecture you need and what you need it for, rather than making blanket "Rust is a non-starter for embedded use" statements.
We're never going to get support for every architecture anyone can come up with that C has ever run on. But who cares? What matters is whether Rust runs on a platform you were seriously considering using Rust for. If it doesn't, then we can get that fixed; chances are if you want that architecture, someone else using LLVM does too.
https://tonyarcieri.com/would-rust-have-prevented-heartbleed...
MPC55xx
there's no proper support even in GCC and we need to work with expensive WindRiver compiler for this target.
personally I don't need TLS for my firmware, but someone might - as there's static without runtime alloc implementation available.
Google suggests that this is essentially PowerPC. Is that not true?
our e200z6 core has PowerPC ISA, but there's a difference in hardware floating point support (here it's done by SPE) and we also need VLE. First one you could somehow get working, but with the latter - no way, its support was dropped by mainline gcc even after the patches were proposed, since it complicates the other parts of PowerPC port and is needed only by few people like me with deep embedded stuff (source: https://gcc.gnu.org/ml/gcc/2013-03/msg00172.html).
As my sibling mentions, if LLVM can target it, then we can, but generally anything < 32 bits isn't gonna work at the moment. We're slowly getting support for some of that stuff.
There's a whole group dedicated to working on this: https://github.com/rust-embedded/
let's start from this
Obviously, being able to call malloc without a GC is a nice to have for TLS on embedded systems.
That said, I guess you'd have to be careful to avoid creating something like a NoSwapBox<Vec>, because the NoSwap property would only apply to the (ptr, capacity, length) triple of the vec, and not to its actual heap allocation that you probably care about. Maybe the answer there is something like requiring that the contents of NoSwapBox implement Copy, or some other way of saying "this is plain old data"? I don't know enough about the plans for custom allocators to say anything intelligent :p
(And yes, it would actually be nice to have reliable crypto on a micro-c.)
Also, when I say that BearSSL is written in C, it is partly a lie: some of it (especially X.509 certificate decoding, and handling of handshake messages) is done in T0, a new Forth-like language that I invented for the task (compiler is provided, and produces C code), specifically to have coroutines (incidentally, it means that most of that code read things byte by byte, with relatively few accesses to buffers, thus less potential buffer overflows).
Despite the horrors implied by a Forth syntax, this actually made writing the code easier. As a bonus, it turns out that T0-generated code is very compact, so I could pack more behaviour into less bytes.