Wait, isn’t this a soundness issue? Couldn’t you, say, replace malloc with a safe function that always returned 0x4 [0], causing segfaults with no unsafe?
Calling platform functions are always unsafe. In the case of malloc, the standard library wraps calls using a safe interface. This assumes that malloc is implemented to spec because there's no good way to handle it otherwise.
Another defence for Rust as if all the problem is with C, Rust will magically make everything safe (however unreadable and not really true). This is another form of marketing Rust, in itself Rust has a steep learning curve and not developer friendly so require constant barrage of hype. It relies on C++ based LLVM for generating binaries like many other languages and underlying unsafe C library for doing anything useful.
It cannot yet be used extensively in Firefox for what it was designed, hope it can accomplish its primary goal for building Firefox sooner.
Nowhere in my comment did I mention C, Firefox, learning curves or marketing so I'm unsure what you're replying to.
To be clear, this issue isn't about Rust, the language. This is about Rust's standard library creating a safe abstraction around platform functions (although altering `memcmp` et al would affect how certain language features are implemented).
And it doesn't matter what language malloc is written in. It could be Python, C, Rust or brainfuck, the issue is the same. Rust's standard library assumes it is implemented to spec. I'm not sure that it could or should do otherwise.
Any language is going to have to rely on some unsafe foundations to do anything useful. That isn't a meaningful criticism.
If you build a 100,000 line code base, would you rather that all of it could potentially have data races and buffer overruns, or that only malloc and some syscalls can?
Rust is absolutely not easy as you say, but neither is C or C++.
There has never been, nor will there ever be, any language in which it is the least bit difficult to write bad code; the difference is that Rust provides better ability to notice that you've done it wrong.
The unsafe beast hides in unexpected places. That being said this one is not too bad in my opinion, it's fairly unlikely to occur accidentally (if you use no_mangle you're probably dealing with unsafe interfaces anyway) and it doesn't really invalidate any of Rust's core principles and models, it's more like a plumbing issue in the linker.
It would be nice if these programs failed to link however.
Yes, and not only no_mangle, but anything that has to do with linking in general can make safe Rust programs unsound (e.g. use LD_PRELOAD to change the malloc implementation at run-time with dynamic linking, and put in a broken/buggt malloc implementation instead).
The TL;DR is that safe Rust is only sound, if the safe APIs it uses are sound, which requires their implementations to be sound (Derek Dreyer et al. [0]). That is, the soundness proofs a Rust's compiler gives you only apply to Rust programs with sound unsafe code.
If you exchange the malloc implementation with an unsound one, then the soundness proofs the compiler provides just don't apply to your program anymore (they apply only to programs with a sound malloc implementation).
---
Being able to worry about soundness in this space is kind of a luxus problem, but probably still one the most interesting aspect of Rust. Like, with C or C++, there is little discussion about soundness because most of the language is already unsound. Like, not even MISRA C tries to make a subset of C sound, just "less dangerous" or "less likely to make mistakes".
The big deal of Rust is that it modularizes soundness proofs, allowing users to prove different modules of their program "conditionally sound", e.g., sound _if_ everything they use is also sound. Most Rust code on crates.io is close to 100% safe Rust code, and that code is already "conditionally sound". This means that you only need to manually prove the remaining 1% of the unsafe Rust code correct, which is a much more tractable problem, than trying to prove 100% of the code correct.
This allows people to refactor that 1% of the code into tiny modules, that each can be proven correct in isolation, and that allow changes to be more precisely scrutinized.
The impact of this is huge. You can refactor pretty much all code you write without worrying about soundness, only needing to worry about it if you need to change one of those tiny modules.
Heh, was gonna link that bug :) But there's an even simpler way: open /proc/self/mem in read-write mode.
"Rust is safe" means something like, if you write code to do a thing, it doesn't unintentionally lead to memory corruption. Opening /proc/self/mem is being fairly intentional about it. Colliding with a C function in another library could be unintentional, which is why I opened that, but most of the time (as with the blog post) it's fairly deliberate and obvious.
You can't blame most of the users here upvoting all Rust related posts as a way of accepting the Rust propaganda, especially upvoting every tiny minor release.
Even as a user of Rust, I won't be surprised to see the responses here expressing their fatigue of constant news and blogposts about the Rust parade banging their pots and pans every day on HN.
I upvote minor Rust releases when I like something in the blog post/release notes, certainly not just because it is Rust. Maybe other people do the same.
I don't want to argue or get downvoted by the Rust fans, just let me share my impressions , we see a lof of submission on the fitst base that are fo form "X made in rust". If X is a kernel or some critical library is fine that you emphasize rust but in the other cases X should be upvoted on it's merits not the fact somebody is learning Rust and poorly re-implements X . Would you like to see the same X this time in Y? Do you want to see every point release of other languages? any point release of some framework? any My first Hello World in X ?
I think new releases (not point releases ) are fine and personally i am intereseted to see what's up with Firefox and Rust - I see the new Firefox releases but nothing int he artciles mention the Rust progress. Btw I do not downvote or flag any submissions, if the community upvotes them then I have to accept it even if I disagree.
Maybe Rust fans could set up a mailing list instead of polluting the HN submission mechanism?
There is no other language that I'm aware of that does this and 'what if everybody did this?' is usually a very good indicator of whether or not a certain behavior is acceptable or not.
Consider: Rust fatigue is going to harm Rust adoption, not help it, publish your major releases widely, keep point releases of social media such as HN. The same thing happened to Perl with its zealotry, and it never recovered.
There's a lot of enthusiasm around Rust on HN (I share a great deal of it) and it's probably a bit excessive at times, but here it's about a safety issue with Rust which is not exactly good publicity.
> Is it deliberate, or are random people just trying to get some filler for their CVs?
Both. The community mostly does the former which is done on purpose and is their way of marketing the language for the best exposure and releases are announced simultaneously across all social media platforms. On HN, once it's appears in new, they all race to upvote it to the top.
The later appears to be applicable for its users who post blogposts like this one to be potentially used in interviews for jobs in Rust.
But then again it appears that the Rust community has hired a town crier to blast their trumpet about all things Rust almost every day right in your face. That is the most aggressive form of marketing I have ever seen for a programming language.
When you're referring to marketing you seem to imply there's some sort of marketing budget in play to achieve some sort of monetary gain in the end? I'm not sure what that would be though.
In the meantime I'm using Rust for some personal projects and I'm having way more fun than I ever had with C++. Even procedural macros are a ton of fun to write compared to the template hell I'd face in C++ (although I'm eager to spend some time with concepts).
> That is the most aggressive form of marketing I have ever seen for a programming language
_Oracle has entered the chat_
Yeah the Rust hype machine is a bit zealous, but I don't think it's entirely unfounded. Rust genuinely solves (or tries way better to that past langs) many problems that plague programmers and computer systems.
I myself have barely used it and yet despite the steep learning curve (boy is it steep) I already enjoy it way more than C++ (let alone java, ick), and I'm sure it'll be more fun once I grok ownership.
This is another form of marketing Rust, in itself Rust has a steep learning curve and not developer friendly so require constant barrage of hype. It relies on C++ based LLVM for generating binaries like many other languages and underlying unsafe C library for doing anything useful.
It cannot yet be used extensively in Firefox for what it was designed, hope it can accomplish its primary goal for building Firefox sooner.
That's a really shitty comment. The author is a long term Rust contributor and has spent their time before on C-land a lot. Yes, he knows how a linker works. Others don't.
He took his time to write down something, because some beginners asked him on Twitter.
Someone posts it on Hacker News and you shit over it like this.
If the post is too mundane for you, so be it. You're not the audience.
And this got down-voted into oblivion, of course.
Rust fanatics are a very fragile crowd and they don't like to hear that other people might not be interested.
Yes, but seriously Steve, this is getting out of hand and is harming Rust, not helping it. If the price of general Rust adoption is the destruction of HN then I would rather pass. Get some discipline in there or I'll start flagging each and every submission that has Rust in the title as a counterweight or petition that having 'Rust' in the title penalizes a submission. HN is a commons, not a private mailing list for Rust fans.
I don’t know what kind of “discipline” you expect me to have. I just post here like everyone else. I’m in charge of no one.
Feel free to flag things; that’s what you’re supposed to do. You could also do what I do: ignore topics I don’t care about. There’s a lot of content on Hacker News.
You're in charge of no-one but you are seen as influential within the Rust community, if you would make a statement that spamming HN with Rust articles does not help Rust at all that would likely carry some weight.
I think you have some basic assumptions that are leading you astray.
For example, two of the stories that landed on HN today paint Rust in a negative light; if I were trying to promote Rust, I wouldn’t be submitting them. If this were being done by the Rust community as a promotional tactic, it would be misguided.
I remember reading it was everyone's favorite weekend language. There's certainly more people using it over the weekend than using it professionally. Maybe that's why there's so much of here today.
People often mistake Rust's safety guarantees for a sandbox like JavaScript. "Safe" Rust code is still on the trusted side of the airtight hatchway[1], so hacks like that are a class of "arbitrary code execution leads to arbitrary code execution".
I this didn't lead to a "duplicate method definition" error by the linker. The more typical way I know for mocking/intercepting OS functions is using the -Wl,--wrap=clock_gettime linker flags [1] which allow to redirect calls to a __wrap_clock_gettime functions. But that doesn't seem to have been necessary here.
54 comments
[ 3.1 ms ] story [ 112 ms ] thread[0]: chosen by fair dice roll
EDIT: yep, https://github.com/rust-lang/rust/issues/28179
It cannot yet be used extensively in Firefox for what it was designed, hope it can accomplish its primary goal for building Firefox sooner.
To be clear, this issue isn't about Rust, the language. This is about Rust's standard library creating a safe abstraction around platform functions (although altering `memcmp` et al would affect how certain language features are implemented).
And it doesn't matter what language malloc is written in. It could be Python, C, Rust or brainfuck, the issue is the same. Rust's standard library assumes it is implemented to spec. I'm not sure that it could or should do otherwise.
If you build a 100,000 line code base, would you rather that all of it could potentially have data races and buffer overruns, or that only malloc and some syscalls can?
Rust is absolutely not easy as you say, but neither is C or C++.
What do you mean by this?
Here's an extensive list of Rust components within Firefox - shipped, in progress, and proposed:
https://wiki.mozilla.org/Oxidation#Shipped
It would be nice if these programs failed to link however.
The TL;DR is that safe Rust is only sound, if the safe APIs it uses are sound, which requires their implementations to be sound (Derek Dreyer et al. [0]). That is, the soundness proofs a Rust's compiler gives you only apply to Rust programs with sound unsafe code.
If you exchange the malloc implementation with an unsound one, then the soundness proofs the compiler provides just don't apply to your program anymore (they apply only to programs with a sound malloc implementation).
---
Being able to worry about soundness in this space is kind of a luxus problem, but probably still one the most interesting aspect of Rust. Like, with C or C++, there is little discussion about soundness because most of the language is already unsound. Like, not even MISRA C tries to make a subset of C sound, just "less dangerous" or "less likely to make mistakes".
The big deal of Rust is that it modularizes soundness proofs, allowing users to prove different modules of their program "conditionally sound", e.g., sound _if_ everything they use is also sound. Most Rust code on crates.io is close to 100% safe Rust code, and that code is already "conditionally sound". This means that you only need to manually prove the remaining 1% of the unsafe Rust code correct, which is a much more tractable problem, than trying to prove 100% of the code correct.
This allows people to refactor that 1% of the code into tiny modules, that each can be proven correct in isolation, and that allow changes to be more precisely scrutinized.
The impact of this is huge. You can refactor pretty much all code you write without worrying about soundness, only needing to worry about it if you need to change one of those tiny modules.
[0] http://plv.mpi-sws.org/rustbelt/
"Rust is safe" means something like, if you write code to do a thing, it doesn't unintentionally lead to memory corruption. Opening /proc/self/mem is being fairly intentional about it. Colliding with a C function in another library could be unintentional, which is why I opened that, but most of the time (as with the blog post) it's fairly deliberate and obvious.
Even as a user of Rust, I won't be surprised to see the responses here expressing their fatigue of constant news and blogposts about the Rust parade banging their pots and pans every day on HN.
I think new releases (not point releases ) are fine and personally i am intereseted to see what's up with Firefox and Rust - I see the new Firefox releases but nothing int he artciles mention the Rust progress. Btw I do not downvote or flag any submissions, if the community upvotes them then I have to accept it even if I disagree.
There is no other language that I'm aware of that does this and 'what if everybody did this?' is usually a very good indicator of whether or not a certain behavior is acceptable or not.
Consider: Rust fatigue is going to harm Rust adoption, not help it, publish your major releases widely, keep point releases of social media such as HN. The same thing happened to Perl with its zealotry, and it never recovered.
These people cannot survive in an open environment.
Both. The community mostly does the former which is done on purpose and is their way of marketing the language for the best exposure and releases are announced simultaneously across all social media platforms. On HN, once it's appears in new, they all race to upvote it to the top.
The later appears to be applicable for its users who post blogposts like this one to be potentially used in interviews for jobs in Rust.
But then again it appears that the Rust community has hired a town crier to blast their trumpet about all things Rust almost every day right in your face. That is the most aggressive form of marketing I have ever seen for a programming language.
Or maybe there's something to this language that justifies the hype or It's a plain conspiracy, we'll never know :D
In the meantime I'm using Rust for some personal projects and I'm having way more fun than I ever had with C++. Even procedural macros are a ton of fun to write compared to the template hell I'd face in C++ (although I'm eager to spend some time with concepts).
Unpleasant "community", I'll stay with C++.
Enable showdead in your HN profile, then you can read flagged/dead comments.
Klabnik rules with an iron fist. No wonder Graydon Hoare has left this circus.
_Oracle has entered the chat_
Yeah the Rust hype machine is a bit zealous, but I don't think it's entirely unfounded. Rust genuinely solves (or tries way better to that past langs) many problems that plague programmers and computer systems.
I myself have barely used it and yet despite the steep learning curve (boy is it steep) I already enjoy it way more than C++ (let alone java, ick), and I'm sure it'll be more fun once I grok ownership.
Go is more fun though ;)
That’s the only relevant point I ever saw mentioned, others being already addressed by a lot of languages, for example F# and C#.
It cannot yet be used extensively in Firefox for what it was designed, hope it can accomplish its primary goal for building Firefox sooner.
He took his time to write down something, because some beginners asked him on Twitter.
Someone posts it on Hacker News and you shit over it like this.
If the post is too mundane for you, so be it. You're not the audience.
Rust is not the only thing I come here for.
It's sad, but HN is becoming just like reddit.
As always, emailing the mods is more productive than complaining in threads.
Feel free to flag things; that’s what you’re supposed to do. You could also do what I do: ignore topics I don’t care about. There’s a lot of content on Hacker News.
For example, two of the stories that landed on HN today paint Rust in a negative light; if I were trying to promote Rust, I wouldn’t be submitting them. If this were being done by the Rust community as a promotional tactic, it would be misguided.
https://news.ycombinator.com/newsguidelines.html
[1]: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
[1] https://drewdevault.com/2016/07/19/Using-Wl-wrap-for-mocking...