> 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.
> 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.
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.
I don't mean "isomorphic" in that every Rust feature has a corresponding C feature. I mean that you can replicate every runtime C feature in Rust, and vice versa. The advantage of Rust is that you get a lot more safety guarantees and ergonomic features out of the compiler than you would with C.
Are any of those safety guarantees important to a crypto project, though? Even heartbleed wasn't a "buffer overrun" in the memory safety sense of that word: the client was asking for and receiving the contents of memory that the server had every right, from a safety standpoint, to read from.
Oh, wow, thank you! I totally had conflated those two in my head. (Let this go down as a rare instance of a HN commenter not doubling down on being wrong...)
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.