4 ms·

I’m not sure what you mean by your comments around C vs. C++/Rust. All of them have no required runtime. All of them generally have libc supplied by your OS, wh

I’m not sure what you mean by your comments around C vs. C++/Rust. All of them have no required runtime. All of them generally have libc supplied by your OS, which is a runtime. Even in C you must restrict yourself to the runtime your building on, i.e. your target might not have libc. Rust and C++ are the same in the regard that they are capable of doing this.

flohofwoe 7y ago
There was a time when Rust executables came with an embedded jemalloc, but that's been fixed in the meantime (I think). But that's not what I mean in the C++ and Rust case, instead: Both C++ and Rust make it quite easy to "accidentally" add bloat indirectly through their standard libraries because they encourage high-level abstractions which may "unfold" into a lot of binary code from very little source code. It can be avoided but requires to give up on many of the high-level language features which Rust and C++ differentiate from (for instance) C.
- bluejekyll 7y ago
  I can speak better for Rust in this regard, so I won't comment on C++, but I also don't work with #[no_std] often so apologies if anything is inaccurate. jemalloc has been optional in nightly ever since I started using the language in 2015. It switched to the system allocator in the 1.28 release, Aug 2018, it also stabilized the ability to define a custom Global Allocator[1]. > Rust make it quite easy to "accidentally" add bloat indirectly through their standard libraries This isn't accurate, the #![no_std] feature disables stdlib in your library/binary. It requires you to implement a few things, but it will not compile if you use things in std [2]. You may be interested in reading the embedded book[3] which discusses this area in a lot more detail. > give up on many of the high-level language features I also would disagree. You still have a powerful type system, match statements, RAII, hygienic macros, proc_macros, all of the core library[4], optionally have access to the alloc crate[5], cargo, simple unit-test integration, and a growing set of #[no_std] libraries with easy access through crates.io or git dependencies. There's a lot more of course. Point being, there are still a lot of higher-level language features available even in a #[no_std] context, and it's very easy to ensure that your binaries won't compile if this is a requirement and someone tries to pull something in that relies on std. [1]: https://blog.rust-lang.org/2018/08/02/Rust-1.28.html https://blog.rust-lang.org/2018/08/02/Rust-1.28.html [2]: https://doc.rust-lang.org/nomicon/beneath-std.html https://doc.rust-lang.org/nomicon/beneath-std.html [3]: https://rust-embedded.github.io/book/intro/no-std.html https://rust-embedded.github.io/book/intro/no-std.html [4]: https://doc.rust-lang.org/core/ https://doc.rust-lang.org/core/ [5]: https://doc.rust-lang.org/alloc/ https://doc.rust-lang.org/alloc/

flohofwoe 7y ago

There was a time when Rust executables came with an embedded jemalloc, but that's been fixed in the meantime (I think). But that's not what I mean in the C++ and Rust case, instead: Both C++ and Rust make it quite easy to "accidentally" add bloat indirectly through their standard libraries because they encourage high-level abstractions which may "unfold" into a lot of binary code from very little source code. It can be avoided but requires to give up on many of the high-level language features which Rust and C++ differentiate from (for instance) C.

bluejekyll 7y ago
I can speak better for Rust in this regard, so I won't comment on C++, but I also don't work with #[no_std] often so apologies if anything is inaccurate. jemalloc has been optional in nightly ever since I started using the language in 2015. It switched to the system allocator in the 1.28 release, Aug 2018, it also stabilized the ability to define a custom Global Allocator[1]. > Rust make it quite easy to "accidentally" add bloat indirectly through their standard libraries This isn't accurate, the #![no_std] feature disables stdlib in your library/binary. It requires you to implement a few things, but it will not compile if you use things in std [2]. You may be interested in reading the embedded book[3] which discusses this area in a lot more detail. > give up on many of the high-level language features I also would disagree. You still have a powerful type system, match statements, RAII, hygienic macros, proc_macros, all of the core library[4], optionally have access to the alloc crate[5], cargo, simple unit-test integration, and a growing set of #[no_std] libraries with easy access through crates.io or git dependencies. There's a lot more of course. Point being, there are still a lot of higher-level language features available even in a #[no_std] context, and it's very easy to ensure that your binaries won't compile if this is a requirement and someone tries to pull something in that relies on std. [1]: https://blog.rust-lang.org/2018/08/02/Rust-1.28.html https://blog.rust-lang.org/2018/08/02/Rust-1.28.html [2]: https://doc.rust-lang.org/nomicon/beneath-std.html https://doc.rust-lang.org/nomicon/beneath-std.html [3]: https://rust-embedded.github.io/book/intro/no-std.html https://rust-embedded.github.io/book/intro/no-std.html [4]: https://doc.rust-lang.org/core/ https://doc.rust-lang.org/core/ [5]: https://doc.rust-lang.org/alloc/ https://doc.rust-lang.org/alloc/