Why? Crypto in a memory-managed language is not just a bad idea but a horrifically bad idea because you expose yourself to every single bug in the runtime's memory management.
A lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls.
Rust can't target the same platforms C can. Rust is also (generally) more memory intensive than C for similar programs. This makes its use in embedded situations a non-starter (at least for now).
> Rust can't target the same platforms C can.
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]
> [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.
> https://benchmarksgame.alioth.debian.org/u64q/compare.php?la....
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".
> There are so many variables here that using the benchmarks game will not give you an accurate picture.
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.