Hacker News Reader

Comment by dfabulich | Hacker News Reader

IMO, this is because there's a general attitude about porting to Rust that porting to Rust, by itself, makes a material improvement in the quality of the software (e.g. reliability, performance, readability), and that these improvements that can't be achieved in C/C++. Entrenched C developers then rise to the debate to defend their language.

This debate has happened often enough that any time someone ports something to Rust, even if it's just for fun or for the author to learn more Rust, C/C++ advocates see it as an attack on their language, and bite back.

View on HN

...hey everyone, I made a C/C++ developer blood pressure checker in Rust.

Your entire program should be wrapped by unsafe{}.

The only attack I feel is calling C/C++ a language. It's two languages and we don't like each other very much. People who spend a lot of time trying to write good C++ avoid much of C's bread and butter like malloc and free, and the general hatred of C++ from C developers is well-documented.

I happen to prefer C++ to C and D to both.

I have never treated "C/C++" as the name of a single language. I always read it as "C and/or C++".

They are so often spoken of in the same breath in ways that other languages are not, that I think a lot of people do forget that they are not the same thing nor even that culturally close.

Going to be honest, whenever I see or hear someone put them in the same category, it usually colors my impression of said person as essentially never really learning C++.

Eh, I'd call them culturally close. I always read it as "the most common systems programming languages", since that's how the phrasing is usually used.

Even that can be disputed. They typically have quite different domains of applications. Gamedev is seldom done in C; operating systems are seldom done in C++. Their different level of abstraction ends up having them applied to different things.

I would assume a lot of recruiter-types or folks just getting their feet wet into programming would assume C++ is just a newer or more powerful "Edition" / "Version" of C.

> we don't like each other very much

Hi are you a language?

People are actually claiming that Rust is more readable than C?

Forrest vs trees..... Sigh

It depends what you call “readable” I guess, if you think it as : “I can have a glance at this code and feel comfortable”, then obviously C is more readable than Rust, because Rust has a quite a few specific syntaxes that will feel alien to anyone not accustomed. But I'm not sure this metric is relevant.

And on the other hand, if you call “readable” the ability of someone knowing the language to get on board of an existing project, understanding the control flows and feeling confident to make changes, then Rust wins easily because the type system gives you all the information you need straight in front of you.

The first time I had a look at Servo[1], I was able to change what I wanted (which were quite a lot of thing: a few dozens of lines in something like 5 or 6 different files) in a few hours. And when I compiled it it worked fine. Good luck doing the same with a C project you just discovered. And I wasn't even a professional Rust programmer at that time.

[1] the experimental browser engine form Mozilla

Which information in particular is missing from the C type system in your opinion?

For better or worse, Rust has a lot more built into its type system, including semantics for type safe generics and safe memory management. This makes it harder to write a correct Rust program, but also it makes it harder to write an _incorrect_ Rust program.

The two major important improvements Rust type system brings are :

- the ownership of your object (who is in charge of free-ing it) and the lifetime of the pointers that targets this object. (the whole ownership system & the borrow-checker)

- is some data-structure thread-safe. (the Send and Sync traits)

With those, you can take any Rust code and play with it without having to ask existential questions. Your code will never segfault or exhibit a strange intermittent bug ones you add multi-threading.

Less important but still really convenient on a daily basis:

- will this function mutate the value I give it. (&mut pointers)

- has this variable already been consumed, which means I should not touch it anymore (affine type)

> the ownership of your object (who is in charge of free-ing it) and the lifetime of the pointers that targets this object. (the whole ownership system & the borrow-checker)

Having to bear the cognitive burden of making the lifetime explicit in all of the code is a steep price to pay for the benefit of securing the small subset of the code that is actually complex enough to potentially cause a problem. I wouldn't mind having such a feature be optional though, so that you'd enable it for the most precarious parts, something like a safe{} block rather than unsafe{}.

> will this function mutate the value I give it. (&mut pointers)

We already have const. Yes I agree it's better to enable by default.

Does rust have something like shared pointers? In c++ that's usually a quite easy way to bail out of the cognitive burden of understanding complex lifetimes.

We have two! Rc is non-atomic, and therefore not threadsafe. Arc is atomic, and therefore threadsafe. The compiler can let you know if you are using Rc inappropriately, so you get some extra speed if you are single threaded.

> Having to bear the cognitive burden of making the lifetime explicit in all of the code is a steep price to pay for the benefit of securing the small subset of the code that is actually complex enough to potentially cause a problem. I wouldn't mind having such a feature be optional though, so that you'd enable it for the most precarious parts, something like a safe{} block rather than unsafe{}.

It's obviously a learning curve burden but now that I use the language on a daily basis, it doesn't really slows me down. The thing is you don't often need to annotate the lifetimes by hand since the compiler elides the most common case. In practice, the time you need to do the annotation is often what you call «actually complex enough to potentially cause a problem».

> then Rust wins easily because the type system gives you all the information you need straight in front of you

The trait system can actually make following execution a bit harder (just like runtime polymorphism in C++), because you have to find the allocation to know the concrete type of what you're looking at. C is much clearer from this point of view (but more limited for the same reasons).

Cough!, void pointer, cough!

Traits are used to express generality, when you need it. If you don't need to be generic over your input, you don't need traits. And when you need it, Rust makes it more explicit than C (and also more performant because it's statically dispatched by default).

I think you're eliding a lot of context here. Specifically the context of overzealous Rust fans. There's a strong, though not universal or even majority sentiment that "writing anything in C or C++ is basically the same as committing assault, murder, professional malpractice or other similar hyperbolic claim" that some Rust advocates engage in.

There's a whole meme about the "Rust Evangelism Strikeforce" on n-gate.com for a reason, and that reason is the community on HN has become a caricature of itself.

By the way, this is from a person who made a point to introduce Rust to the team, when even just a year or so ago I'd have preferred C++.

>eliding

Incidentally, I learned this word from Rust docs (lifetime elision). I'd never seen it in any other context.

To provide some supporting evidence for this, a choice comment made a couple of days ago:

> Rust has many benefits and I find it hard to imagine how anyone manages to get any performance-sensitive work done in the cryptocurrency industry with anything else.

I've seen every single thing I mentioned ("murder, assault, malpractice") applied to C++ programming in comments in Rust threads.

Javascript runs everywhere where there is a browser.

Rust runs everywhere where there is a c compiler, which is funnily enough the sample places that C/C++ run.

And with wasm, Rust/C/C++ all can run in the browser too...

Not quite yet. But getting there.

pretty much there: https://www.hellorust.com/setup/wasm-target/

JS in the browser has direct integration to the DOM, networking, various local data persistence APIs, and other IO and sensors (webcam, accelerometer...) etc. Rust can be compiled to run in a sandbox, which can then be integrated via a remote call interface with the JS layer, and thus be indirectly (via JS) connected to the above APIs, but there are currently concerns around the performance of this approach. Rust cannot independently manage a web page which hosts it, without JS. There is some way to go before browsers support practical, accessible and performant front-end web apps in Rust.

When people say “The Browser” they mean “that thing which is on literally every computer where you instantly load that one kind of software”.

People think the web is a technology, or that JavaScript is a language.

They’re not. It’s not. The web is an idea: it’s the idea that every computer in the world already has the runtime on it that can run your next app. Whatever that is—whatever that runtime is—that’s “The Browser”.

WASM is not that. Maybe in 10 years.

emscripten can compile to both wasm and asm.js and load them depending on browser support. this seems good enough.

Performance won’t be as good as hand tuned JavaScript with native DOM calls.

webassembly has vastly improved performance in a variety of situations.

What are you babbling about? The web is technology. JavaScript is a language. And WASM is shipping in all major browsers already.

You don't have to wait 10 years. You can start using WASM today.

It hurts my feelings that you think I’m babbling. I’m trying to be as articulate as I can.

I don’t want to write software just for people with 2 year old iPhones. I write software for everyone, especially people who can’t afford anything but the hardware they’re stuck with. That’s why I’m not going to target WASM.

That’s my point: to me, “The Web” isn’t just modern browsers on newish devices. It’s the whole world as an audience. I think that’s why so many people target the web.

I also think WASM is premature optimization in almost all situations.

That said, I totally support anyone who wants to target it. It’s dope technology. If you love Rust and you want to write browser apps with it, and limit your audience a little, knock yourself out. I don’t think you’re embracing what the web is for, but there’s no law that says you have to.

afaik webassembly has shipped in all major browsers - edge, firefox, opera, chrome and safari... including mobile versions.

If your audience can exclude the very poor and people with extreme bandwidth limitations ( for updating OS, etc), or you can afford to just tell people “no” then that’s certainly a decision you can make. But you’ll be saying no to a lot of people.

i'm sorry but i don't quite follow what you're trying to say.

I’m getting a lot of pushback in this thread so I’ll put this in the “maybe I’m wrong bucket”.

I’ll wait to talk about it again until after I have experience doing browser compatiblility testing with a WASM toolchain.

You're aware that most operating systems have a C API, right? Give me a place C doesn't run where js does.

In a browser. Yes, there's wasm, but it has a lot of limitations that don't apply to JavaScript. fineline had a good comment about it upthread: https://news.ycombinator.com/item?id=17088315

https://github.com/kripken/emscripten

Try to use the C API on Android, ChromeOS, Windows Phone, Mbed.

You mean wherever there is llvm? It's a large subset, but it is still a subset.

Huh til that rust isn't compillable by gcc.

That's different. The rust toolchain is compiled by rust, and it relies on LLVM which can be compiled by GCC. But LLVM does not have a backend for every architecture (or even if it does, it might require extra effort from the Rust compiler using it and they have not enabled support for _everything_). Thus not all architectures can be targets for Rust programs.

I'm not sure on the last point, a lot of architectures, especially niche ones, aren't supported by Rust at all while there are plenty of C compilers for them going around.

(have fun trying to get Rust working on 8bit controllers or Itanium/ia64)

I think the point is less that Rust runs everywhere that C runs, and more that there doesn't exist an environment that can run Rust and not run C (which is not true for Javascript)

Can you clarify this point? To me it would seem with Rust being able to target WASM/ASM.js that you could indeed target all the same environments JS does.

Emscripten means that's not a distinguishing feature from C or C++.

My response was to the last part that there's an environment where Javascript can run but Rust can't. I agree that C/C++ targets are a strict superset but I'll posit that for all the architectures that matter it's the same surface area at which point the calculation for which to use is about ease-of-use, correctness, etc.

Reply on news.ycombinator.com