zz VS min-sized-rust

> we'll find out Rust isn't the panacea to all our language problems

I don't think anyone is suggesting it will be. It's not about to supplant Ada SPARK, for instance, as Rust is far behind in terms of formal analysis.

> just like what the parent pointed out about Java and it's memory safety promises back in the day

Java does address the memory-safety issues of C and C++. You can't have a buffer overflow vulnerability in pure Java code. You can't have any kind of undefined behaviour due to memory-management mistakes in your code. You can't double-free, or use-after-free, or deference a pointer to a local variable that has gone out of scope. You can't trigger undefined behaviour through a read-before-write bug in your code.

It's possible to have a memory leak in Java, if you retain references to objects for too long, but that won't ever give rise to undefined behaviour.

Of course, there can still be bugs in a JVM, but that's another matter. All languages are vulnerable to compiler bugs.

Other languages like JavaScript do the same. It's possible to leak memory, but it's never possible to trigger undefined behaviour from JavaScript. That's a vital part of its security model.

> It is indeed quite possible to write memory safe C/C++ code... and it's done every day

That doesn't sound right.

There's a reason I gave the examples of the Linux kernel and Chromium. They're written by highly competent developers, but they still have subtle memory-management bugs. Most C/C++ codebases are written by less competent developers, but are of far less interest to attackers, so it's of less consequence. Their memory-management bugs are likely to go unnoticed forever.

I agree it's possible to write C/C++ code without memory-management bugs (there are various formal development systems for C), but it's a significant challenge. I'd hope avionics software, for instance, would be entirely free of such bugs.

> You never hear about how memory safe and performant all that code is... you only ever hear about the rare, high profile mistakes.

They're not that rare, they're a major source of serious security vulnerabilities, and languages like Safe Rust can close the door on them entirely.

> The problems with languages like C++ are more about how bloated it's become. There's 30 ways to do anything in that language, and 24 of them you're not supposed to use anymore!

Agreed. C++ is quite a lumbering monster of complexity. Ada also has a reputation for being somewhat bloated, but it's not as far gone as C++.

> if not for memory safety promises, then for it being a "fresh start" for systems programming without all the legacy baggage C++ has

Keep an eye on Zig, too. Also D and Nim, and perhaps Vala. Also the lesser-known ZZ language, which looks very interesting.

https://github.com/aep/zz

This is a good guide on building small Rust binaries: https://github.com/johnthagen/min-sized-rust

This talks about going to extreme lengths on making the smallest Rust binary possible, 400 bytes when it was written, https://darkcoding.net/software/a-very-small-rust-binary-ind...

The thing is, you lose a lot of nice features when you do this, like panic unwinding, debug symbols, stdlib… for kernel and some embedded development it’s definitely important, but for most use cases, does it matter?

Oh it was 137, haha. I will link you to this older comment of mine: https://news.ycombinator.com/item?id=29408906

See also https://github.com/johnthagen/min-sized-rust

Are you sure? If so then this is awesome news, but I'm a bit confused; the commit in that min-sized-rust repo adding `build-std` to the README was merged in August 2021: https://github.com/johnthagen/min-sized-rust/pull/30

Are you saying that at that point the feature still hadn't "landed in Rust nightly" until recently? If so then what's the difference between a feature just being available in Rust nightly, vs having "landed"?

Rust binaries are by default nowhere close to 500MB. If they are not small enough for you, you can try https://github.com/johnthagen/min-sized-rust. By avoiding the formatting machinery and using `panic_immediate_abort` you can get about the size of C binaries.

A useful reference: https://github.com/johnthagen/min-sized-rust

That must be without stripping. Also there are ways to reduce binary size. See e.g. [min-sized-rust](https://github.com/johnthagen/min-sized-rust). I've gotten stripped binaries of small cli utils less than 400KiB without doing anything special, less than 150 KiB by customizing profile settings and compressing with upx, and less than 30 KiB by replacing the std with the libc as the link shows. Haven't tried with fltk though...

This is not quite what you're asking, but it does also address the underlying concern: https://github.com/johnthagen/min-sized-rust