Jamey Sharp On Whether You Should Translate Your Code To Rust

[Shimon]

people who code in C, have always coded in C and will only ever code in C.

Such people should explore another contender - Nim, that transpiles to C.

[Luke_Wolf]

Actually along the lines of porting stuff, I've been rewriting a toy program to help me learn rust, and I've run into a bit of a problem, how does one handle event flows in idiomatic rust? In C# I would use the built in listener/sender pattern, in C++ I'd use signals and slots, in C and Javascript I'd use function pointers/callbacks, but in my googling around all I've seen are people from a year ago talking about how signals/slots couldn't be done related to Qt and Rust and no examples detailing about how things should work, other than that closures are a no-go.

[ldo17]

C++ has grown in a year more than Rust in 10.

Maybe that’s the problem with C++: it started out as a bloated language, and has gone downhill from there.

Can you explain “&&” references and move semantics in one paragraph or less?

[mmstick]

Actually along the lines of porting stuff, I've been rewriting a toy program to help me learn rust, and I've run into a bit of a problem, how does one handle event flows in idiomatic rust? In C# I would use the built in listener/sender pattern, in C++ I'd use signals and slots, in C and Javascript I'd use function pointers/callbacks, but in my googling around all I've seen are people from a year ago talking about how signals/slots couldn't be done related to Qt and Rust and no examples detailing about how things should work, other than that closures are a no-go.

Do you have an example of what you're trying to accomplish? Some of the things you mention sound completely different from each other. Function pointers are basically closures, and you can create closures in Rust and supply them as input arguments in a higher-order manner. Many traits in the core and standard library are implemented in this manner, such as various methods in `Option`, `Result`, and `Iterator`. Listeners and Senders sounds a lot like Rust's Senders and Receivers, which is effectively the same as Go's channels.

[Luke_Wolf]

Do you have an example of what you're trying to accomplish? Some of the things you mention sound completely different from each other. Function pointers are basically closures, and you can create closures in Rust and supply them as input arguments in a higher-order manner. Many traits in the core and standard library are implemented in this manner, such as various methods in `Option`, `Result`, and `Iterator`. Listeners and Senders sounds a lot like Rust's Senders and Receivers, which is effectively the same as Go's channels.

Well let me explain what I'm doing. Basically you have a connection object, a controller object, and some actions

The connection object listens on the port for valid messages, and when it receives one it turns it into a message object, the connection then fires off an event containing this message object, which the controller is listening for. The controller checks whether there are any action objects which should receive the command, and then passes the event along to the ones that should. The actions do whatever they're programmed to, and if there's any response it needs to send to the connection, the action fires off an event that the controller is listening for and then passes it to the connection object.

Obviously the connection and the controller are running in their own threads, and I've already decided that the messages are going to be handled by enum since Rust has a very flexible enum system.

All the things I had mentioned in the previous post were ways to pass those events around, which do work rather differently from each other yes.

If the sender / receiver in Rust sounds like a fit for that to you, do you have any good examples I could look at?

[mmstick]

Well let me explain what I'm doing. Basically you have a connection object, a controller object, and some actions

The connection object listens on the port for valid messages, and when it receives one it turns it into a message object, the connection then fires off an event containing this message object, which the controller is listening for. The controller checks whether there are any action objects which should receive the command, and then passes the event along to the ones that should. The actions do whatever they're programmed to, and if there's any response it needs to send to the connection, the action fires off an event that the controller is listening for and then passes it to the connection object.

Obviously the connection and the controller are running in their own threads, and I've already decided that the messages are going to be handled by enum since Rust has a very flexible enum system.

All the things I had mentioned in the previous post were ways to pass those events around, which do work rather differently from each other yes.

If the sender / receiver in Rust sounds like a fit for that to you, do you have any good examples I could look at?

Without source code, I won't be able to demonstrate an idiomatic solution. You can have a Sender in your connection listener that creates and passes an enum through the Sender to it's associated Receiver in another thread, and merely pattern match the enum on the other end to select whichever action you want to perform. At a glance, it does not sound like you would need a closure at all. The relevant documentation is here. There are more types of channels in Crates.io in case you want something different than a multi-producer, single-consumer.

As an example, in my Parallel implementation, I use a Sender to send a completion or error signal (enum values) to a Receiver in the main thread that then knows to finish tailing/printing the last of the outputs for the current job and start reading the next job's outputs.

I will also warn that while channels are very convenient, they do have an overhead over a more traditional channel-less approach with Arc'd Mutexes, so if you need a fast solution with minimal overhead, it's wise to investigate that approach.

[nomadewolf]

Hahahaha the moron will say in 2 years that Redox OS is ready to take on Windows. Kids these days... They don't understand that we've been there before and repeat the same mistakes instead of learning from the elders.

Never said that.
I think Redox OS made impressive progress to date, compared for instance with HURD or ReactOS, which have had dispointing long development times...
So far, RedoxOS has surpassed my expectations, and i HOPE it continues to do so.
But i'll wait for the actual results.
If anything, it has to take over BSD and Linux, before it takes on Windows.

[nomadewolf]

successful in what way? nobody is going to switch from linux to redox, so it looks like nothing can push rust forward

No one CAN switch right now.
But if The Redox developers manage to put out a stable OS that has clear advantages over Linux while maintaining compatibility, then you very well that in the open source world, distros can rise and fall in relative short amount of time...

[starshipeleven]

I didn't bring up node.js, the person I was responding to did. I was comparing with Rust with C/C++. I'm saying that it isn't a good idea to wholesale rewrite stuff traditionally written in C to use Rust. There were no bullshit comparisons in my argument. I said node.js was probably good for the use cases it's used for.

No, you clearly made a "node.js = rust" and then cited the fact that writing userspace in node.js is stupid (because it is) to also show how rewriting stuff in Rust is stupid (when it is not as it is a compiled language).

[starshipeleven]

Fanboism is strong in this thread. C is a toy language. Academics patting each other on the back. COBOL has grown in a year more than C in 10. C has no chance. Face the reality!

fixed.