Comment by sirwhinesalot | Hacker News Reader

Comment by sirwhinesalot | Hacker News Reader

Parent Full thread

The other commenters already mentioned it but Rust is an alternative to C++, with a similar approach to "zero-cost abstractions". Meaning it provides you with the means to do systems programming at a higher-level and ignore low level details.

If you're learning low-level/barebones hardware programming, this is both a blessing and a curse. If you already know the low-level stuff, then Rust/C++ abstractions let you organize your code in a much nicer way, but if you're learning the low-level stuff, then those abstractions are actually in the way.

C won't get in the way, for better or worse, so it's definitely worth learning, at least to appreciate the safety valves Rust and C++ give you after you've repeatedly shot your own foot (specially Rust which learned from most of the historic mistakes of C++).

If you don't want to deal with C-nonsense, then Zig is probably the best alternative for that sort of low-level programming, it even has freestanding (no operating system) as a first class target, stack-traces and all.

FWIW you can easily write Rust in a C-like style, using primarily free-standing functions and structs. You can opt-in to “advanced” features (traits, enums, generics) as you see fit.

Interfacing with other libraries, is ofc, a different matter, but you can usually wrap the library API in your own functions to minimize this mismatch.

All of Rust's functions are available as "free-standing functions" because of how types work in Rust, and Rust doesn't have classes, just structs. So, as a consumer nothing changes.

   if std::collections::HashSet::is_empty(&basket) {

... is perfectly legal Rust, it would just be more idiomatic to write:

   if basket.is_empty() {

The availability of all functions as "free functions" is convenient when you need, say, a filter predicate, since of course std::collections::HashSet::is_empty is exactly what you wanted if what you wanted to express was the predicate "is this HashSet empty?" and in languages that aren't allowed to do this you'd need to pointlessly shuffle chairs around to achieve the same thing instead.

Yup, that's a good point, UFCS means that every method/function is free-standing =)

Universal Function Call Syntax goes both ways, Rust only offers to treat all of the things that seem like "methods" as free functions but not the reverse.

Under UFCS I could extend your Rust type by simply writing a new free function which matches the type, and this is in fact deliberately forbidden. (I can write the free function, but, doing so does not extend the type and I can't call it using the "method" syntax).

You can, but it's not like the Rust std-lib is in that style, nor does it play well with the ownership semantics, so my point stands.

You can also write literal C and use the C std-lib in C++ but it is the same problem. You're not using C++ at that point

You can use every rust API in that style, even if it wasn't written like that. See the sibling comment here: https://news.ycombinator.com/item?id=30472226

If you think what we're talking about amounts to having a . or not then you have no idea what we're talking about.

Rust's stdlib assumes not only that there is malloc behind the scenes, but that it is ok to panic. Rust itself, including its stdlib, lacks a stable ABI. It also assumes that lots of little allocations and deallocations with a single owner is a valid memory pattern, and that writing directly to specific memory locations is something you never want to do. These are all wrong assumptions for someone writing baremetal. Look up abi_stable and no_std.

Obviously for embedded use cases you’d not want to use std. it’s why we have core. If you want a stable ABI, you can also easily offer a repr(C) interface. I don’t know what to tell you, plenty of people use Rust successfully for embedded programming.

Of course they do, I never claimed otherwise. People also successfully use C++.

If you're learning, however, you know have to understand why you can't use generics (monomorphisation means you're not getting a stable ABI), why you shouldn't use native tagged unions and instead should write your own with unsafe (for total control of how the tag is handled), why you can't use the standard library, why you need to tag most things with repr(C), why the standard ownership patterns the borrow checker beat into you are in the way when writing your own allocator (with plenty of unsafe). Do you see my point?

Both Rust and C++, when writing baremetal, ask you to ignore how to write idiomatic code in their respective languages. This is fine for experienced devs, who will make good use of the additional features for abstraction, but not for newbies IMO.

C and Zig, on the other hand, do not have this problem, as idiomatic C barely uses its standard library (which is garbage anyway) and idiomatic Zig is designed to work baremetal, including the standard library. I certainly don't recommend using C for new developments in most cases, but for learning, well, you need to learn it anyway, even if you're using Rust baremetal. It's effectively what you're writing, albeit with lots of repr and unsafe strewn around.

Reply on news.ycombinator.com