This is one of my favourite activites with LLMs as well. After implementing some sort of idea for an algorithm, I try seeing what an LLM would come up with. I hint it as well and push it in the correct direction with many iterations but never tell the most ideal one. And as a matter of fact they can never reach the quality I did with my initial implementation.
i never got this point. whats stopping me from writing a function like this in zig?
fn very_bad_func() !i32 {
var GPA = std.heap.GeneralPurposeAllocator(.{}){};
var gpa = GPA.allocator();
var s = try gpa.alloc(i32, 1000);
s[0] = 7;
return s[0];
}
the only thing explicit about zig approach is having ready-to-use allocator definitons in the std library. if you excluded std library and write your own allocators, you could have an even better api in rust compared to zig thanks to actual shared behaviour features (traits).
explicit allocation is a library feature, not a language feature.
the explicit part is that zig forces you to import allocator of your choosing whereas odin has allocator passed as part of hidden context and you can change/access it only if you want to. hence explicit behavior vs implicit behavior.
i use neither of those languages, so don't ask me for technical details :D
can you elaborate on what you mean by "move the borrow around registers", an example maybe? what other things are you experienced that are struggling doing in rust?
For one firmware, I have some code that keep the MCU sleeping and it wakes with I2C address match. When the I2C code handles the match, it must change the configuration of the system registers related to sleep to stay awake when waiting for interrupt, this means my I2C controller must be the owner of that register so it can change it. But after I2C handled the request the I2C controller must pass the register to the other controller that will go back to sleep when done. In rust I do that by having an Option<TheRegister> in both controller, and when I2C is done, main controller do the_option.take() to grab the register, do its job, then put it back. The usual way to do that in rust is to use Arc<Mutex<T>> but that doesn't work in my MCU, so I use the Option trick.
The other hard thing is DMA, it requires a lot of fidling, while in zig it jus works.
I'd argue these are related to current rust libraries rather than with Rust itself. For practical purposes this might not matter. I've been making an effort to clarify this, as I'm worried these early APIs will scare people away from Rust on embedded. I had to write my own HAL (with ergonomics and DMA-based APIs as priorities) since I ran into the same problems you describe.
reply