Rust's language ergonomics initiative

Rust's language ergonomics initiative
blog.rust-lang.org

Is there something like rust for c++ programmers?

The thing that keeps getting me now is there are so many types moving around with generics and traits. It would be nice if it were easier for something to be object safe and/or Any was more powerful. My solution as with many things is to route around it but it is frustrating at times.

    pub fn do_many(iter: &mut Iterator) {
      let mut job_id = None;
      let job_id_env = env::var("MYAPP_JOB_ID");
      let mut log = if let Ok(val) = job_id_env {
        write_pid_file(&val);
        job_id = Some(val.clone());
        let home = env::var("HOME").expect("HOME must be set");
        let path = format!("{}/log/myapp-{}.log", home, val);
        let path = Path::new(&path);
        match File::create(&path) {
          Ok(mut f) => Box::new(f) as Box,
          Err(e) => {
            if format!("{}", e) == "No such file or directory (os error 2)" {
              Box::new(io::stdout()) as Box // oh well
            } else {
              panic!("Can't open log file: {}", e);
            }
          },
        }
      } else {
        Box::new(io::stdout()) as Box
      };

      // Commit the tx if we get these signals:
      let signal = chan_signal::notify(&[Signal::INT, Signal::TERM]);

      let negotiator = OpenSsl::new().unwrap();
      let url = env::var("MYAPP_DATABASE").unwrap_or("postgres://myapp_test:secret@localhost:5432/myapp_test".to_owned());
      let tls = if url.contains("@localhost") { TlsMode::None }
                else { TlsMode::Require(&negotiator) };
      let conn = Connection::connect(url, tls).expect("Can't connect to Postgres");
      let db = make_db_connection(&conn); // defines a bunch of prepared statements
      
      // now we can do stuff . . . 

    }

    let log = open_log();
    let db = prepare_db();

I thought maybe macros would help here, since there is no new stack frame, but they still introduce a new scope that limits the lifetime of the temporary variables.

Even worse, if I want to write tests for functions that use the log and db, I need to repeat all that code again and again.

I think the answer is to use Box here? I haven't worked that out yet, but it definitely feels harder than it should. And even if I can make it work, I'm a little sad that I have to give up stack-based allocation.

I've also read that the answer might be OwningRef (https://crates.io/crates/owning_ref), but I'm not sure yet. I wish the Rust book had a section about it. It seems like Cow and Rc might also help me---I don't think so, but I'm not positive yet. Covering these allocation-related crates in a systematic way would be nice.

Anyway, I'm just a Rust newbie, but it sounds like the ergonomics effort is (partly) for newbies like me, so I'm trying to express my struggles in terms of a pattern that the Rust team could optimize for. It seems like something that people would hit quite often. I'm sure there is an answer to what I'm trying to do, so my point is that maybe it should be easier to find, or at least better documented.

By its very nature, Rust is harder (than let's say Python or JS). It is compiled, there's not much runtime magic to rely on and low level is hard.

But thinking about this and trying to make it easier is important