> For example, some of the functionality around semi colons seem like they will be a common source of stupid programmer bugs that are difficult to track down. Perhaps the compiler will catch that stuff.

It will, because the semicolon in Rust actually has a semantics impact: `a` has type T(a) but `a;` has type Unit (~void).

> Go kinda ruined other languages for me with multiple return values

That's sad, because Go has one of the worst MRV implementations out there: it's a special case of the language itself.

In most languages with MRV — and that includes Rust, but also MLs, Haskell, Erlang, Python or Ruby — MRV is simply a natural consequence of being able to unpack or pattern match containers (tuples and/or lists depending on the typing discipline).

Anyway Rust has multiple return values, don't worry about that.

I have limited experience with Rust, but the semicolon stuff you're describing has been one of the most surprisingly positive aspects about it for me. I thought it sounded kind of like a dumb gimmick that just adds subtlety (read: removes simplicity) to something for no reason. However, in practice I've found is really great for making the intent of your code more visible (less cluttered). I miss it when I'm doing C#.

Also, I've never come across a situation with too few/extra semicolons causing any kind of logic errors. The compiler will complain at you if you get it wrong.

I had the same experience; having briefly touched Matlab and loathed its difference between semicolon (don't print result) and no semicolon (print result) I was very dubious of it—why not just put `return` there? But when you combine it with the almost-everything-is-an-expression way of doing things, it actually works really well. Makes some forms of state machine exceptionally elegant, for example. So much so that Python has lost some of its charm for me.

Also, the type checker ensures that you'll hear about it if you lack a semicolon and emit a value other than unit from a block, without then using it.

Go is not the only language with multiple return values. Lua for example had them before Go. In Lua it would look like:

  addsub = function(a, b) return a + b, a - b end

  a, b = addsub(32, 44)

And if you run that code with LuaJIT it compiles down to a few machine code instructions, no object creation at all, no function call.

In contrast I think at least in Python the tuple based solution would be horribly inefficient because it allocates/deallocates a new object every time just to pass values. I don't now if the Rust compiler is smart enough to optimize the tuple creation away.. but I doubt it.

  > I don't now if the Rust compiler is smart enough to 
  > optimize the tuple creation away

I'm sure it can. LLVM is a really, really good backend.

Multiple return values is possible with n-tuples.

  fn addsub(a: int, b: int) -> (int, int) {
      (a + b, a - b)
  }

  ...

  let (a, b) = addsub(32, 44);

Indeed, the behavior described here is just a consequence of allowing pattern-matching when assigning variables. Say you wanted to do the Python trick of swapping two values:

    let a = 1;
    let b = 9;
    let (b, a) = (a, b);
    printf!("a: %i, b: %i", a, b);  // a: 9, b: 1

...or say you just wanted to grab a single item out of a tuple:

    let x = (1, 2);
    let (_, y) = x;  // the underscore is the pattern for "ignore this"
    printf!("y: %i", y);  // y: 2

Just for comparison:

  b, a = a, b 

is actually valid code in Lua (and works as expected).

Grabbing only one value looks like this

  _, y = returnsTwoValues() -- grab only the second 

  y = returnsTwoValues() -- grab only the first

This works similarly in Ruby:

    a,_ = two_values()
    _,b = two_values()

Ah, very interesting. Thanks for posting that. Looks like I have one more reason to dig into Rust.

Rust does have a lot of potential, but don't underestimate how much change it has undergone lately, and will likely be undergoing in the future.

The large amount and rapidity of change makes it difficult to use it seriously. It's nowhere near as stable as other newer languages like Go and Scala are, for instance.

Some experimental programs I wrote a mere 8 months ago are now basically unusable with recent versions of Rust due to language, syntax and standard library changes.

Unless you can constantly track Rust's development on a daily basis, and update your code accordingly, I'd be very hesitant to suggest using it for anything but throw-away code at this point.

This is true, though I do believe it is a lot more stable than about 12 months ago(?)

It reminds me of Go a couple of years ago, but that had "go fix" which would mostly update your source files to the newest revisions. That made early adoption a lot nicer. I'd love to see a "rust fix"