Hacker News Reader

Comment by noobermin | Hacker News Reader

Ok, so I hate to be too direct but the rust enthusiasm always struck me as annoying like the meme about arch users telling everyone they use arch and so should you, but on that token, I always felt it strange given it's literally over something as mundane as a programming language choice. BUT, this as a reason seems to explain a lot more for why evangelists, particularly those in management type positions in large IT companies are pushing rust so much. Wanting to weaken the economic position of a certain type of developer makes a lot more sense.

View on HN

> Wanting to weaken the economic position of a certain type of developer makes a lot more sense.

Just more anecdata, but this isn't true for my company. We're hiring for Rust because we're seeing more and more clients take memory safety seriously (and ask specifically about it as a design consideration).

These things have a way of balancing themselves out: developers like Rust, so there will probably be an eventual "glut" of Rust programmers like there was for C++ programmers in the 1990s. But it's a multiparadigm language, so I don't expect there to be consistent wage deflation based on that (and especially not in systems, where finding competent engineers is a perennial problem).

> we're seeing more and more clients take memory safety seriously

Running your test suite with asan, msan, tsan isn't sufficient? From my experience you need to start doing really nasty things (which shouldn't pass code review) before the sanitizers won't find your issues.

There are plenty of things that ASan won’t catch, like misuse between contiguous allocations.

But that’s sort of tangential: the goal is to write software that’s correct to begin with, not poke holes in it with the testsuite after the fact. With Rust, I can pick third-party dependencies that I can be (vanishingly) confident don’t have memory safety issues; when I start a greenfield C++ project, any dependencies I bring in are now potential sources of memory unsafety in my code.

Do you vet all of your dependencies' code for unsoundness when using unsafe?

One of the guarantees that Unsafe Rust makes is that well-formed unsafe code cannot trigger unsoundness in safe code.

In other words: I very rarely write unsafe code myself. When I bring in others’ unsafe code, I use cargo-geiger and siderophile (which I help maintain) to quantify it.

It's not a guaranteed guarantee as far as I can understand.

Or such bugreports would make no sense: https://github.com/denoland/deno/issues/15020

The bug report says exactly what I said: if you don't write well-formed Unsafe Rust, then Rust will not make any guarantees about invariant preservation in Safe Rust.

This is exactly the same as in C++, except stronger: in C++, any piece of well-formed code can violate safe invariants. In Rust, only unsafe code can violate safe invariants, and can only do so if it isn't itself well-formed.

According to the RustBelt paper [0]:

> so long as the only unsafe code in a well-typed λRust program is confined to libraries that satisfy their verification conditions, the program is safe to execute.

I think the main caveat is that IIRC, the RustBelt unsafe rules do not cover ALL uses of unsafe in the wild, they analyze only a subset of Rust as whole, and of course, unsafe usage actually has to obey the rules. But I'm hardly an expert here.

That bug report basically says they broke the unsafe rules and thus the guarantee no longer holds (and there is UB).

[0] https://dl.acm.org/doi/abs/10.1145/3158154

I'm reminded of this quote, written in support of more and stronger use of systems for formal verification, like powerful type systems:

> Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence. -- Edsger W. Dijkstra, "The Humble Programmer" (1972)

Oh for sure, use better types to express the problem in ways that the compiler can catch mistakes. But... you do need to show at some point that your code actually does what you claim it does, even if just for a single use case; might as well piggyback sanitizers since you're running tests anyways.

Re: Dijkstra, I'm not trying to prove that the code has no memory errors, I'm trying to make sure none get triggered in production ie. the difference between computer science and software engineering. If there was a simple and easy way to do behaviour proofs I'd be happy to use that, but coq et al. are a real pain.

Surely you're joking, because I simply refuse to believe that you think Rust developers are actually sitting around thinking how to put other devs out of a job instead of, you know, using Rust simply because it's a better, more well designed language.

I didn't read it that way at all.

I read it as: where can we find a lower cost (than C++) pool of developers.

It's not particularly conspiratorial. Companies are always looking to expand their labor force and good C++ devs can be very expensive, so why would you want start a new project in C++? Security is another aspect altogether...

Companies don't care about cost, they care about bang for the buck. And this is where Rust has a clear advantage over C/C++, at least in many cases.

I'd actually prefer a GCed language, but Rust gets so many of the other things right that its still better than anything I've seen before (despite forcing a borrow checker on me).

I love that you can't accept the possibility that Rust is good so much that you had to come up with a genuine conspiracy theory to explain its popularity.

Buggy whip manufacturers were also concerned that the car was just a conspiracy to drive them out of business.

No Rust Evangelist is out there thinking, "Hm, how do I put C/C++ developers out of business today"

I see you do not have much contact with Rust evangelists.

I think they're thinking "how do we get those C++ businesses to switch to Rust" rather than "how do I bankrupt them".

They're thinking "how do we get those C++ businesses to stop hiring C++ coders, and start hiring us Rust coders instead".

The original purpose of Rust was to displace C, a laudable goal. But it is failing at that, because C coders are practically defined as people who will never switch to anything. (Any who might have did already.) So now the only hope is to displace C++ instead, and the propaganda machine is trying to paint C++ as equally as unsafe as C, which it manifestly is not, lying if that is what it takes.

Well, there is corporate financial interests involved, which is sure to push the propaganda machine into higher gear. Expect a lot more trash and FUD being thrown around by converted fanatics and speculators, in regards to all the "inferior" languages.

What issue is there for the C++ developers to transition?

Rust is a simpler language, with better characteristics. Memory safety is the a big selling point for the business people, but there is also a better module system, dependency management, better generics, no hidden memory allocation, etc. etc.

> What issue is there for the C++ developers to transition?

rust is lacking a ton of libraries.

And personally I prefer using a big thing like Qt which has classes for everything, rather than rust where I have to find a non-terrible library for every little thing.

Rust is not, in the end, a simpler language, in the same way C is not. It is able to do less, which leaves me needing to do more.

"Hey C++ developer, you should use rust instead" is very different than "Hey C++ developer, I don't want you to have a job".

Do you not see the difference?

I do. "New programs should not be in C++" means, exactly, "You should be laid off so they can hire me instead". If you had something that could do what I need, I would be using it already. It cannot. But you want to bypass me and fool managers, instead, with FUD about memory faults I don't code and have not in years.

I have spent strictly more time in the past five years filing compiler bug reports than chasing memory faults. Yet you say I should trust the compiler to make errors impossible. Are you able to see the flaw in your reasoning, here?

> "New programs should not be in C++" means, exactly, "You should be laid off so they can hire me instead".

That strikes me as wrong in many ways. I think it means, exactly - "new programs should use a different language than C++".

I someone writing that might have been implying "hire me instead", but given the specific author is CTO of azure, i doubt they are angling for your job, or really any dev job.

Managers hearing this advice from the CTO of could possibly interpret it as "lay off our C++ folks, we're hiring for rust". Or they could interpret it as:

* We should switch to the new language, have the team train up.

* We should have the team start evaluating new languages (or rust specifically).

* We hire some rust folks for the next project to evaluate how it goes.

Any half-way decent management will know that the institutional knowledge in their existing dev team is worth a lot, and getting the new hires up to speed is rather expensive.

Sure crap management exists, but I've never had, nor known any who has had management so bad that they would lay off thier whole dev team over a tweet. I really doubt "lay off all the C++ folks" would be a particularly common response.

The topic in this subthread is overbearing Rust evangelists and their effects.

To the degree that management pays them any attention -- and a CTO parroting their advocacy in tweets (squawks?) certainly counts -- the threat is real. Other companies' management may be equally affected, in a degree more than just posting idle-hack tweets.

Against, the subthread topic is overbearing Rust advocates and, specifically, what harm they can do. Obviously nobody will "lay off all the C++ folks" just because Rust promoters would really like that, and as much as say so. But that is very far from saying no harm is done, or that no one is harmed by their extremist rhetoric.

> Obviously nobody will "lay off all the C++ folks" just because Rust promoters would really like that, and as much as say so

1. If it was so obvious, why did you claim it to be true, and then double down?

2. I have yet to see anyone say or even strongly imply it. The closest I've seen is this thread wherein you take a lot of leaps in reasoning and a very specific path through a large possibility space to divine the true intent of a simple sentence.

It is one thing for people to advocate a thing, such as "you should fire all your C++ staff and hire us", and another thing for my employer to obey.

But that difference does not make advocating it less bad, unless they are obviously speaking facetiously and expect it to have no effect. It is very clear people saying it mean it and want that to happen.

Azure CTO's announcement is a success for that advocacy.

I think you are delusional. No one is advocating for your firing. "NEW projects" is not "all projects ever existing". Just like cobol is still there and running decades after it was first considered a dead language. Even after new projects were all being written in java, the cobol programmers were there. They switched languages, or kept working in cobol. There are still new cobol programmers in 2022.

Even if every C++ codebase wanted to rewrite itself in rust that effort would take decades and in the mean time we'd still need C++ devs.

The only people advocating for firing C++ all devs are the imaginary ones in your head.

Calling people delusional means you have no argument.

If my employer announced no new C++ projects, that would mean, at best, a sharp demotion. I would be relegated to maintenance of legacy products. The kind of systems I make would no longer be written, because Rust is not up to the job.

You reveal that what you are doing is fully as nasty as it seems. You reveal that you believe there wil be no room for your language without first tearing down another.

Have you even used Rust? Based on your other comments, it just seems like you have an axe to grind against anyone who uses Rust, coming up with accusations of "Rust devs trying to take 'er jerbs"

I like Rust fine. But Rust is not suitable for my work, where C++ is.

So, anyone saying "no programs should be written in C++" is saying, exactly, that I should not be able to do my work, and that I should not have employment.

That my current employer will not necessarily obey such an instruction does not make the attempt any the less offensive.

It's finally clear - You don't actually think that people are advocating for you to be fired[1]. You are just taking an absurd extreme position because after a career of not having to think too much about other languages something comes along that can actually threaten the C++ crown. Now you are worried that you'll be relegated to the niches along with your language, like assembler and cobol. Don't worry - there'll be room for you there even as C++ fades away: you can stay in the niches, or you can maintain the mountains of existing C++ code, or you can evolve and move forward with the rest of us.

You are a great case study in why the rest of us shouldn't comingle our identities with the identities of our tools.

[1] I did note that you changed it from "no new projects" to "no programs" a dirty trick that I'm only going to address by pointing it out.

Try to explain the difference between "no new projects" and "no programs". Any program I have not written yet would be a new project. Any old project is one where the program has already been written.

So you are being dishonest in pretending to a distinction without a difference.

Switching from the legitimate "you should use my new language because it is good" to "you should demote everybody coding <otherlang> to legacy maintenance, and put us in their place" admits a very ugly fact about yourselves and about your beliefs about your language's legitimate prospects.

If you believed it deserves a place on its own merits, you would not be trying to tear down other languages to try to make a hole for it. It is disgraceful behavior.

You should be ashamed of that, and you should be more ashamed of calling people who object "delusional".

> Any program I have not written yet would be a new project. Any old project is one where the program has already been written.

That is simply not any definition I've ever heard for a new project. You are assuming a binary of written or not written, and yet there are codebases that are incompletely written. That is what the parent means about ongoing projects that wouldn't migrate to Rust where you'd still be able to work on them, and who knows, maybe Rust won't overtake C++ and it'll continue, like many C projects have.

But that you have made yourself a "C++ developer," and not a developer in general who solves problems with whatever tool is best, does mean that whenever something comes along that threatens your identity, you seem to take it to absurdity, as the parent says.

You have already revealed your true colors.

No, more like you have, as others have pointed out.

Reply on news.ycombinator.com