Correctness of the solution

On reflection, I'm not sure either the C++ or the Rust code solves the problem as stated. I'm not completely sure I understand the shoe shine shop model so I may be wrong. Here's what it looks like the code does: you generate a bunch of random events of all kinds, and order them in time. Then you process the events one by one starting with the earliest. But that doesn't make sense!

Customers arrive according to PP with rate \$\lambda\$, and enter only if first chair is empty. Shoe-shiners takes \$\exp(\mu_1)\$ time for brushing and \$\exp(\mu_2)\$ time for polishing.

The way I'm reading it, your random variables should be ordered not with respect to other events of the same kind, but with respect to the order of events in the shop. A shop can't finish shining a shoe before it has been brushed, and it can't finish brushing a shoe before any customers have arrived. Therefore, you need to schedule a FirstFinished event with respect to the Arrived event that initiated it, not with respect to the previous FirstFinished event.

A BTreeMap isn't the right solution to this problem. One way to solve it might be a priority queue with both the event kind and the time of the event (possibly a BinaryHeap<(OrderedFloat<f64>, Events)>). Your event queue starts out filled with only Arrivals, randomly distributed according to \$PP(\lambda)\$. As you process the queue, you pull off an arrival, and schedule the FirstFinished event at some time in the future relative to the arrival time. Then you pull off the next event, which could either be another Arrival (which you would have to drop) or the FirstFinished event you just pushed on (which would enable you to transition to the next state, and schedule the SecondFinished event), and continue processing.

I thought so too, but my group mate guessed that it doesn't make a difference. When the results produced by this program matched theoretical ones, I was convinced. Out of interest I just programmed your version of the solution and the results are the same.

Okay, I'm not an expert but I do think this is technically true, because the expected time remaining until the next event does not depend on the time since the last event. So from a pure results perspective your colleague may be correct. However, there are still two good reasons to write the solution the way it is formulated:

1. You are relying, perhaps unaware, on a feature unique to exponential distributions. Suppose you were asked to model the same problem, but use a normal distribution for the time it takes to brush or shine shoes (which is probably more reasonable, anyway). Your current code can't be easily changed to account for that; you'll have to rewrite it. Also, if somebody else came along after you, they might not realize this code depends on an exponential distribution; they are likely to be confused (as I was).
2. Generating a lot of random numbers has performance implications. Consider the difference between cargo run 1 50 50 10 and cargo run 1 1000000000 1000000000 10. These simulations should serve roughly the same number of customers, but the second one calculates nearly two billion random numbers that never get used!

That said, a lot of the advice I have to give here is applicable generally, so let's proceed as if the program's behavior is correct as written. I will restrict myself to comments on the Rust code, as that's what I am more familiar with.

Versions

You may be using an older version of Rust. extern crate declarations are not needed anymore in the 2018 edition. If you're still on 2015, that's fine; I just thought you might like to know.

Most distributions in the rand::distributions module have been moved to a separate crate, rand_distr. The old versions are deprecated; I got warnings about it during compilation. I don't know how long ago this change was made; you might want to update your dependencies. Again, not necessarily a problem, just FYI.

Style

Thank you for using rustfmt.

States and Events should be named State and Event, because each enum represents a single state or event, not several.

Star imports (like use rand::distributions::*;) are usually inadvisable, like using namespace in C++, because they pollute the module namespace. If you have a lot of them you can easily lose track of which names come from where. You're only using a couple of specific names here, so just write them explicitly:

use rand::distributions::{Distribution, Exp}; pub use ordered_float::OrderedFloat; 

(Seeing as nothing else is marked pub, that can presumably go too.)

Don't loop over integers and then index into a slice. Instead, loop over the slice, and possibly throw an .iter().enumerate() in if you need access to the index, so

for i in 0..s.len() { /* do something with s[i] */ } 

becomes

for element in s { /* do something with element */ } // or for (i, element) in s.iter().enumerate() { /* if you need i too */ } 

Questions

Variant is never constructed

// variant is never constructed: `FirstFinished`, why do I get this message? I can see this variant printed when running the program 

This looks like a compiler bug in that it doesn't realize that converting from an integer, with or without unsafe, can create variants without naming them.

Integer to enum conversions

// 1 template function for this? Or any other way to cast integer to enum? Or I should use libraries for this? impl From<usize> for States { fn from(s: usize) -> States { let tmp: u8 = s as u8; unsafe { std::mem::transmute(tmp) } } } 

There is no reason to use unsafe here. In fact, as written it is incorrect, because passing a usize that doesn't correspond to a valid States could cause undefined behavior. As long as you're using safe Rust, the compiler protects you from unsafety; when you use unsafe, you assume responsibility for writing a safe abstraction that can't be used unsafely.

C-like enums implement the TryInto trait, which you should use instead. You can replace the bodies of both functions with s.try_into().unwrap(). Oops, this was a blunder on my part. TryFrom/TryInto are not automatically implemented for C-like enums; that was a requested feature that I thought had been implemented, and compiled when I tried it but actually is incorrect. Instead you should probably just write TryFrom yourself; here's one example. However, converting enums to integers isn't particularly idiomatic in Rust; if you rewrite the code to use a match as under "Design concerns" below, it's not necessary.

report

//what do I need lifetime 'a for? Is there supertrait that specifies multiple traits? ("Number", "container", idk) //Or can I just say that allowed types are f64 and i32? fn report<'a, T>(title: &str, counts: &'a [T; States::Dropping as usize]) where T: std::iter::Sum<&'a T> + std::ops::Div + Copy + Into<f64> + std::fmt::Display, { 

What do I need 'a for?

Not much, in this example. Named lifetimes are all about specifying relationships, in this case, the relationship between counts, which is a reference, and Sum<&T> which is a trait satisfied by T. You have T: Sum<&'a T>, which means that you can add a bunch of &'a Ts and get the sum as a T. You have a bunch of &'a Ts (the slice) and you need a T, so that's the right constraint. There's not much more to it than that.

Is there a supertrait that specifies multiple [number-like] traits?

There are traits like that, defined in the num_traits crate. You usually want num_traits::Num to do general math on a generic type. But it's not really needed here; if you change the events line to

 let events: f64 = counts.iter().copied().map(Into<f64>::into).sum(); 

you only need T: Copy + Into<f64> to implement the whole function. (This line looks pretty ugly; probably there's something nice and elegant I'm overlooking.)

Calling into

 Into::<States>::into(i), Into::<f64>::into(counts[i]) / Into::<f64>::into(events) // How to call Into properly? this looks bad 

If you really need to specify the type argument to Into, that's how you would do it, but that's unusual. Most of the time you can just write .into(). When the types implement From, that is also often somewhat cleaner.

 States::from(i), counts[i].into() / events.into() 

You have several other intos scattered in this loop:

 for (time, event) in timeline { ... } 

But they're all turning time, which is an OrderedFloat<f64>, into a regular f64. You don't need to do that; because OrderedFloat is just a newtype struct, you can just access the inner value with .0. Or in this case, since you don't actually need the OrderedFloat inside the loop, you may use a destructuring pattern to pull it out as you iterate.

 for (OrderedFloat(time), event) in timeline { ... } 

OrderedFloat

 // I don't like OrderedFloat because it's a wrapper. Is there a way to implement Ord for floats and keep nice syntax? // Maybe it's the problem of algorithm. Any proposals? let mut timeline: BTreeMap<OrderedFloat<f64>, Events> = BTreeMap::new(); 

Not really, you need to decide somehow how to handle NaNs. If NaNs aren't a possibility, maybe floating-point numbers aren't an appropriate type. An alternative might be to pick a unit, like 1 nanosecond, and just keep all your times and durations as integers, only converting them for display purposes.

Emulating do loops

 //Is it ok to emulate do while loops like this? while { /* loop body that returns true or false */ } {} 

I mean, I guess it works, but ew. Just use loop and have if condition { break; } in there somewhere.

Design concerns

main is too long. pacmaninbw's advice applies as well to Rust as to C++. I'd try to move some of that logic out to methods of State.

I like the way you use derive(Default) to avoid doing unnecessary work; that feels nice and idiomatic.

The Invalid state of your machine makes me slightly uncomfortable. There are uses for such things but it looks like you could get rid of it entirely and just panic immediately when you encounter an invalid state/event combination, rather than making your state temporarily invalid until the next loop iteration.

There's another thing that also seems awkward to me, and that's the repeated use of States::Dropping as usize for an array size. This use of enums is normal in C but in Rust it just feels out of place; enum is not just a renamed integer but a full-featured sum type. Ideally, you would make use of this to write a next_state function that is statically guaranteed to cover all the bases:

fn next_state(sr: State, event: Event) -> Option<State> { match sr { State::Empty => match event { Event::Arrived => Some(State::First), _ => None, } State::First => match event { Event::Arrived => Some(State::Dropping), Event::FirstFinished => Some(State::Second), _ => None, } /* ... */ } } 

Turning this into a macro so you can keep the nice table format in the source code seems pretty doable.

Miscellaneous tips

 let event_to_state: [[States; 5]; 3] = [ // EMPTY FIRST SECOND WAITING BOTH /* Arrived */ [States::First, States::Dropping, States::Both, States::Dropping, States::Dropping], /* First_Finished */ [States::Invalid, States::Second, States::Invalid, States::Invalid, States::Waiting], /* Second_Finished */ [States::Invalid, States::Invalid, States::Empty, States::Second, States::First], ]; 

This is a bit long and noisy compared to the C++ version; you can trim it down by adding a use States::*;. Also it should be a const (not quite like C's const; more analogous to constexpr in C++).

 use States::*; #[rustfmt::skip] const EVENT_TO_STATE: [[States; 5]; 3] = [ // EMPTY FIRST SECOND WAITING BOTH /* Arrived */ [First, Dropping, Both, Dropping, Dropping], /* First_Finished */ [Invalid, Second, Invalid, Invalid, Waiting], /* Second_Finished */ [Invalid, Invalid, Empty, Second, First], ]; 

I might consider using a declarative macro instead of a generic function for report. It's internal, the abstraction is mostly syntax and the trait bounds are not terribly interesting.

I don't really like macros since I come from c++. Are they widely used by Rust community?

Yes. Declarative macros (those defined with macro_rules!) are quite different from preprocessor macros (fancy text substitution) like in C.

• They resemble C++ templates in that they must be syntactically valid at definition, but don't type check until instantiated.
• Macros are hygienic (names defined in the macro don't leak to the outer scope, or vice versa).
• They are also scoped, so they don't leak out of the function or module in which they are defined.

As with any form of metaprogramming, it's possible to go overboard, but you shouldn't be afraid of using a macro now and again to reduce repetitive code that can't easily be made into a function or generic. Procedural macros are a different story, but they're even more infrequently needed.