Rust is not a good C replacement • Hacker News Board

Re: Rust is not a good C replacement

#131

Post by chessturk » Mon, Mar 25, 2019, 4:23 PM UTC

steveklabnik wrote: post #122

chessturk wrote: post #117

Sincere question, I didn't realize that Rust didn't have a specification. How can folk say Rust guarantees safety when it doesn't guarantee an implementation? I don't see how you could have one without the other. Now, admittedly, the lowest level language I've used is Go!, so fairly abstracted (and no memory management), so I might be mistaken, but it doesn't seem like you can have safety without a specification.

> How can folk say Rust guarantees safety when it doesn't guarantee an implementation? Just because there isn't a formal spec, doesn't mean that the underlying systems aren't built with some rules, grounded in computer science and math. We believe that the systems we've set up do guarantee those properties, even if they haven't yet been formally verified. And a subset of them have been formally verified, which also i…

> Put another way: not all specs are equal. Some are formal, some are informal.

So is the argument that the language reference is as good as many existing language specifications, and my complaint is only one of semantics?

Re: Rust is not a good C replacement

#132

Post by chessturk » Mon, Mar 25, 2019, 4:35 PM UTC

postalrat wrote: post #58

fxfan wrote: post #21

If OP thinks Firefox is one of the largest C++ codebases in the world then OP has a very limited worldview.

How many thousands are larger? Now how many thousands are smaller?

Taking a total shot in the dark, but I imagine AAA video games constitute a crap-ton of C++ codebases larger than Firefox, but I wouldn't know for sure.

Re: Rust is not a good C replacement

#133

Post by MuffinFlavored » Mon, Mar 25, 2019, 4:39 PM UTC

steveklabnik wrote: post #16

MuffinFlavored wrote: post #10

Earlier quoted context omitted.

Is that how Rust concurrency works under the hood? Polling?

Rust has no particular built-in model for concurrency or threading. The standard library currently exposes system threads, and we’re working on providing an API for pluggable concurrency models. The most popular of which is a wrapper around epoll/kqueue/iocp.

Rust has no particular built-in model for concurrency, but as soon as you want to do anything important with Rust (given the current ecosystem) you're going to run into Tokio, no? It seems to be the community-agreed-upon way to handle concurrency.

Does Tokio use polling under the hood?

Re: Rust is not a good C replacement

#134

Post by Yetanfou » Mon, Mar 25, 2019, 4:45 PM UTC

beders wrote: post #11

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would. And that is why we can't have nice things. "I don't really care" if someone overflows my buf…

Sure you can have nice things, they're there - just use them to create the 'next big thing' and the nice things will hitch a ride on its fame. Trying to push others to use those nice things does not work as long as those others prefer to use what they consider to be their tried-and-true older but nicer things.

Re: Rust is not a good C replacement

#135

Post by steveklabnik » Mon, Mar 25, 2019, 4:50 PM UTC

MuffinFlavored wrote: post #133

steveklabnik wrote: post #16

Earlier quoted context omitted.

Rust has no particular built-in model for concurrency or threading. The standard library currently exposes system threads, and we’re working on providing an API for pluggable concurrency models. The most popular of which is a wrapper around epoll/kqueue/iocp.

Rust has no particular built-in model for concurrency, but as soon as you want to do anything important with Rust (given the current ecosystem) you're going to run into Tokio, no? It seems to be the community-agreed-upon way to handle concurrency. Does Tokio use polling under the hood?

There are a number of different options. And today, yes, code is tied to one of them. But, and it’s not stable yet, futures and executors, the two traits, are being added to the standard library. This lets your code be generic over executors, and there are already more than just tokio. Including an embedded one, for example.

Tokio wraps epoll/kqueue/iocp.

Re: Rust is not a good C replacement

#136

Post by bibyte » Mon, Mar 25, 2019, 4:55 PM UTC

beders wrote: post #11

> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows. I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would. And that is why we can't have nice things. "I don't really care" if someone overflows my buf…

Yeah that's what stands out to me as well. I wish the author had put that sentence at the top. The biggest feature of Rust is it's safety. If you don't care for the biggest feature of a language then it shouldn't be a surprise that you don't like the language.

Re: Rust is not a good C replacement

#137

Post by Rusky » Mon, Mar 25, 2019, 4:59 PM UTC

jhasse wrote: post #72

xiphias2 wrote: post #15

,,Concurrency is generally a bad thing'' Easy speedup of processors ended. Not using system resources efficiently is not sustainable long term. Mozilla created Rust to be able to use the multi-core hardware (especially on mobile phones), thereby improving battery usage as well for rendering web pages. Rust has it's C++ style problems (compiling time, not good enough IDE support), but the dev team knows about them, an…

> Rust has it's C++ style problems (compiling time, not good enough IDE support), [...] Actually, since language servers like clangd, cquery and ccls, IDE support is not a C++ style problem anymore.

There have been improvements for sure, but have you used a good Java or C# IDE? C++ support is still far behind in terms of performance and accuracy.

(I work on a C++ IDE.)

Re: Rust is not a good C replacement

#138

Post by steveklabnik » Mon, Mar 25, 2019, 5:00 PM UTC

skybrian wrote: post #129

TheCoelacanth wrote: post #119

Earlier quoted context omitted.

What do you want out of an informal spec that isn't provided by "The Rust Reference"[1]? [1] https://doc.rust-lang.org/reference/index.html

It's useful but I'd like to see a bit more top-level completeness. Every feature should be listed and have at least a cursory description, even if it's not entirely nailed down. (Maybe it already is like that, but the disclaimers say it's not.)

The vast, vast majority does, but there may be some missing bits. Printed out, it's about 170 sheets of paper, so there's a lot there.

Re: Rust is not a good C replacement

#139

Post by steveklabnik » Mon, Mar 25, 2019, 5:01 PM UTC

chessturk wrote: post #131

steveklabnik wrote: post #122

Earlier quoted context omitted.

> How can folk say Rust guarantees safety when it doesn't guarantee an implementation? Just because there isn't a formal spec, doesn't mean that the underlying systems aren't built with some rules, grounded in computer science and math. We believe that the systems we've set up do guarantee those properties, even if they haven't yet been formally verified. And a subset of them have been formally verified, which also i…

> Put another way: not all specs are equal. Some are formal, some are informal. So is the argument that the language reference is as good as many existing language specifications, and my complaint is only one of semantics?

Yes, it's basically about what you mean by "guarantee". Very few things are formally guaranteed. People tend to use "guarantee" to mean "I believe this is true with a very high level of confidence."

Re: Rust is not a good C replacement

#140

Post by [deleted] » Mon, Mar 25, 2019, 5:09 PM UTC

chessturk wrote: post #131

steveklabnik wrote: post #122

Earlier quoted context omitted.

> How can folk say Rust guarantees safety when it doesn't guarantee an implementation? Just because there isn't a formal spec, doesn't mean that the underlying systems aren't built with some rules, grounded in computer science and math. We believe that the systems we've set up do guarantee those properties, even if they haven't yet been formally verified. And a subset of them have been formally verified, which also i…

> Put another way: not all specs are equal. Some are formal, some are informal. So is the argument that the language reference is as good as many existing language specifications, and my complaint is only one of semantics?

[deleted]