Hacker News new | ask | show | jobs
by TheNightman 938 days ago
This was my impression as well. I haven’t spent enough time with Rust to hold a hard stance on it but it definitely seems like it was not designed for “bare-metal” applications. I hadn’t heard of Zig before this but I’m definitely going to look into it now. Got any recommendations for a good intro to zig?
4 comments

How is that the case? You have bare pointers and the ability to manipulate them, allocation is explicit and can be disabled, you can remove the stdlib entirely, add your own allocator support, etc etc etc.
I'm aware of that, and the point still stands for me that I'm not sure what the point of writing in Rust is if you do all of those things.
This reads like “I’m not sure what’s the point of power tools if every now and then you need to reach for a plain old hammer or screwdriver”.

What’s the point of high-level languages at all if they’re just going to be implemented on top of a CPU that will happily chase raw pointers and divide by zero if you ask it to?

Because everything else can be expressed safely and more concisely than writing it in C or raw asm. And you have to pay virtually zero abstraction costs for the pleasure: see Rust’s comparative performance in language shootouts. Not infrequently Rust even beats C’s performance due to better visibility for optimizations.

And when you do still have to resort to unsafe low-level bit twiddling, you get to keep all the other benefits of having a modern, powerful language.

Do you genuinely think the Linux kernel is just throwing Rust in to attract kids who just follow the latest programming fads?

Well, sorry, but you're not being very clear. First you said it didn't seem designed for low level and now you're saying you aren't sure what the point is if it can do low level things?

It would help if you clarified. I don't want to try to clarify things and end up putting words into your mouth.

The point is that you limit where you're doing that.

Like just as an example - I can write an allocator and toggle register bits etc. All of that requires unsafe code, raw pointers, etc.

But I can then build on top of that in safe Rust, with all the guarantees that brings. I still have to check that the unsafe allocator or whatever work soundly, but Rust checks the stuff on top of it.

This gives a decent overview of some of the areas where the focus of Zig is different than Rust. Other than that...I'd just start by reading through the standard library code and the repo to get a feel. It's very very similar to C so you will be immediately comfortable, just cleans up some stuff like removing default global allocator (you pick your malloc basically), better macros (comptime), and encouraging use of non-null terminated strings and fat pointers etc.

https://ziglang.org/learn/why_zig_rust_d_cpp/

I use Rust for bare-metal development (no libc, no allocator, no panic, 32k size limit), and it is comparable to C and C++ for that use-case. The project is 99.5% Rust with a bit of assembly glue for startup/interrupt handlers.
It is not designed for, but Rust works well on microcontrollers, such as Arduino. For example, a blink program for Arduino in Rust is less than 300 bytes in size when compiled with "s" optimization level. It's a bit larger than C because of vector of interrupt handlers and error handling.
> It is not designed for,

Making sure Rust can work in embedded environments is absolutely a design goal, and choices around this are made explicitly.

>choices around this are made explicitly.

e.g?

A few off the top of my head: the core/std split, making the core language never allocate implicitly, the design of async/await.
> the design of async/await.

I am curious

How is "the design of async/await." for embedded programming?

The design of async/await took "using it in embedded" as a constraint. This is why it doesn't allocate, for example. Even C++ coroutines have one allocation, though they say that it can often be optimized away.

This means RTOS-like projects can use it for tasks, and it works well. Embassy is an example of such a project.

(Yet, I should also point out that you don't have to: at work we keep ours synchronous, for Reasons. Rust lets you do what you want.)

Async/await does not require dynamic memory allocation.