Hacker News new | past | comments | ask | show | jobs | submit login

If you're interested in learning more about that, check out our NSDI'20 paper on how we chose this direction (https://www.usenix.org/conference/nsdi20/presentation/agache) and the Firecracker source and docs (https://github.com/firecracker-microvm/firecracker).

Thanks to KVM, and to the minimal hardware support (no PCI, no ACPI, etc), Firecracker's source is rather simple and even relatively readable for non-experts.




Firecracker's source is rather simple and even relatively readable for non-experts.

... as long as they're experienced at writing Rust. As a Rust newbie it took me a long time to figure out simple things like "where is foo implemented", due to the twisty maze of crates and uses directives.

I totally get why this code is written in Rust, but it would have made my life much easier if it were written in C. ;-)


> it took me a long time to figure out simple things like "where is foo implemented"

Out of curiosity, what development setup do you use?

I imagine that with vanilla EMacs or vanilla Vim you’d have to do quite a bit of spelunking to answer that sort of question.

With a full-blown IDE like for example JetBrains CLion with Rust plug-in installed, it is most of the time a matter of right-click -> go to definition / go to type declaration. (Although heavy use of Rust macros can in some cases confuse the system and make it unable to resolve definitions/declarations.)

And with JetBrains CLion you still have Vim keybindings available as a plug-in.

I switched from Vim to CLion + plug-ins years ago and haven’t looked back since. (Vanilla Vim is still on my servers though so that when I ssh in and want to edit some config files or whatever I can do so in the terminal.)


My development environment for this was mostly "nano in an SSH session". (Among other reasons, I can't even build Firecracker locally.) For FreeBSD work that's just fine since grep can find things for me. It didn't work so well for Firecracker.


I'm surprised `grep` didn't work for finding implementations. Did you find out why? Was it eg searching first-party source code but not crates?


Figuring out how to get all the crate source code extracted was the first step, yes. But when after that, the object oriented nature meant that there were often many different foo functions, so I had to dig through the code to figure out what type of object I was dealing with and which type each of the different foo implementations dealt with.

Whereas in FreeBSD I just grep for ^foo and the one and only line returned is where foo is implemented -- because if there's different versions of foo, they have different names.

Namespaces sound good in principle but they impose a mental load of "developers need to know what namespace they're currently in" -- which is fine for the original developer but much harder for someone jumping into the code for the first time.


If you go to the web site for the crate (or the standard library), and find the doco for the module / function / trait / ..., you find an handy "source" button. It will take you straight to the definition.

Eg, (me picking a random crate on crates.io): https://docs.rs/syn/2.0.29/syn/ or the standard library: https://doc.rust-lang.org/std/option/index.html

It's all generated by the same system from comments in the source. You can generate the same thing for your code.


Sure, but that doesn't help me when I want to go into that code and add extras debugging code so I can figure out where things are going wrong.


Yes! After a bit of playing around, I can follow Rust reasonably well... but only with an IDE, which I've never used for C or even really for the bits of Java I wrote. I understand that many more experienced Rust developers are similarly IDE-reliant.

I do think it's a deliberate tradeoff, having e.g. .push() do something useful for quite a few similar (Vec-like) data structures means you can often refactor Rust code to a similar data structure by changing one line... but it certainly doesn't make things as grep-friendly as C.


Etags makes answering that fairly simple in a C codebase and emacs can be an lsp client.


In comparison, I remember spending much less time finding "where is foo implemented" in Rust than in C++, and also found Rust std to be much more readable than C's when I wasn't familiar with each language. But I can see how rust with all the procedural macros, crates, traits could become a maze for people most familiar with C, and I probably don't feel that because of my C++ background.


If you use a language server, go-to-definition just works.


“Writing things in C to appease the C people” is reasoning that can’t possibly die soon enough. You’ve had a good run.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: