Thank God this VMM is written in Rust, otherwise I would be very skeptical. I don't care about features or purpose or technical advantages, give me Rust or give me death.
For real, I find it so odd to tack on "written in Rust" to every new project that's announced that uses Rust. (As someone who uses Rust in their day job)
As someone who does no programming at all, I can say that it kinda works.
It makes me think "Ok they have made a VMM again, but this time in that somehow safer programming language Rust. They probably know what they're doing so it will be just as good as the old one, only safer!".
I know enough to know that this is not necessarily true, but when I see these posts I always hope that it's true (and rely on people with the proper knowledge and experience to verify if it is or isn't).
Then I go to the comments and there is often a discussion about how a rewrite will probably be less secure because it will introduce new bugs. But then maybe those will be fixed and eventually it will just be a more secure version.
"Written in Rust" to me implied that they're willing to go with a modern tech stack.
When I see that a project is written in Rust I assume that beyond the language, their other technology/library/framework choices also tend torwards what is modern and unstable, rather than what is conventional and solid.
That information is relevant to shaping one's view of a project. I think it makes sense to mention that you're using a modern stack.
(Though Rust is already close to moving into the conventional/solid category.)
Why is there a conflation between "modern" and "unstable", and "conventional" and "solid"? I've seen plenty of conventional things that are not solid, and plenty of modern things that were far from unstable. Or maybe I have a different threshold for what modern is.
Beyond your parenthetical, what about Rust is unstable for you today? It would be interesting to me to hear that in order to see if the things that come to mind when hearing that are the same that you meant.
Traditionally this would have been written in something like C, which, while conventional, is hardly solid in security-sensitive contexts like this one.
I also tend to think “will lack long term support”, as I’ve seen many Rust projects where the OG devs move on to other projects. It’s fine to do that of course, but when I see “X but written in Rust” I read it as “I made this as an exercise” and not “I am making a full attempt to replace this other project”.
You're right. It does smack a little bit of insecurity (phycological, not in the CS sense). But, "blah blah blah `written by AI`" transmits a different signal than "blah blah blah `written in Rust`", at least for now.
because languages matter more than people like to admit
yes you can write OOP in C , but please don't
and you can write fp code in Java .. this one I am not so sure about, but I would say its still better to just use scala or clojure if you must JVM, and use just use ocaml and drop the no-tail-call-optimization-jvm
Tl;Dr: Run the VM with only modern paravirtualized devices, then run OpenHCL inside the VM in ring -1 to emulate legacy devices and the guest os in ring 0 as usual.
This is more secure, as the host only exposes paravirtualized devices with reduced attack surface to the guest. While still allowing to run legacy os.
It never even occurred to me that they could be talking about something other than the virtual memory manager. I was hyped to see if there was some new architecture being applied for cross-OS compatibility, novel memory objects, techniques to reduce fragmentation, stuff like that. Now I’m just sad.
I knew what it stood for, but a pet peeve of mine in any form of engineering documentation (or frankly any technical documentation in any field) is not spelling out acronyms/initialisms on their first use; it was drilled into me in my degree; always spell out the first time you use a term on the assumption that the reader doesn't already know what any of it stands for.
I both expect and don't expect this from Microsoft, but it makes me irrationally annoyed and I'm already feeling adversarial when reading something that does this in the first sentence no less.
Looking at Cargo.toml, a great deal of the project's dependencies are internal dependencies. Those are located in the same repo, and the separation is only there to help keep the compile times manageable by allowing parallel compilation.
It's very rare to see so many internal dependencies in one project, but the concept itself is well explored.
But besides that, it's just the project making use of the Rust ecosystem instead of rolling everything by themselves. From what I can see most of these external dependencies are already established in the ecosystem (some crates I am not sure since I've never used them, but anyhow, http, hyper etc. are among the most popular crates).
> the separation is only there to help keep the compile times manageable
I don't think that's the reason, at least not the only reason. Workspaces is just a nice and modular way to organize a big project and separate concerns.
Cargo.toml is more appropriate to check dependencies and that has 642 lines. Some of them maybe just for testing or project setup. Remove them all I think it still would leave you with few hundred dependencies. And that does not seem excessive for a Rust project specially from Microsoft.
I mention Microsoft specifically because their Go projects are similarly excessive in dependencies even though higher quality Go projects do have fewer dependencies.
External dependencies only start on line 354 of that file, and end on line 503. The rest is internal dependencies (within the repository), and build config.
It's a different metric all together though, since it doesn't show transitive dependencies only direct dependencies (and as you suggest it doesn't distinguish between actual dependencies and testing dependencies because it's a workspace cargo.toml). As someone else suggested, using a program like cargo tree is the most appropriate.
It's also worth putting this in context that there's half a million lines of rust code in this repository.
Cargo.lock is not ideal for this. It needs to be portable, and cover all kinds of builds and test runs, so it contains a superset of all dependencies for all platforms (recursively), as well as development-only dependencies, and everything needed for all optional features.
Running `cargo tree -e normal` gives a more realistic subset of what is actually used, and `cargo tree -e normal --no-default-features` gives you the "basically just needs" subset.
Another thing to keep in mind that Rust projects are very often split into many small packages (from the same authors, published as part of the same project). That isn't more code or more dependencies, but merely delivering code not as one monolith, but as modular components.
I want to understand what communication channel(s) it has from guest to host. It's not clear from the cut-and-paste support described in the VNC section of the manual, how this works and what other functionality might be supported.
I find it interesting that every single piece of software that was ever written in Rust always mentions that very proudly in its title. It's not something I see often with other programming languages (most software is just software and doesn't necessarily advertise the language it was built with). I do not know anything about Rust, so I'm just curious, does this confer a kind of underlying trustworthiness or quality to the application?
> It's not something I see often with other programming languages
Search HN stories for "written in", sort by date, and in the past couple weeks there are of course a number of "written in rust" but also c, python, ruby, go, c++, lisp, java, javascript, flutter, crystal, and react. Rust has the most instances currently but it's also common enough here with other languages.
This is interesting and clearly a true claim, but anecdotally I feel like the combination of 1) lands on HN homepage and 2) includes "written in" in the title is heavily biased towards Rust. I don't know how to search for those two qualifiers to prove or disapprove my feelings though.
I did a simpler count: the number of comments in this thread that either
(without also talking about the content of the submission) (1) only talk
about Rust (2) only talk about programming languages (3) talk about how
programming language choice impacts the project or the quality of the
software (or how it might not be a guarantee of those things) (4) talk
about how a VMM being written in Rust/not being written in Rust is good
(this last one is the closest to the submission topic but still not
about the submission topic).
It wasn't until this comment that made me realize that using "written in Rust" as rage click bait is such a "useful" strategy here, because it will inevitably attract plenty of comments about the mentioning of the language. Ironically, the people complaining end up increasing the post's rank by engaging more.
Due to Rust's safety guarantees there's a perception that software written in Rust is automatically safer than software written in its direct competitors C and C++.
This is not necessarily true, you can write unsafe Rust code and you can write safe C++ code, but it does seem to hold in practice that the guardrails imposed by Rust help quite a bit in stopping devs from making really stupid mistakes.
That would be the "thrustworthiness" implied by the use of Rust.
And a VMM is going to require a lot of unsafe rust code. There are strategies to minimize it to make that surface easier to audit, but it is not a panacea for systems programming gremlins.
Out of 413,842 non-empty lines of rust code in the repository (including comments) there are 2006 instances of "unsafe", 255 of which are of the form "unsafe_" (definitely not unsafe blocks, mostly of the form #![forbid(unsafe_code)] which is an instruction to the linter to forbid unsafe blocks in the module) leaving slightly less than 1751 unsafe blocks. (Still counting comments, and type signature annotations on function pointers, and so on, but most of those 1751 will be actual unsafe blocks. A block can of course be multiple lines of code).
I don't really know what a VMM consists of, so I'm mostly surprised that this project is half a million lines of code.
No question, just pointing out where the *perceived* trustworthiness comes from. If it helps for something like a VMM it's a whole other story. Marketing gimmick.
It's not unsafe that causes unsafety, it's how you wield it.
- Do you know your invariants?
- Have you documented them?
- If using unsafe block, have you asserted them or guaranteed that they hold for any input?
Granted, Rust is kind of mediocre at teaching you this. It raises warning for unsafe fn without safety documentation block, but not when omittin safety comments in unsafe blocks.
I've also seen this done for C and modern C++. I believe it's done to suggest something (i.e. Rust is memory safe, C is usually fast, modern C++ is used to distinguish from the terrible old C++, Java runs on the JVM so it's relatively easy to use cross platform, Kotlin is for Java software that doesn't throw random null pointers every week, etc.)
The same tokens are also used for stuff that is designed to run on bare metal/containers/kubernetes/"""serverless""".
I find it interesting that every single post which has "written in Rust" also has someone in the comments asking why every single Rust project advertises it was written in Rust.
It's fascinating to me that every post which has "written in Rust" includes a comment pointing out the fact that someone in the comments always asks why every single Rust project advertises it was written in Rust.
(term simplification, halt loop) It’s fascinating that a forum full of technical people make comments that lampoon the meta commentary by making an nth-order meta comment.
Do you not remember ten years ago when this was a thing with Python? It's an effective evangelism tactic. Super annoying, but it "works" in some sense. I consider it like "YouTube face", I tolerate it because even good projects or creators have to play the game to some extent or get washed away in the crapflood.
> Also, I don't find it annoying, but helpful, because I care - amongst other things - about the language of open source software projects.
Come on, this is not even a good strawman. It's very easy to find out the language of you want to know, and it's possible to inform without evangelism.
It may seem proselite and overly highlighted, but personally I find it very practical.
Whenever I review a tool, or look for an alternative, I always look at the state of the maintenance and the choice of programming language, mainly to eliminate, as much as possible, the many tools written in Javascript and Python when it is not suitable.
I will not necessarily prefer a tool written in Rust, but at least it is rarely a flaw.
That was Go a 10 years ago, now it's Rust. Some people feel the need to talk loudly about their tools, which can be annoying, but also helps put it on the radar for the rest of us. Once we're aware of something we can assess it for ourselves and maybe we stick with it and maybe we go back to what we where doing before, or move on to the next thing.
The Rust fans are pushing it a bit, I understand why they love the language, but I don't, so the insisting hammering on "written in Rust" can push me away from certain tools. In the end it will die down and the loudest will move on to the next language, once the Rust hype has been tapered out.
"Written in Rust" is a brand that confers fast and safe. Like any brand, there is some truth to it but no rigorous guarantees. If Rust becomes more widely used that brand will likely start to fade.
I agree, but if we tried to reason why: I would argue that it's because writing rust code that compiles is harder.
We tend to ascribe significance to things that are percieved as difficult, back in the day for example a book was hugely important, so authors were revered, but now with the advent of easier access to printing presses an author is not similarly revered.
Making small modules here and there, even if hard, is deemed less effort, and similarly gluing small modules together is deemed even less significant of an achievement, so what you're solving becomes much more important than how, since significance in the process is diminished.
Since Rust is harder than C++ (making compiling software is easier, even if there's runtime errors after all) - we ascribe significance to the fact that it was used.
I don't think it's any secret that Rust is a very hyped up language, has been for 5 years already.
I've been saying for years now that if Rust was a stock, I'd be investing. Meaning, if I was a young programmer I would probably take the time to learn Rust, because it's going to be in high demand.
When something needs to be constantly emphasized, it makes me suspicious. The more I read "[...] in Rust", the less I will be surprised if Rust is considered harmful in another 5 to 10 years.
Promotional PR tactics benefit programmers of non-mainstream languages by raising awareness, interest, the labor market, and hopefully professional jobs working on the particular technology.
It is a useful feature. We’ve had tons and tons of bugs caused by C/C++ misfeatures which is both why Rust was invented and why users are looking for more stable alternatives after decades on the patch of the week treadmill. A tool like this is aimed at a technical audience who will see the appeal of a tool which is safer and easier to work on.
Right, but I suspect people would like to use it to run VMs rather than start developing it. If the indent is to invite developers who "know rust", then that is the wrong measuring bar (IMO, of course), as you'd want developers who are interested in hypervisors instead of a specific language.
Not disagreeing with you on the memory safety. It's just that the way "written in Rust" is used, it seems like a marketing gimmick to invite anyone who knows (or maybe wants to learn) Rust. Shows (IMO!) the weakness of the project rather than its seriousness.
It's the in-thing at the moment so it certainly attracts attention. Make sure to claim to be "Blazing fast [Rocket Emoji]" in the README too for good measure.
Yes we do, just look at the years following up the introduction of XYZ language, be it on BBS, Compuserve, Prodigy, Usenet, Dejanews, or whatever is the main communications channel of the day.
> It's not something I see often with other programming languages
Lisp software also presented with "Lisp" in the title. Lisp programs are rarer, so you see "Lisp" in titles less frequently than "Rust" but I believe that any Lisp program proudly claims that it was written in Lisp.
Rust culture is a lot like socialism, libertarians, fundamentalist religions, vegans, etc. They see themselves apart from the "mainstream", as rebels, revolutionaries, etc.
In their beginning, Java and Python were like that, too. Lua, Haskell and Kotlin also do the same. Golang is more discrete.
The website states: "OpenVMM is a modular, cross-platform, general-purpose Virtual Machine Monitor (VMM), written in Rust."
I'd leave out the "written in Rust", because who cares, but I think it's in the license terms for Rust that you need to include that in when communication your project. The modular and cross-platform is much more interesting that the implementation language, and much more relevant for the majority of the users. I'd focus on that if I wrote the documentation and marketing material. One excuse I'd make is that the link is to the Github repository, where it's perhaps more relevant that you're informed that you'll be looking at Rust code.
Is that true? That the license requires the addition of "written in Rust" to announcements? I looked and couldn't find the requirement.
But, agree generally with your points.
Rust was something i thought was a cute little language years ago, much like i thought python was. I didn't pay attention for like 2 years and it feels likes it's everywhere and everything.
Thank God this VMM is written in Rust, otherwise I would be very skeptical. I don't care about features or purpose or technical advantages, give me Rust or give me death.
When it comes to low-level, security sensitive software like this, I actually do value the software being written in a relatively safe language.
Could Rust, could be C# for all I care.
Rust's safety properties are vastly better than C#, memory safety is the barrier to entry.
For real, I find it so odd to tack on "written in Rust" to every new project that's announced that uses Rust. (As someone who uses Rust in their day job)
As someone who does no programming at all, I can say that it kinda works.
It makes me think "Ok they have made a VMM again, but this time in that somehow safer programming language Rust. They probably know what they're doing so it will be just as good as the old one, only safer!".
I know enough to know that this is not necessarily true, but when I see these posts I always hope that it's true (and rely on people with the proper knowledge and experience to verify if it is or isn't).
Then I go to the comments and there is often a discussion about how a rewrite will probably be less secure because it will introduce new bugs. But then maybe those will be fixed and eventually it will just be a more secure version.
"Written in Rust" to me implied that they're willing to go with a modern tech stack.
When I see that a project is written in Rust I assume that beyond the language, their other technology/library/framework choices also tend torwards what is modern and unstable, rather than what is conventional and solid.
That information is relevant to shaping one's view of a project. I think it makes sense to mention that you're using a modern stack.
(Though Rust is already close to moving into the conventional/solid category.)
Why is there a conflation between "modern" and "unstable", and "conventional" and "solid"? I've seen plenty of conventional things that are not solid, and plenty of modern things that were far from unstable. Or maybe I have a different threshold for what modern is.
Beyond your parenthetical, what about Rust is unstable for you today? It would be interesting to me to hear that in order to see if the things that come to mind when hearing that are the same that you meant.
Traditionally this would have been written in something like C, which, while conventional, is hardly solid in security-sensitive contexts like this one.
I also tend to think “will lack long term support”, as I’ve seen many Rust projects where the OG devs move on to other projects. It’s fine to do that of course, but when I see “X but written in Rust” I read it as “I made this as an exercise” and not “I am making a full attempt to replace this other project”.
I consider a language mature, when it's developers stop feeling the need to list "written in X" in the features section of the repository/main page.
That'd be a poor criteria. C++ is now an immature language:
Show HN: Comprehensive inter-process communication (IPC) toolkit in modern C++ (2024) https://news.ycombinator.com/item?id=40028118
You're right. It does smack a little bit of insecurity (phycological, not in the CS sense). But, "blah blah blah `written by AI`" transmits a different signal than "blah blah blah `written in Rust`", at least for now.
because languages matter more than people like to admit
yes you can write OOP in C , but please don't
and you can write fp code in Java .. this one I am not so sure about, but I would say its still better to just use scala or clojure if you must JVM, and use just use ocaml and drop the no-tail-call-optimization-jvm
the point is .. languages matter
Note this “disclaimer” in the guide:
> In recent years, development efforts in the OpenVMM project have primarily focused on OpenHCL (AKA: OpenVMM as a paravisor).
> As a result, not a lot of "polish" has gone into making the experience of running OpenVMM in traditional host contexts particularly "pleasant".
> This lack of polish manifests in several ways, including but not limited to: […]
> • No API or feature-set stability guarantees whatsoever.
https://github.com/microsoft/openvmm/blob/main/Guide/src/use...
Plus, for running as a paravisor:
> OpenHCL currently relies on Hyper-V's implementation of Virtual Trust Levels (VTLs) to implement the security boundaries necessary
OpenHCL is much more interesting than OpenVMM:
Tl;Dr: Run the VM with only modern paravirtualized devices, then run OpenHCL inside the VM in ring -1 to emulate legacy devices and the guest os in ring 0 as usual.
This is more secure, as the host only exposes paravirtualized devices with reduced attack surface to the guest. While still allowing to run legacy os.
In case anybody else wondered VMM = Virtual Machine Monitor.
I read it as Virtual Memory Manager and wondered how the heck they pulled one off that works for both Windows and Linux.
It never even occurred to me that they could be talking about something other than the virtual memory manager. I was hyped to see if there was some new architecture being applied for cross-OS compatibility, novel memory objects, techniques to reduce fragmentation, stuff like that. Now I’m just sad.
I knew what it stood for, but a pet peeve of mine in any form of engineering documentation (or frankly any technical documentation in any field) is not spelling out acronyms/initialisms on their first use; it was drilled into me in my degree; always spell out the first time you use a term on the assumption that the reader doesn't already know what any of it stands for.
I both expect and don't expect this from Microsoft, but it makes me irrationally annoyed and I'm already feeling adversarial when reading something that does this in the first sentence no less.
Cargo.lock has 8750 lines. Is that normal for something like this?
For comparison, QEMU basically just needs glibc, glib and zlib for basic functionality.
Looking at Cargo.toml, a great deal of the project's dependencies are internal dependencies. Those are located in the same repo, and the separation is only there to help keep the compile times manageable by allowing parallel compilation.
It's very rare to see so many internal dependencies in one project, but the concept itself is well explored.
But besides that, it's just the project making use of the Rust ecosystem instead of rolling everything by themselves. From what I can see most of these external dependencies are already established in the ecosystem (some crates I am not sure since I've never used them, but anyhow, http, hyper etc. are among the most popular crates).
> the separation is only there to help keep the compile times manageable
I don't think that's the reason, at least not the only reason. Workspaces is just a nice and modular way to organize a big project and separate concerns.
Cargo.toml is more appropriate to check dependencies and that has 642 lines. Some of them maybe just for testing or project setup. Remove them all I think it still would leave you with few hundred dependencies. And that does not seem excessive for a Rust project specially from Microsoft.
I mention Microsoft specifically because their Go projects are similarly excessive in dependencies even though higher quality Go projects do have fewer dependencies.
External dependencies only start on line 354 of that file, and end on line 503. The rest is internal dependencies (within the repository), and build config.
It's a different metric all together though, since it doesn't show transitive dependencies only direct dependencies (and as you suggest it doesn't distinguish between actual dependencies and testing dependencies because it's a workspace cargo.toml). As someone else suggested, using a program like cargo tree is the most appropriate.
It's also worth putting this in context that there's half a million lines of rust code in this repository.
Cargo.lock is not ideal for this. It needs to be portable, and cover all kinds of builds and test runs, so it contains a superset of all dependencies for all platforms (recursively), as well as development-only dependencies, and everything needed for all optional features.
Running `cargo tree -e normal` gives a more realistic subset of what is actually used, and `cargo tree -e normal --no-default-features` gives you the "basically just needs" subset.
Another thing to keep in mind that Rust projects are very often split into many small packages (from the same authors, published as part of the same project). That isn't more code or more dependencies, but merely delivering code not as one monolith, but as modular components.
How does this relate/compare to CloudHypervisor, another Rust based VMM that has been around for couple of years
https://github.com/cloud-hypervisor/cloud-hypervisor
This one is written by Microsoft employees and used on Azure.
Slides from Linux Plumbers talk about OpenHCL: https://lpc.events/event/18/contributions/1956/attachments/1...
Half the user guide is empty.
I want to understand what communication channel(s) it has from guest to host. It's not clear from the cut-and-paste support described in the VNC section of the manual, how this works and what other functionality might be supported.
I find it interesting that every single piece of software that was ever written in Rust always mentions that very proudly in its title. It's not something I see often with other programming languages (most software is just software and doesn't necessarily advertise the language it was built with). I do not know anything about Rust, so I'm just curious, does this confer a kind of underlying trustworthiness or quality to the application?
> It's not something I see often with other programming languages
Search HN stories for "written in", sort by date, and in the past couple weeks there are of course a number of "written in rust" but also c, python, ruby, go, c++, lisp, java, javascript, flutter, crystal, and react. Rust has the most instances currently but it's also common enough here with other languages.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
This is interesting and clearly a true claim, but anecdotally I feel like the combination of 1) lands on HN homepage and 2) includes "written in" in the title is heavily biased towards Rust. I don't know how to search for those two qualifiers to prove or disapprove my feelings though.
I did a simpler count: the number of comments in this thread that either (without also talking about the content of the submission) (1) only talk about Rust (2) only talk about programming languages (3) talk about how programming language choice impacts the project or the quality of the software (or how it might not be a guarantee of those things) (4) talk about how a VMM being written in Rust/not being written in Rust is good (this last one is the closest to the submission topic but still not about the submission topic).
45/64.
It wasn't until this comment that made me realize that using "written in Rust" as rage click bait is such a "useful" strategy here, because it will inevitably attract plenty of comments about the mentioning of the language. Ironically, the people complaining end up increasing the post's rank by engaging more.
Due to Rust's safety guarantees there's a perception that software written in Rust is automatically safer than software written in its direct competitors C and C++.
This is not necessarily true, you can write unsafe Rust code and you can write safe C++ code, but it does seem to hold in practice that the guardrails imposed by Rust help quite a bit in stopping devs from making really stupid mistakes.
That would be the "thrustworthiness" implied by the use of Rust.
And a VMM is going to require a lot of unsafe rust code. There are strategies to minimize it to make that surface easier to audit, but it is not a panacea for systems programming gremlins.
It is manager, not runner. Does it require that much unsafe?
Out of 413,842 non-empty lines of rust code in the repository (including comments) there are 2006 instances of "unsafe", 255 of which are of the form "unsafe_" (definitely not unsafe blocks, mostly of the form #![forbid(unsafe_code)] which is an instruction to the linter to forbid unsafe blocks in the module) leaving slightly less than 1751 unsafe blocks. (Still counting comments, and type signature annotations on function pointers, and so on, but most of those 1751 will be actual unsafe blocks. A block can of course be multiple lines of code).
I don't really know what a VMM consists of, so I'm mostly surprised that this project is half a million lines of code.
For this kind of analysis, https://github.com/geiger-rs/cargo-geiger comes in handy.
No question, just pointing out where the *perceived* trustworthiness comes from. If it helps for something like a VMM it's a whole other story. Marketing gimmick.
A paravisor actually doesn't really need that much.
It's not unsafe that causes unsafety, it's how you wield it.
- Do you know your invariants?
- Have you documented them?
- If using unsafe block, have you asserted them or guaranteed that they hold for any input?
Granted, Rust is kind of mediocre at teaching you this. It raises warning for unsafe fn without safety documentation block, but not when omittin safety comments in unsafe blocks.
For what it's worth, clippy has an optional lint to detect undocumented unsafe blocks: https://rust-lang.github.io/rust-clippy/master/index.html#un...
I've also seen this done for C and modern C++. I believe it's done to suggest something (i.e. Rust is memory safe, C is usually fast, modern C++ is used to distinguish from the terrible old C++, Java runs on the JVM so it's relatively easy to use cross platform, Kotlin is for Java software that doesn't throw random null pointers every week, etc.)
The same tokens are also used for stuff that is designed to run on bare metal/containers/kubernetes/"""serverless""".
I find it interesting that every single post which has "written in Rust" also has someone in the comments asking why every single Rust project advertises it was written in Rust.
This comment was written in plain text.
It's fascinating to me that every post which has "written in Rust" includes a comment pointing out the fact that someone in the comments always asks why every single Rust project advertises it was written in Rust.
(term simplification, halt loop) It’s fascinating that a forum full of technical people make comments that lampoon the meta commentary by making an nth-order meta comment.
Technical people have fun too. I think.
This statement relies on self-reported inner state. It is inherently unreliable. ;)
Do you not remember ten years ago when this was a thing with Python? It's an effective evangelism tactic. Super annoying, but it "works" in some sense. I consider it like "YouTube face", I tolerate it because even good projects or creators have to play the game to some extent or get washed away in the crapflood.
HN in particular has a long history of this kind of thing, e.g “Written in Ruby”.
(Or if you’ve been around super long, “written in Lisp”.)
I doubt that a GitHub README is used for language evangelism. If at all, it's project promotion.
Also, I don't find it annoying, but helpful, because I care - amongst other things - about the language of open source software projects.
> I doubt that a GitHub README is used for language evangelism.
Perhaps you should reconsider this. OpenVMM split up its docs and there isn't much in the actual README, but a few seconds investigation led me to https://github.com/microsoft/openvmm/blob/main/Guide/src/dev... , for example.
> Also, I don't find it annoying, but helpful, because I care - amongst other things - about the language of open source software projects.
Come on, this is not even a good strawman. It's very easy to find out the language of you want to know, and it's possible to inform without evangelism.
> OpenVMM split up its docs and there isn't much in the actual README, but a few seconds investigation led me to https://github.com/microsoft/openvmm/blob/main/Guide/src/dev... , for example.
this is a reason to reconsider my statement why?
> Come on, this is not even a good strawman.
It's not a straw man at all. It's my opinion.
> It's very easy to find out the language of you want to know, and it's possible to inform without evangelism.
Indeed, but nothing makes it more straight forward than the language being mentioned in the HN News title
It's meant to imply that it's as performant as, but safer than c/c++.
But not necessarily less buggy or more useful than the counterparts (if there even are any).
It may seem proselite and overly highlighted, but personally I find it very practical.
Whenever I review a tool, or look for an alternative, I always look at the state of the maintenance and the choice of programming language, mainly to eliminate, as much as possible, the many tools written in Javascript and Python when it is not suitable.
I will not necessarily prefer a tool written in Rust, but at least it is rarely a flaw.
That was Go a 10 years ago, now it's Rust. Some people feel the need to talk loudly about their tools, which can be annoying, but also helps put it on the radar for the rest of us. Once we're aware of something we can assess it for ourselves and maybe we stick with it and maybe we go back to what we where doing before, or move on to the next thing.
The Rust fans are pushing it a bit, I understand why they love the language, but I don't, so the insisting hammering on "written in Rust" can push me away from certain tools. In the end it will die down and the loudest will move on to the next language, once the Rust hype has been tapered out.
"Written in Rust" is a brand that confers fast and safe. Like any brand, there is some truth to it but no rigorous guarantees. If Rust becomes more widely used that brand will likely start to fade.
It also confers “cargo install” if it’s an app.
I agree, but if we tried to reason why: I would argue that it's because writing rust code that compiles is harder.
We tend to ascribe significance to things that are percieved as difficult, back in the day for example a book was hugely important, so authors were revered, but now with the advent of easier access to printing presses an author is not similarly revered.
Making small modules here and there, even if hard, is deemed less effort, and similarly gluing small modules together is deemed even less significant of an achievement, so what you're solving becomes much more important than how, since significance in the process is diminished.
Since Rust is harder than C++ (making compiling software is easier, even if there's runtime errors after all) - we ascribe significance to the fact that it was used.
One thing is for sure, it's going to help it be a more stable, robust piece of software, that's already a big deal.
I don't think it's any secret that Rust is a very hyped up language, has been for 5 years already.
I've been saying for years now that if Rust was a stock, I'd be investing. Meaning, if I was a young programmer I would probably take the time to learn Rust, because it's going to be in high demand.
When something needs to be constantly emphasized, it makes me suspicious. The more I read "[...] in Rust", the less I will be surprised if Rust is considered harmful in another 5 to 10 years.
Promotional PR tactics benefit programmers of non-mainstream languages by raising awareness, interest, the labor market, and hopefully professional jobs working on the particular technology.
It seems as if the implementation detail is the feature. Can't the program stand for itself?
It is a useful feature. We’ve had tons and tons of bugs caused by C/C++ misfeatures which is both why Rust was invented and why users are looking for more stable alternatives after decades on the patch of the week treadmill. A tool like this is aimed at a technical audience who will see the appeal of a tool which is safer and easier to work on.
Right, but I suspect people would like to use it to run VMs rather than start developing it. If the indent is to invite developers who "know rust", then that is the wrong measuring bar (IMO, of course), as you'd want developers who are interested in hypervisors instead of a specific language.
As a user of VMs, I would value memory safety because hypervisor exploits are nasty and patching is higher risk.
Not disagreeing with you on the memory safety. It's just that the way "written in Rust" is used, it seems like a marketing gimmick to invite anyone who knows (or maybe wants to learn) Rust. Shows (IMO!) the weakness of the project rather than its seriousness.
It's the in-thing at the moment so it certainly attracts attention. Make sure to claim to be "Blazing fast [Rocket Emoji]" in the README too for good measure.
Yes we do, just look at the years following up the introduction of XYZ language, be it on BBS, Compuserve, Prodigy, Usenet, Dejanews, or whatever is the main communications channel of the day.
> It's not something I see often with other programming languages
Lisp software also presented with "Lisp" in the title. Lisp programs are rarer, so you see "Lisp" in titles less frequently than "Rust" but I believe that any Lisp program proudly claims that it was written in Lisp.
I saw this for go all the time a couple of years back.
I wait for the day when someone adds "Written in COBOL" to their HN project title.
Technically somebody already has: https://news.ycombinator.com/item?id=24370792
Also: https://news.ycombinator.com/item?id=23189918 Not literally "in Cobol" in the title, but almost. And in both cases the primary novelty is that it's written in Cobol.
It's usually the only selling point.
I take it as tribalism.
Rust culture is a lot like socialism, libertarians, fundamentalist religions, vegans, etc. They see themselves apart from the "mainstream", as rebels, revolutionaries, etc.
In their beginning, Java and Python were like that, too. Lua, Haskell and Kotlin also do the same. Golang is more discrete.
I feel like "written in Go" is the at least the second most likely language to be pimped in an hn title.
it's written in rust is the only thing worth mentioning about it? congratulations on writing a thing that does something, i guess
The website states: "OpenVMM is a modular, cross-platform, general-purpose Virtual Machine Monitor (VMM), written in Rust."
I'd leave out the "written in Rust", because who cares, but I think it's in the license terms for Rust that you need to include that in when communication your project. The modular and cross-platform is much more interesting that the implementation language, and much more relevant for the majority of the users. I'd focus on that if I wrote the documentation and marketing material. One excuse I'd make is that the link is to the Github repository, where it's perhaps more relevant that you're informed that you'll be looking at Rust code.
Is that true? That the license requires the addition of "written in Rust" to announcements? I looked and couldn't find the requirement. But, agree generally with your points.
It was a joke, rust is under a normal very permissive set of open source licenses (MIT or Apache2 at the users option)
I think that might have been a joke.
That is a joke.
My bad. Face palm.
VMM == Virtual Machine Monitor, "such as Hyper-V, QEMU, VirtualBox".
Rust was something i thought was a cute little language years ago, much like i thought python was. I didn't pay attention for like 2 years and it feels likes it's everywhere and everything.
Time to learn.
A New Virtual Machine Monitor for Windows and Linux that happens to be written in Rust
A very interesting project. If I understand correctly it’s being used for Azure infrastructure.