Hacker News Reader

Comment by scorpion95 | Hacker News Reader

Which form of Rust parallelism did you choose? I’ve read that the old one sucks.

Certainly Rust is different beast than C.

Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well?

I cannot believe at first that Rust is ever more performant than C, as C could be made parallel and seems more barebones. One of the languages that CUDA can be used with is C, so I suspect that C may beat Rust in the world of computation for now? And Rust continues to evolve, I suspect, as C could.

The author states:

> My overall feeling is that if I could spend infinite time and effort, my C programs would be as fast or faster than Rust, because theoretically there's nothing C can't do that Rust can. But in practice C has less abstractions, primitive standard library, dreadful dependency situation, and I just don't have the time to reinvent the wheel, optimally, every time.

So, I think for now: C is faster, even in parallel. But Rust could be nicer to use than C in many respects, so it may be worthwhile to consider it for large applications.

That which we state definitively may be subjective, though.

View on HN

C being barebones does not mean it is faster. Because it has such weak typing and gives a huge amount of programmer freedom, compilers have to do a lot of work to be able to understand a C program well enough to optimise it.

Rust, on the other hand, requires the programmer to give the compiler more information about what they're doing.

A very simple example:

  void foobar(struct foo *f)
  {
    f->a += 2;
    foo();
    f->a += 2;
    bar();
    f->a += 2;
  }

Because C pointer types are so barebones, the compiler can't tell whether foo() and bar() can modify f->a just from looking at the above code. So it will always have to load and store that for each += operation.

Rust on the other hand has two kinds of reference, rather than pointers:

  fn foobar(f : &mut foo) {
    f.a += 2;
    foo();
    f.a += 2;
    bar();
    f.a += 2;
  }

This is more high-level. But it's good for performance! Rust has a rule that you can only have one mutable reference to a struct at one time. Therefore, foo() and bar() can't be modifying f.a and it can simplify this to `f.a += 6;`.

(You can see it in action for yourself here: https://godbolt.org/z/hWs67P. Sadly, Rust doesn't do this by default due to problems with LLVM, but eventually it can.)

Lately on another Rust thread somebody pointed out that C programs use a lot of indirection like pointers and vtable dispatches which actually detracts from the supposed mega-speed of the low-level C. I found that to be mind-blowing and felt stupid for not remembering that earlier.

I don't think vtables are often used in C.

I think they meant function pointers in general (callbacks and the like, see qsort). Also, a lot of C codebases end up implementing manual vtables of some sort where polymorphism is required.

It's true they aren't that common, but have you looked at the Linux kernel code? It's written in C, and vtables are everywhere.

I've also used them on occasions. They do a particular job people call pluggable implementations / dynamic typing / sub-classing depending on their background. If there isn't some central place that knows all the types (if there is you can use switch/case/match), there isn't much choice, it's vtables or nothing. But needing to do that job is rare, so seeing it in languages that don't use vtables promiscuously to implement OO is correspondingly rare.

Which is as it should be, because vtables are more expensive than a direct call, very expensive if they prevent inlining. One of rust's triumphs is it provides them, but you have to go out of your way to use them so it encourages avoiding their overheads.

Dynamic dispatch (vtables are one way to do it, and so is a function pointer) is incredibly common in C, because there's no language-built-in way to perform monomorphization.

> Sadly, Rust doesn't do this by default due to problems with LLVM, but eventually it can.

Can it, though? I keep hearing/reading FUD around both unsafe and Pin making it unlikely to ever be able to ubiquitously enable the noalias stuff.

You have correctly identified it as FUD. People have a bone to pick with Pin, so they irrationally latch on to it, but the general problem is the fact that the &mut invariants cannot currently permit any self-referential data, which is a useful concept in general (for intrusive data structures, etc) and whose lack that people have been hacking around since before 1.0, with crates like rental and owning_ref. The plan to fix this is to make self-referentiality a first-class concept in the language, as a principled exception to the usual &mut uniqueness invariant that preserves memory safety while properly encoding the aliasing guarantees.

> The plan to fix this is to make self-referentiality a first-class concept in the language, as a principled exception to the usual &mut uniqueness invariant that preserves memory safety while properly encoding the aliasing guarantees.

Are there issues I can subscribe to or RFCs for this?

Yep, this one: https://github.com/rust-lang/rust/issues/63818 (the comment I'm summarizing is https://github.com/rust-lang/rust/issues/63818#issuecomment-... )

Source? I would like this to be true, but I haven't actually seen it anywhere.

https://news.ycombinator.com/item?id=26410487 (it's a significant part, though not the entirety, of this comment)

Here's Niko Matsakis' take: https://github.com/rust-lang/rust/issues/63818#issuecomment-...

Code affected by unsafe already has to go through `UnsafeCell` which disables most aliasing optimizations, and the stacked borrow semantics have explicit opt-outs for such cases. I don't believe there are any Rust semantic issues standing in the way of exploiting aliasing information in this way, just LLVM bugs (and the fact that its restrict model isn't currently equipped to handle the information at such a fine granularity).

There is undefined behavior in Rust affecting real-world code, including Tokio's scheduler, and code produced by async fn definitions. UnsafeCell doesn't solve the problem. There's more information at https://gist.github.com/Darksonn/1567538f56af1a8038ecc3c664a....

Bug report at https://github.com/rust-lang/rust/issues/63818.

Reddit threads at (older) https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_... and (newer) https://www.reddit.com/r/rust/comments/lxw6cl/update_to_llvm....

Somewhat related HN thread at https://news.ycombinator.com/item?id=26406989.

This is the `Pin<&mut>` example which I'm not that familiar with but was aware of. I think it's highly unlikely that this one, relatively niche use case is going to prevent Rust from ever being able to safely turn on aliasing optimizations. There have been several solutions proposed, e.g. adding a stricter UnsafeCell to the language; they may technically not be backwards-compatible, but given how `Pin` is used and the fact that this is a soundness issue, I think it should be fine.

The HN thread is mostly unrelated. I agree that it would have been better to integrate `Pin` directly into the language, though, but mostly for ergonomic reasons; it could still probably happen in an edition upgrade.

The github discussion thread where that originates from also contain the language designers optimistically discussing how in the worst case `Pin` just has to be hardcoded to exclude these optimizations. Which wouldn't make it the first type in the std lib that works similary (see interior mutability and UnsafeCell), so I personally intepret that as "unlikely to be an issue".

That's what restrict is for:

    void foobar(struct foo *restrict f) { ... }

And just like that we're back to

> There's a significant difference between what these languages can achieve in theory, and how they're used in practice.

Theoretically in C you can use restrict for this. Practically nobody does (rust users keep finding bugs and miscompilation in LLVM's noalias support), and it's a huge footgun because you're completely on your own and all bets are off if you misuse it.

Meanwhile in rust land, it's the default and the compiler checks your homework, and while you can always lie to the compiler it's much rarer that you'd even get in a position to do so.

But restrict is very hard to reason about correctly, and the consequences for making a mistake are potentially catastrophic.

There's a very real difference between what's possible in theory and what humans do in practice. I wish Hacker News people engaged more with the practice.

Yes, C99 added that keyword, and you can use it in C code. (C++ is a more complicated matter, I believe…)

But I think it's pretty uncommon in practice. One reason is that the C compiler has no borrow checker to help you notice when you're using `restrict` unsafely.

(Also, there's the whole “strict aliasing” hell…)

It's not that uncommon in HPC codes. I.e. one of the places where speed matters.

If you can have "one mutable" and "more than one non-mutable" reference (not sure if this is the case), you still cannot safely do that optimization, as foo() and bar() could in principle be reading f.a and the optimized version would then not have the correct values of f.a when foo() and bar() are called.

Note, I genuinely don't know if this caveat applies to Rust. But, m general, not only mutable references need to be considered.

> My overall feeling is that if I could spend infinite time and effort, my C programs would be as fast or faster than Rust, because theoretically there's nothing C can't do that Rust can.

The exact same argument applies to assembly code. There are very good reasons that it's not used nowadays except in incredibly rare circumstances or in the embedded world.

It doesn't matter in the slightest how fast your language is in theory. Not one iota.

The only thing that matters is how fast the programs you write with it are in practice. The evidence is clear: it is significantly easier to write faster programs in Rust than it is in C, and this applies to even the most skilled developers.

The very short version:

There are many things which cause both frequent and rare strange crashes in multi-threaded code.

In C, all these things will compile OK. In safe Rust, practically none of them will compile.

It is much easier to fix compile issues in Rust to do with dangerous memory usage or thread sharing than it is to debug a compiled program.

Accessing files or database content from multiple threads without proper locking, or transactions, in place will compile just fine.

Rust won’t prevent all manner of bugs, but if you need to prevent multiple parts of your application from accessing a resource concurrently, it’s fairly trivial to design types that would guarantee that at compile time.

If you need to do it across processes, then you need a file system that supports exclusive file opens.

The db question is a red-herring, because to properly solve for concurrency in the db, you need to use locks in the db (table and row locks), not the code accessing the db.

You dont necessarily need to use locks in the db. You can use transactions as well, unless you want to do major changes to the DB where transactions would be in constant conflict state.

You’re right, though that wasn’t really the point of my reply. More that concurrency in the DB is a DB design choice and not the responsibility of the language accessing the DB. This is especially true when accessing the DB from multiple nodes, which most deployed software does.

Locks and transactions are intertwined. Write locks are typically released only when the transaction ends, and read locks too at some transaction isolation levels.

> Rust won’t prevent all manner of bugs

Nit: rust will prevent all manner of bugs. Rust won't prevent every manner of bugs.

Indeed, but the fearless concurrency sales pitch tends to overlook that.

It’s hard to see how you could be arguing in good faith given that your point of “fearless concurrency” being an overstated “sales pitch” has now been answered with multiple substantive answers.

Please stop moving the goal posts from “program concurrency” to “distributed or multi-process transactions.” It subtracts from the conversation.

Rust is honest about what it does and doesn’t do.

Rust is honest, https://doc.rust-lang.org/nomicon/races.html

I am not moving goal posts, rather talking about issues that many apparently lack the knowledge to understand how many variants of data races exist in an application.

Quite understanable given the majority of developers that keep writing single threaded applications.

The fearless concurrency sales pitch doesn't overpromise. You're trying to stretch it, but it's pretty clear on what kind of concurrency issues it covers (eg. data races).

Yeah it would be a grave misinterpretation of "fearless concurrency" to think Rust somehow validates that access to some shared resource with it's own semantics is also safe. I'm not educated on the subject but that problem seems pretty intractable for a language to solve in a general sense.

Indeed, yet that is not how many Rust advocacy blog posts sell it.

Such as?

Any blog post that gives examples accessing shared variables and never goes beyond anything else, leaving to the reader that it works the same way regardless of what resources are being accessed.

https://blog.knoldus.com/how-we-can-do-fearless-concurrency-...

Now rewrite the same blog post using SQL queries to update the same counter variable on a table row.

The Rustonomicon is quite clear that it wouldn't work,

> However Rust does not prevent general race conditions.

https://doc.rust-lang.org/nomicon/races.html

You really had to dig a post that has less text than code?

> leaving to the reader that it works the same way regardless of what resources are being accessed.

If that's how readers envision that non-language-managed resources work, they should go back to CS102 right now.

And concerning the nomicon, it explicitly states that Rust can't handle all races condition, I don't get your point.

What a silly point to make. The code you’re writing in rust could launch a nuke that destroys the world and it will also compile just fine.

Rust has the expressive power to design an API that explicitly makes it impossible if you so desire though. For instance by using an API similar to mutexes where you have to lock to access the contents.

> However Rust does not prevent general race conditions.

https://doc.rust-lang.org/nomicon/races.html

I never claimed otherwise. If you want to enforce invariants in your DB API you'll have to implement them yourselves, Rust won't do it for you because Rust doesn't know what a database is. Still, it's perfectly possible to design a DB API is such a way that it would prevent some issues, such as for instance doing changes without an active transaction.

But you're right to point out that Rust won't magically solve all your possible sources of crash and data corruption, it just does make it a lot easier to enforce arbitrary constraints. For instance if you decide that in order to avoid these issues you want all your DB stuff to only run in a single thread you could design your API in a way that would prevent DB handles from being shared between threads, all that enforced by the language. You couldn't accidentally leak a DB handle to a different thread.

> Accessing […] database content from multiple threads without proper locking, or transactions, in place will compile just fine.

All the rust db interfaces I've seen so far forbid unlocked sharing of connections, statically (the connections are !Sync, in Rust speak).

They don't enforce the use of transactions, nor exclusive access to database tables.

show me a c program that does this in a manner that a rust program can't emulate

C doesn't advertise fearless concurrency.

> Code converted from C to Rust seems much more voluminous.

This is a fairly odd claim.

If you have to deal with strings (ASCII and UTF-8) properly, C is stupidly verbose.

If you need a data structure more complex than an array of something, C is stupidly verbose.

If you want to deal with pattern matching/regexen, C is ridiculously verbose.

Do I agree that Rust is far more verbose for an embedded "blinky" (the embedded equivalent of "Hello, World!")? Yes.

But once I start doing things like processing messages in a communications stack (BLE, CANOpen, Ethernet, etc.), Rust starts looking better and better.

Blink in rust is concise as well:

  // Main function
  #[arduino_uno::entry]
  fn main() -> ! {
    let peripherals = arduino_uno::Peripherals::take().unwrap();

    let mut pins = arduino_uno::Pins::new(
        peripherals.PORTB,
        peripherals.PORTC,
        peripherals.PORTD,
    );

    // Pin D13 is connected to L led
    let mut led = pins.d13.into_output(&mut pins.ddr);

    loop {
        led.toggle().void_unwrap();
        arduino_uno::delay_ms(500);
    }
  }

https://github.com/vlisivka/rust-arduino-blink/blob/main/src...

When I converted code from C to Rust, I was left with much more code.

Are you just noting specifics, or was it your experience that there was less Rust required for a full C to Rust conversion?

AFAIK it is a common experience that both C and C++ code tend to become fewer LOC in a move to Rust, a lot of it due to stuff like serde that greatly reduces boilerplate. It probably depends on your application and program size, though. I'm sure that if you're doing a lot of pointer wrangling or something it won't be smaller in Rust, while if your C program was just a bunch of SIMD intrinsics anyway like a lot of high performance code is now it'll probably be basically the same length.

Did you ever take a look to try and figure out where the extra verboseness came from? For instance, was it spread equally across all functions or concentrated in those doing numeric computations (or whatever)? It would be interesting to learn something from this example.

Did you convert it by hand and translate the code into idiomatic rust? Or just run some C code through c2rust? Because the latter will not produce anything like a typical rust program, it will be C types and logic with minimal changes to make it compile in rust (and those changes will make it look very verbose).

for one thing, naming a C struct requires more words than naming a Rust struct; for another, the names of functions that operate on them

I mostly agree with your post but:

> If you need a data structure more complex than an array of something, C is stupidly verbose.

What’s stupidly verbose about Structs to you?

"Data structure" here probably means something like a linked list, binary tree, or hash table.

Linked list, binary tree, and heck, even a hash table aren’t “stupidly verbose” to me in C either, hence my question to GP.

You have to allocate and deallocate--where and when does that occur? When the data structure needs to grow, all pointers need to be invalidated--where and when does that occur? How do you iterate across the data structure? Do those iterators hold a local pointer or do they hold a root pointer plus an accessor function pointer plus memoization? What happens when you want to copy a subset of the data structure? I can go on and on.

Every one of those things requires a fairly primitive function call that sometimes doesn't even need to exist in another language. For contrast, think about all the macrology that the Linux kernel does to iterate across every element of a linked list that is effectively "for element in list {}" in any higher language.

And, even worse, most of that stuff in C needs to be runtime-only, while some of this kind of thing gets elided by the compiler in other languages.

If you don't consider all that "stupidly verbose" I'm really curious what you would?

And this is long before we start talking about concurrency.

C allows you to write something that works "just enough" that you put it into production and then it bites you in the ass (similar to quadratic algorithms--functional enough to get to production and then bite you).

The author did say that there is nothing that Rust does that C cannot. The difference is that in Rust, those things are easier, or many times, the default way, while in C, you would have to take care of way too many things to make sure things work.

I used to say that wrt to memory leaks with Java and C++ and it remains true when comparing C and Rust:

It's not that it's easier to write programs in [Java|Rust]. It's that it makes it much harder to write the bugs.

Yesterday I upgraded an entire code-base from C to C++ just because it was faster than writing my own dynamically resizing array in C.

Writing programs in C is harder just because there are essentially no containers in the stdlib.

Aren't there good container libraries for C?

There are a lot of great libraries for sure, but they aren't in the stdlib and C doesn't make it as easy to use external libraries as languages with modern tooling. Everybody gets grumpy about dependencies and a lot of people probably figure it's easier to maintain their own container code in their application than to deal with that.

They are either based on void * with performance issues, or macro based with weird ergonomics that look like function calls, but aren't.

It's doable, but not very easy.

You are right in a library-demographical sense, but not in a fundamental sense. There is a 3rd way. Have a look at the CTL I linked to (downvoted..maybe I should have explained more?).

Once you give up the closed source/prebuilt binary library idea and embrace the C++-like header library idea and write implemenations in terms of "assumed macro/inline function" definitions, the problem becomes straightforward with no performance issue and different ergonomics issues than you probably think.

It's a more "manual instantiation" than C++ templates or generics in other languages where just refering to them works, but most of C is quite manual. So, it fits the headspace & the hard parts of data structures/meddlesome hands remain factored out. Since you parameterize your files/code with #define/#include, you have to name your parameters which can make the instantiating client code more obvious than C++ templates with many arguments. OTOH, there is no/poor type checking of these parameters.

I had a look, and it feels like template programming but with even worse guarantees.

Having a type declaration dependent on #define P whether it is plain old data or not, and needing to know what that means, is not the kind of ergonomics I'd want. That requires learning a whole new paradigm to ensure I am not doing wrong things.

In my mind it is so big an extension of the C language, that it leaves the C headspace and becomes its own headspace.

Yeah. It's not for everyone. I think "different ergonomic issues" may cover that and I did mention the type checking already. :-)

It is a smaller learning curve from pure C than "all of Rust" or even "all of C++/STL". You got the basic idea in short order (that may be for ill as well as good..I was never trying to make a normative claim).

https://github.com/glouw/ctl/

Yes.

But it’s not just taking care of those things that must be done; it seems to bloat the code.

I think it’s a great alternative to C for large apps like Firefox, and perhaps it’s a good alternative to Go for services.

For general purpose, I personally want something fast that’s easy, clear, and concise like Ruby.

Do I just accept that Rust is the most evolved version of C, or is my gut correct that it’s bloated? Is it a good choice for general purpose as-is?

As someone who's worked predominantly in high level languages (Scala, Ruby, etc...) I've found Rust to be relatively straightforward to use for simple CLI tools or gRPC servers (tonic library is pretty nice). I haven't tried building a CRUD app yet, but I don't see any real reason why it would be impossible to have an ergonomic web framework in Rust.

The things I find most difficult: 1. Wrangling with the borrow checker can be painful before you know what you're doing (and even afterwards) but if you understand the standard library/patterns well, it seems to minimize the cost. Example being trying to write your own `get_or_else_insert` style method for a HashMap. Writing your own version is easy in other languages but hard in Rust. If you didn't know that methods like that already exist on HashMap you will experience a lot of pain until you understand the "right" way to do something.

2. Shared memory concurrency is definitely at the nexus of all the more difficult parts of Rust. Especially with async/await. There's no question in my mind that if you want to write a webserver that has async functions accessing shared memory, that you will for sure need to fill in any gaps in your knowledge as it will be difficult to get to a working program without understanding significantly more concepts than what it might take for a simple single-threaded CLI app

I'm pretty sure that it will be possible (if it isn't already) to get the Rust ecosystem to a state where writing a CRUD app is about as simple as in Go (and considerably easier/more ergonomic w.r.t certain things like JSON serialization).

Firefox's is compiled code is mostly written in C++ not C. You conflate C with C++, Java, and C#. C++ while has source compatibility with C tends to end up much different than C. C will not give you the OOP hell-scape you can dig yourself into with those three languages. C code tends be simpler and much more close to the assembly that will be generated than you would get in those language. Moreover, Java and C# are not even compiled. Anyways C != C++. C++ has changed quite a bit since it's earlier days and has diverged from plain C in a lot of ways. Some people even feel C++ keeps adding too many new features too fast.

> Some people even feel C++ keeps adding too many new features too fast.

It's not so much that they keep adding features, but that they (almost?) never remove any.

Python 3 has shown the world what happens when that is done without bringing the ecosystem along.

Haskell has also removed some features over time.

Haskell or GHC?

If you mean GHC, the language version is whatever the pile of configuration flags at each source file ends up meaning, some of them even contradict themselves.

Great for language research, which is Haskell main purpose in life, hardly a good idea for getting industry love.

I am talking about Haskell, specifically the removal of 'n+k patterns' and 'monad comprehensions'.

About GHC: I think their approach with pragmas is great and something for other languages to emulate. It's also great in production, with the caveat that you might want to restrict that mechanism to surface level changes only, and nothing that changes the intermediate format.

Are there many other programming languages that remove features?

Python 3 made some backwards incompatible changes. Haskell removed some features over time, as well.

> C++ while has source compatibility with C

It doesn't really, some things from C won't compile in C++, but that's a minor nitpick

I guess people mostly take source compatibility to mean that you can write the headers for your C library so that it can be used from C++. That's not the same thing as C being a proper subset of C++ or whatever, but it's still a vast enough advantage of C++ over most competitors that it might as well be.

Ruby is not fast.

But if you want something between rust and ruby, checkout crystal (garbage collected, strongly typed with inference, llvm binary, ruby-like syntax, fast like golang).

> Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well?

My experience is mostly the opposite. For many tasks Rust can be much more concise (see anything with string handling, for example).

> Code converted from C to Rust seems much more voluminous.

I haven't seen that in practice. A good point of reference are implementations of things like ruby, python, or the erlang vm in rust compared to the C alternatives. This might be because Rust is also more expressive (probably by borrowing certain syntax/semantics from ocaml/haskell), though the borrow checker does add back some verbosity.

Reply on news.ycombinator.com