What are the major differences between row polymorphism and subtyping
Subtyping says given an expression of one type we can give it also another type.  We say the former is a subtype of the latter and this subtyping relationship induces many other relationships.  In symbols,
$$\frac{\Gamma\vdash E:S\qquad S&lt;:T}{\Gamma\vdash E : T}$$

The key thing here (and the reason I reviewed it) is that the same expression is given two different types.  In parametrically polymorphic languages with implicit type instantiation we have the following subtyping relationship:
$(\forall \alpha.\tau) &lt;: \tau[T/\alpha]$ for all types $T$.  If type instantiation is explicit like in System F, this subtyping relationship doesn't hold.

As a bit of an aside, we could say a language with row types (usually) has  subtyping relationships of the form $\{\ell_1:A,\ell_2:B\} &lt;: \{\ell_2:B,\ell_1:A\}$ giving rise to $\{\ell_1:A,\ell_2:B\} \cong \{\ell_2:B,\ell_1:A\}$ where $S \cong T \iff S &lt;: T \land T &lt;: S$.  However, the way this is actually handled is by changing the notion of equality of types (i.e. unification) so that $\{\ell_1:A,\ell_2:B\} = \{\ell_2:B,\ell_1:A\}$, i.e. they unify.  In this case, the subtype relationship is the trivial $T &lt;: T$ one.

Usually when we talk about a language with subtyping we mean one with a non-trivial subtyping relationship on ground types, i.e. types without free variables (which, of course, can and will generate subtyping relationships for non-ground types).  So a system with row polymorphism like Roy's is not a language with subtyping in this sense, though it does have the non-trivial subtype relationship that comes from any implicitly instantiated parametric polymorphic language.  Structural subtyping, on the other hand, explicitly states non-trivial subtyping relationships for ground types.

By row types, I'll mean having a non-trivial unification as described above or an equivalent.  Without this, row types are little more than nested tuples.  Note, row types are independent of parametric polymorphism; I do not mean to imply row variables.  From the argument about $(\cong)$ above, structural subtyping implies row types but not vice versa.  Parametric polymorphism is orthogonal (in the sense the you can have or not have it, there are definitely interactions) to row types or structural subtyping.  A system with structural subtyping + parametric polymorphism subsumes row type + parametric polymorphism (assuming some kind of "record union") in the sense that every term in the latter can be typed with the same type in the former.   The former is just able to type with additional types as well.  Using Brian's example, in a system with structural subtyping and parametric polymorphism answer would have the same type as in the row typing version, but it would also have the subtyping version's type as well.

So you presumably want to compare row type + parametric polymorphism with structural subtyping without parametric polymorphism.  The key benefit of the former (and sometimes drawback) is that it allows you to propagate information globally.  When $\rho$ gets instantiated to { c : Number }, everything that ever unified with it gets instantiated as well.  This may percolate up to the root of your application.  Carrying around row variables through large sections of code is not uncommon.  Subtyping's approach is to forget information: going from a subtype to a supertype loses (type) information.  This can often be what you want: there's a common type you care about and everything else is irrelevant details.  My bias is toward maintaining as much type information as possible and only discarding it explicitly.  The downsides of subtyping's approach is often evidenced by programs that are type correct but only because types were pushed to a(n informationless) "top" type, e.g. the empty record.  Reiterating, parametric polymorphism (in general) preserves type information, subtyping intentionally loses it.