Hacker News Reader

Comment by aliqot | Hacker News Reader

im so tired of non-substance rust content on hn. i dont want to know THAT it is written in rust (shocking, i know!) I want to know WHAT made it better to be in rust rather than x. I'd read the shit out of an article about that. its starting to become a meme cheatcode, just add "in rust!" to the end of your post title and you'll get a baseline starter pack of hn votes

View on HN

I was going to add a boring "me too" reply. But then I re-wrote it in Rust and it's now 10 times more insightful!

I am going to have to borrow this comment.

For how long?

For their entire 'lifetime.

The constant Rust spam on the front page makes me think that there may be some sort of pro-rust bot that upvotes them. There probably isn't, just a lot of enthusiasm, but it's tiring.

However, it has also convinced me that Rust isn't faster than C++ in practical applications, thanks to the number of "we moved our C++ codebase to Rust" blog posts that have 0 benchmarks. You can practically guarantee that if their code had gotten faster, they would have said something about it. That has dulled my enthusiasm for the language significantly.

Also, it is humorous to me to see blog posts that say, "[Rust feature that causes inconvenience] enables compilers to do [compiler optimization that C++ compilers already do]."

>Also, it is humorous to me to see blog posts that say, "[Rust feature that causes inconvenience] enables compilers to do [compiler optimization that C++ compilers already do]."

What? You can't safely do strict aliasing in C++ and even if you did, it was broken anyway to the point where the Rust compiler had to disable it because of LLVM bugs.

https://github.com/rust-lang/rust/issues/54878#issuecomment-...

https://news.ycombinator.com/item?id=25624538

Strict aliasing maps to TBAA in LLVM; the buggy feature is noalias, which corresponds to C's restrict.

The restrict keyword historically has meant "I know these pointers are different, please optimize as though they are." It had nothing to do with correctness. It is quite tricky to check for correctness in the general case of this kind of keyword.

> The constant Rust spam on the front page makes me think that there may be some sort of pro-rust bot that upvotes them. There probably isn't, just a lot of enthusiasm, but it's tiring.

I get it; we all have our annoyances. Personally, the above kind of comment is tiring. Complaints about what makes the HN front page seem like a waste of energy. How can we contribute to moving the conversation forward? By "forward" I mean learning from each other, sharing ideas, and other constructive goals.

P.S. If you don't want to see [keyword] in HN, there are probably browser extensions that can help you.

The problem is that I am interested in Rust's development and I do want to see the Rust keyword, when the content is substantive. For example, there is another front page post right now about Rust and Haskell, which is an interesting commentary.

The complaint is about the input not the output.

>>> pclmulqdq: The constant Rust spam on the front page makes me think that there may be some sort of pro-rust bot that upvotes them. There probably isn't, just a lot of enthusiasm, but it's tiring.

>> xpe: ... Personally, the above kind of comment is tiring. Complaints about what makes the HN front page seem like a waste of energy. ...

> 0xdeadbeefbabe: The complaint is about the input not the output.

Explain, please. What is the input? The output?

As far as I can tell, the input is the low-effort "I like Rust but have no insight" blogs. The output is their appearance on the front page of this website.

The constant complaining about Rust posts may suggest that opposite is true. Why don't you follow other topic if you are not interested in Rust. You are free.

I am interested in Rust. I am not interested in takes like this one, or a lot of the other "I love rust" content that lacks technical substance.

Why don't you put your interest and desires together and make something like that? I'm sure the people who are at least trying to do something would welcome the example.

Hello sir, I'm here to resolve your doubts

https://goodmanwen.github.io/Programming-Language-Benchmarks...

compared to what rust has to offer, compared to C and CPP, this is truly awesome.

The funny thing is that posts like these are fine and upvoted heavily. But if someone make a post like: Tiobe states that "C++ is language of the year 2022", then its either flagged or utterly downvoted to death.

The Rust fanatics have VERY thin skin if the language they hate gets any upward-adoption news.

My code got faster, and removed memory safety issues, but I got no upvotes :P

I wouldn’t care if Rust were 10x slower. Just within my career, computers have become 1000x faster. We can definitely afford a stack that might actually work.

Usually everyone knows what made it better to be in Rust, especially when it comes to C and C++.

N=1, but I don't always know what made it better in Rust.

I've never seen a need to use rust, and regularly work on small projects in C. As far as I can tell, there isn't really a compelling reason to switch.

Security / memory safety and preventing concurrency bugs

Security is an especially big one for lots of systems

You can just toss out names of qualities and it might impress someone with no experience but to the rest of us we're just waving our hands like "ok.. and then?" waiting for the substance, which this comment provides none of

I'm not sure I agree. If anything someone with experience has first-hand knowledge of the perils of buffer overflows, double frees, and other memory bugs. Sure we can go into more detail but it's a little disingenuous to act as if someone with experience writing C would not be able to fill in the blanks.

>someone with experience writing C would not be able to fill in the blanks.

"yeah well if you're smart you wouldn't need explanation"

except the people you're swaying with such remarks aren't the ones who already know, its the ones who are afraid to ask lest they be judged so they just kinda laugh along and parrot the smartest-bully.

I have never worked with Rust but seeing major operating systems and critical softwares gradually adopting, and other developers reporting less segfaults when replacing their codebase with Rust is convincing enough for me to try it out.

Comments like this make me think that you have never worked in a domain where safety is paramount (like avionics or medical technology).

People who are developing in these domains are typically using a strict subset of c or c++ and running their programs through a process of formal verification.

As far as I am aware, rust has no specification to formally verify, and the formal verification tools are all out of date (because of the rapid pace of language changes) or lacking (for example Miri lacks the ability to consider all input values because it executes your code the same way as it would normally run)

This key!

The wealth of formal verification tools in the safety critical c and c++ world is very high. Those tools, not the compilers are what get validated during tool qualification. Ultimately it is about the formal verification, static analysis and dynamic analysis tools, as well as, traceable code execution, robustness tests etc.

A formally verified rust compiler could really be a game changer, but until then, the tools do exist to write safe c and c++, but they are expensive and adherence is low outside of the places they must be used

Ferrous Systems is “on the last legs” of qualifying the compiler for a few different safety standards. It is true that Rust is behind in these domains, but it’s only a matter of time.

Most people aren't. I understand the hype on one level. It's fun to do great work and build high quality things. OTOH, What most of the world needs is "good enough" work rather than great work.

I haven’t, and interesting to know that C++ is used there!

I’m referring to systems software (operating systems, browsers, runtimes, backends) where formal verification is not normally used.

My impression as a non-expert who has only dabbled in Rust is that while it is ‘easy’ by design to write memory-safe code, it is relatively difficult to write panic-free code, and by and large the ecosystem doesn't try. (I know about `no_panic`.) In some domains (e.g. the rust-analyzer panic discussed here yesterday¹) this is fine; in others “this is fine”.²

The first Ariane 5 launch is an example of the latter. The code was written in a ‘safe’ language, Ada. A conversion overflow (that, as it happened, was in fact genuinely harmless) triggered a panic that (by design) brought down the subsystem, and with it the rocket.³

¹ https://news.ycombinator.com/item?id=34775549

² http://gunshowcomic.com/648

³ http://sunnyday.mit.edu/nasa-class/Ariane5-report.html

Interesting point.

I allow for panics when the panic is expected to never execute, i.e. logic errors.

I see how it can be problematic, and thought of adding a general logic error for such cases. However, it adds work for devs and the machine.

Still, panics can happen for allocations, where I don't know a solution.

Would you consider this as a problem as well?

If not, no_panic should suffice, right? Yeah, it might make things harder, but for rockets you probably won't use that many external crates and a bit more work should be acceptable, shouldn't it?

What would you like to see the devs and the lang team to do?

I'm not knowledgeable enough about Rust's actual current state and plans to make concrete suggestions. Given the wide interest in Rust for security, I do think it's likely that in the long run significant effort will go into avoiding DOS-by-panic.

I think it's unfortunate that LLVM had no popular small targets during Rust's early years, so it didn't get much attention from embedded devlopers. Heap allocation is one place where this shows. It's not really worse than C++, though, where in principle many parts of the standard library can use a custom allocator, but handling errors is awkward, and in practice the ecosystem doesn't try. C and C++ standards also don't generally specify which library components are allowed to perform heap allocations internally.

C and C++ have ended up with small parallel ecosystems for such use cases. Since Rust aims to have one true ecosystem under cargo, it might be nice if library components could be explicitly tagged as panic-free, heap-free, etc.

Rust doesn't exactly have things tagged as heap-free, but no_std category[1] contains many crates who have at least indicated that they don't use the standard library. Some may pull in liballoc and still want to do allocation, but it's better than nothing. Additionally, many packages that normally require the standard library let you opt out of that, with reduced functionality.

My team works in no-heap Rust. We use external packages. It's much easier than in any other ecosystem to do so. Even that bit above goes a very long way and saves a lot of work.

1: https://crates.io/categories/no-std

I wrote a small service to synch the datetime based on a gps/imu module with an ethernet interface. It needed to be rock solid because it was going to fly in the field (scientific instrument, not avionics). It was faster and easier to write in Rust, despite having no one else with Rust know-how in the company, the rest of the system components in C++/Python, and several months of of c and c++ experience myself. I barely knew rust and yet felt way more confident the program didn't have weird unexpected edge cases, leaks, etc. Not to mention way more ergonomic.

Rust and Golang projects are generally more interesting as they generally are small static binaries and have the lowest friction to try out/deploy.

It's almost the opposite effect of all the comments that appear on Electron projects regarding bloat.

There was an accumulation of trust in the fact that most rust rewrites would yield interesting results. So the gates are wide open now.

> shocking, i know!

How is most generic comment under HN Rust topic shocking?

It's just over-correction for past criticisms of other loved languages.

"Oh yeah? If X is so good, why aren't there any real software projects written in it?" etc.

Reply on news.ycombinator.com