I really like what I see, but a few missing features stand out:

1) regex literals 2) default values on methods 3) if / unless suffixes like ruby has throw new Exception if blah 4) multiple return values from a method 5) ||= operator like ruby (if null then) 6) list loading via << 7) list union via | (nitpicking, I admit)

My $0.02:

1. Yeah that would be nice, I think thats on the list somewhere.
2. We actually have these already.
3. I liked those too from Ruby, though not sure enough to warrant adding them.
4. Some background discussion on multiple return values, I am fine without them.
5. You mean like this?

6 and 7 could be implemented using shortcuts, though I prefer just using the method names - makes the code more readable IMO.

You mean like this?

No.

foo ||= bar

If foo is null bar is assigned to foo. If foo isn't null nothing happens ( bar isn't evaluated, so no side effects, either).

First off - thank you very much for your feedback philswenson. It is always appreciated.

1) regex literals

Its been discussed - I have mixed thoughts about whether saving a few characters is worth adding a full-fledged literal syntax. But I think it would be a good debate to have.

2) default values on methods

As Andy said, already there:

foo(Str a := "def")

3) if / unless suffixes like ruby has throw new Exception if blah

To me the reason for a construct like that is a work around for Ruby's block style, so that you can do stuff on one line easier. While I use it all the time in Ruby, I personally never feel the need for it in a curly brace language like Fan. What do others think?

4) multiple return values from a method

We don't have this yet, but I feel it is something that would be quite nice - at the very least a nice syntax to unpack a list in one assignment. Although it is hard to have that discussion without also bringing in the tuple discussion Andy referenced above.

5) ||= operator like ruby (if null then)

As Andy said already doable using the ?: operator. Helium can you explain how they are different? That is what ?: does - if the lhs is null then it evaluates to the rhs side. Although in Fan the rhs does not evaluate if lhs is non-null (so no side effects). I guess you could argue that ?: is an expression and ||= is an assignment (and the assignment might have side effects).

6) list loading via << 7) list union via | (nitpicking, I admit)

You can do this in Fan via operator overloading. It is more a question of convention than feature. Right now by convention we've been pretty strict on use of operator overloads to bool and numerics.

foo = {}
foo['key'] = 'value'
foo['key'] ||= 'otherValue'  

foo['key'] is value

bar = {}
bar['key'] ||= 'otherValue' 

bar['key'] is otherValue

Using ?: in Fan:

Str:Str foo := [:]
foo["key"] = "value"
foo["key"] = foo["key"] ?: "otherValue"

I'm not a ruby programmer, so I don't know how often it's actually used.

Hmm, that seems to be one of those that things that would be nice to have, but can be fairly simply done with an existing construct, so it doesn't seem worth adding. I'll have to pay more attention when I code to see how often that case comes up for me.