5 ms·

This title is almost perfectly designed to do well on HN, but it's definitely worth reading in it's entirety. Some highlights for me: - The author sees Rust a

This title is almost perfectly designed to do well on HN, but it's definitely worth reading in it's entirety. Some highlights for me: - The author sees Rust and Zig in different niches. When Rust was created it didn't need to specialise because there were no languages like Rust. It was free to be a general purpose language targeting multiple domains. But that's not the case for Zig. He sees Zig shining at writing systems software that requires low level control - where unsafe code is a necessity and fine grained control over allocation is a blessing. - The author was the original author of rust-analyzer, the LSP for Rust. I remember reading his original proposal for why Rust should ditch their existing LSP effort (called Rust Language Server) and start afresh with a completely new. And he was 100% right. He knows what he's talking about when it comes to IDE experiences for languages. I hope the Zig developers listen to what he's suggesting here. - "Rust is a language for building modular software ... the core of what Rust is doing: it provides you with a language to precisely express the contracts between components, such that components can be integrated in a machine-checkable way." That is a good description of Rust. Rust allows you to confidently assemble a program that works well, even if you have to collaborate with hundreds of other programmers to create it. - "Zig is about perfection. It is a very sharp, dangerous, but, ultimately, more flexible tool." Makes sense, but this tells me that I probably lack the skill to write correct Zig. - Comment by the author on reddit (https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9xyg/?context=1 https://www.reddit.com/r/rust/comments/123jpry/comment/jdv9x...) about advantages that Zig has is illuminating. Again, none of these appeal to me, but these are great to have in the right use case. - In a different comment on reddit (https://reddit.com/r/Zig/comments/123jpia/blog_post_zig_and_rust/jdvb087/?context=1 https://reddit.com/r/Zig/comments/123jpia/blog_post_zig_and_...) he said "Until release-safe guarantees the absence of UB, I wouldn't be ready to recommend Zig as a general-purpose language." Which is fair, but it's still early days for Zig, years to go before 1.0. It's entirely possible that this behaviour could come to be. I think the author's article makes a compelling case that Rust and Zig can both co-exist and succeed.

formerly_proven 4y ago
Zig feels like a good match for replacing C on microcontrollers because it permits “hold my beer” shenanigans and memory management is less of an issue. Zig metaprogramming also seems like a better match for these environments - think about how much nicer you could do stuff like qmk -, the Rust embedded stuff seems quite painful in comparison. Haven’t tried this yet, it’s on my perennial todo list and when I touch this stuff I usually want to get something done. I also imagine you’ll have to do everything yourself with Zig here, while Rust does have a lot of HAL crates.
- grawp 4y ago
  I have the exactly opposite experience. Rust move semantics, borrowing, Send&Sync types and checks and type based compile time state-machines is exactly what I was missing specifically on embedded systems in C/C++ and what I'm sorely missing in Zig. In Rust you start by splitting peripheries to blocks, then to registers, then to register parts and distributes these (these are zero cost operations!) into irq handlers and tasks and the type systems will check that everything that need exclusive access has it .. that you do not use read-modify-write operation on a same register from two interrupts where one can preempt the other without using some guard as mutex.. while it perfectly allow you to do this with write-only registers without guard etc... it is just so nice to work with. People who find it complicated and/or not worth it are usually doing either some rudimentary super duper easy stuff on architectures or OSes which does not have or utilize nested interrupts or they do it on some IOT like noncritical stuff where they don't give a s** (vs industrial machinery, drones, other vehicles..).
- kristoff_it 4y ago
  > Zig feels like a good match for replacing C on microcontrollers because it permits “hold my beer” shenanigans People who have used Zig to do embedded work have reported the opposite: they like Zig because it helps keep simple things simple and not more unsafe than they have to be. https://kevinlynagh.com/rust-zig/ https://kevinlynagh.com/rust-zig/
  - bschwindHN 4y ago
    I'm not sure what was available to the author at the time of writing, but it feels like abstractions have gotten better and writing embedded Rust has gotten easier. I also wrote keyboard firmware in Rust and thought it was great! I leaned on embedded-hal and the chip HAL crates (one layer of abstraction higher than the author in your link) and was able to get the majority of the firmware done in a day or two. For example, here is my key matrix scanning function: https://github.com/bschwind/key-ripper/blob/d33db6144bbb6f803f8a11f7a1ac8e83e5f54bcf/firmware/src/key_scan.rs#L22-L46 https://github.com/bschwind/key-ripper/blob/d33db6144bbb6f80... I also gave a small talk on the subject (aimed more at beginners) at a Rust meetup in Tokyo: https://www.youtube.com/watch?v=x7LQevYn7d0 https://www.youtube.com/watch?v=x7LQevYn7d0 And finally, a (somewhat) dated article I wrote about using Rust for embedded work: https://blog.tonari.no/rust-simple-hardware-project https://blog.tonari.no/rust-simple-hardware-project Overall, it feels totally usable to me, and I love how Rust's ownership and lifetime concepts prevent me from doing stupid things like reusing a pin for two peripherals or configuring a peripheral with pins it can't work with.
rektide 4y ago
> I remember reading his original proposal for why Rust should ditch their existing LSP effort (called Rust Language Server) and start afresh with a completely new. And he was 100% right. Where can I read more about this? What ended up happening?
- steveklabnik 4y ago
  https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html was the announcement of the replacement, and talks about it a little bit: > RLS was introduced by RFC 1317 and development was very active from 2016 through 2019. However, the architecture of RLS has several limitations that can make it difficult to provide low-latency and high-quality responses needed for an interactive environment. > rust-analyzer uses a fundamentally different approach that does not rely on using rustc. In RFC 2912 rust-analyzer was adopted as the official replacement for RLS. These RFCs provide some more color. The long and short of it is, the RLS relied on a process where rustc would sort of pre-process your codebase, and spit out a "save analysis" file. RLS would read this file, and do its thing. rust-analyzer, on the other hand, doesn't use rustc at all(*), and instead analyzes your code on-demand, in an incremental style. The latter has many advantages in an IDE context. The * is there because part of the original idea is that rustc would end up producing some libraries that rust-analyzer would also use, allowing them to share code. Given that rustc has also been moving towards an incremental, on-demand architecture, this would be easier. I am out of the loop these days, but from the relative outside, this effort seemed to stall out. I don't really know why. Maybe it has been happening and just isn't really visible. Regardless of those details, rust-analyzer is very good. It's a shame the transition took so long, in retrospect!
  - rektide 4y ago
    Very cool. Thanks for the links & write up!
- nindalf 4y ago
  I can't find the original link to his proposal, but I did send him a message on reddit asking if still had a link to it. The gist of it was, he felt the first attempt to make a Rust LSP (RLS) had the wrong architecture. It was basically running the Rust compiler in check mode and relaying the errors back. In his opinion an IDE needed a different, incremental architecture that stored state. It also needed to be much more tolerant of errors. He had already made a Rust IDE plugin in Java for JetBrain's IntelliJ-Rust plugin, and wanted to make a similar one in Rust. So he started the rust-analyzer project and it succeeded. Last year it became the official LSP of the Rust project. (https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-rust-org.html https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-ru...)
trh0awayman 4y ago
My general understanding is that Zig was made to make video games and Rust was made to make system software, and everything falls out from there.
- alpaca128 4y ago
  Did you mean Jai, which indeed is made with game development in mind? Because I've never heard anyone talk about games with Zig, and iirc one of the original motivations for the language was audio software.
yawaramin 4y ago
> He sees Zig shining at writing systems software that requires low level control. Honestly don't see why we would need to specialize this use case to a different language altogether when Rust already has `unsafe`.
- kristoff_it 4y ago
  Some arguments about how Rust `unsafe` is not the same as Zig: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ https://zackoverflow.dev/writing/unsafe-rust-vs-zig/
lr1970 4y ago
> - The author was the original author of rust-analyzer, the LSP for Rust Not only this. matklad is also original author of IntelliJ Rust - another popular IDE.

formerly_proven 4y ago

Zig feels like a good match for replacing C on microcontrollers because it permits “hold my beer” shenanigans and memory management is less of an issue. Zig metaprogramming also seems like a better match for these environments - think about how much nicer you could do stuff like qmk -, the Rust embedded stuff seems quite painful in comparison. Haven’t tried this yet, it’s on my perennial todo list and when I touch this stuff I usually want to get something done. I also imagine you’ll have to do everything yourself with Zig here, while Rust does have a lot of HAL crates.

grawp 4y ago
I have the exactly opposite experience. Rust move semantics, borrowing, Send&Sync types and checks and type based compile time state-machines is exactly what I was missing specifically on embedded systems in C/C++ and what I'm sorely missing in Zig. In Rust you start by splitting peripheries to blocks, then to registers, then to register parts and distributes these (these are zero cost operations!) into irq handlers and tasks and the type systems will check that everything that need exclusive access has it .. that you do not use read-modify-write operation on a same register from two interrupts where one can preempt the other without using some guard as mutex.. while it perfectly allow you to do this with write-only registers without guard etc... it is just so nice to work with. People who find it complicated and/or not worth it are usually doing either some rudimentary super duper easy stuff on architectures or OSes which does not have or utilize nested interrupts or they do it on some IOT like noncritical stuff where they don't give a s** (vs industrial machinery, drones, other vehicles..).
kristoff_it 4y ago
> Zig feels like a good match for replacing C on microcontrollers because it permits “hold my beer” shenanigans People who have used Zig to do embedded work have reported the opposite: they like Zig because it helps keep simple things simple and not more unsafe than they have to be. https://kevinlynagh.com/rust-zig/ https://kevinlynagh.com/rust-zig/
- bschwindHN 4y ago
  I'm not sure what was available to the author at the time of writing, but it feels like abstractions have gotten better and writing embedded Rust has gotten easier. I also wrote keyboard firmware in Rust and thought it was great! I leaned on embedded-hal and the chip HAL crates (one layer of abstraction higher than the author in your link) and was able to get the majority of the firmware done in a day or two. For example, here is my key matrix scanning function: https://github.com/bschwind/key-ripper/blob/d33db6144bbb6f803f8a11f7a1ac8e83e5f54bcf/firmware/src/key_scan.rs#L22-L46 https://github.com/bschwind/key-ripper/blob/d33db6144bbb6f80... I also gave a small talk on the subject (aimed more at beginners) at a Rust meetup in Tokyo: https://www.youtube.com/watch?v=x7LQevYn7d0 https://www.youtube.com/watch?v=x7LQevYn7d0 And finally, a (somewhat) dated article I wrote about using Rust for embedded work: https://blog.tonari.no/rust-simple-hardware-project https://blog.tonari.no/rust-simple-hardware-project Overall, it feels totally usable to me, and I love how Rust's ownership and lifetime concepts prevent me from doing stupid things like reusing a pin for two peripherals or configuring a peripheral with pins it can't work with.

rektide 4y ago

> I remember reading his original proposal for why Rust should ditch their existing LSP effort (called Rust Language Server) and start afresh with a completely new. And he was 100% right. Where can I read more about this? What ended up happening?

steveklabnik 4y ago
https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html was the announcement of the replacement, and talks about it a little bit: > RLS was introduced by RFC 1317 and development was very active from 2016 through 2019. However, the architecture of RLS has several limitations that can make it difficult to provide low-latency and high-quality responses needed for an interactive environment. > rust-analyzer uses a fundamentally different approach that does not rely on using rustc. In RFC 2912 rust-analyzer was adopted as the official replacement for RLS. These RFCs provide some more color. The long and short of it is, the RLS relied on a process where rustc would sort of pre-process your codebase, and spit out a "save analysis" file. RLS would read this file, and do its thing. rust-analyzer, on the other hand, doesn't use rustc at all(*), and instead analyzes your code on-demand, in an incremental style. The latter has many advantages in an IDE context. The * is there because part of the original idea is that rustc would end up producing some libraries that rust-analyzer would also use, allowing them to share code. Given that rustc has also been moving towards an incremental, on-demand architecture, this would be easier. I am out of the loop these days, but from the relative outside, this effort seemed to stall out. I don't really know why. Maybe it has been happening and just isn't really visible. Regardless of those details, rust-analyzer is very good. It's a shame the transition took so long, in retrospect!
- rektide 4y ago
  Very cool. Thanks for the links & write up!
nindalf 4y ago
I can't find the original link to his proposal, but I did send him a message on reddit asking if still had a link to it. The gist of it was, he felt the first attempt to make a Rust LSP (RLS) had the wrong architecture. It was basically running the Rust compiler in check mode and relaying the errors back. In his opinion an IDE needed a different, incremental architecture that stored state. It also needed to be much more tolerant of errors. He had already made a Rust IDE plugin in Java for JetBrain's IntelliJ-Rust plugin, and wanted to make a similar one in Rust. So he started the rust-analyzer project and it succeeded. Last year it became the official LSP of the Rust project. (https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-rust-org.html https://blog.rust-lang.org/2022/02/21/rust-analyzer-joins-ru...)

trh0awayman 4y ago

My general understanding is that Zig was made to make video games and Rust was made to make system software, and everything falls out from there.

alpaca128 4y ago
Did you mean Jai, which indeed is made with game development in mind? Because I've never heard anyone talk about games with Zig, and iirc one of the original motivations for the language was audio software.

yawaramin 4y ago

> He sees Zig shining at writing systems software that requires low level control. Honestly don't see why we would need to specialize this use case to a different language altogether when Rust already has `unsafe`.

kristoff_it 4y ago
Some arguments about how Rust `unsafe` is not the same as Zig: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/ https://zackoverflow.dev/writing/unsafe-rust-vs-zig/

lr1970 4y ago

> - The author was the original author of rust-analyzer, the LSP for Rust Not only this. matklad is also original author of IntelliJ Rust - another popular IDE.