"Model 2" prototype status

[Vitaly Davidovich]

I don't know why mutability of structs in .NET keeps being referred to as a
mistake.  Sure it can lead to bugs, but so can many other things if not
used properly.  It's a useful tool to have in some occasions (given .net
supports passing them by ref).

sent from my phone
On Aug 4, 2015 3:10 PM, "Simon Ochsenreither" <simon at ochsenreither.de>
wrote:

>
> > Other languages and platforms have attempted to unify objects and
> > primitives -- with varying degrees of failure and success. Paul
> > Philips' talks circa 2013 -- at JVMLS and Scala PNW -- highlight the
> > challenges of trying to unify references and primitives on the JVM while
> > retaining any sort of compatibility. The poor performance of Scala
> > streams over "primitives" (see Aggelos Biboudis' paper on this) proceeds
> > mostly from this attempt to unify; the result is that they can't prevent
> > the boxing, and performance suffers. .NET took the path of unifying
> > structs and objects (but regrettably, allowed their structs to be
> > mutable.) This has been partially successful but also less than
> > perfect; we've tried to learn what we can from their experience.
>
> I have seen this claim quite a few times already, and I think it's not a
> fitting
> characterization of the issue.
>
> I'll try to clarify a bit:
>
> * The whole issue with unification and the Any/AnyRef/AnyVal hierarchy is
> that
> we (in Scala) have to fight the JVM for every tiny bit of additional
> correctness.
> Sometimes, it's just a case of diminishing returns given the constraint
> that we
> want to have a execution model where vanilla class files are executed on
> the
> JVM, and not some "ScalaVM inside the JVM" approach.
> If the JVM provides better support for these things, most of the issues we
> see
> in Scala will just go away for good.
> * The performance of Scala collection operations in the paper you
> mentioned is
> unrelated to that.
> Constructing a data structure after each operation is expensive (and a bad
> idea
> from my POV), boxing is probably the least pressing issue. The paper [10]
> referenced by Biboudis doesn't support his claim in my opinion, either. Of
> course, getting rid of boxing is great, but no amount of boxing
> elimination can
> turn an O(n) collection design into an O(1) collection design. (Which is
> pretty
> much what ScalaBlitz does, last time it looked: It tries to eliminate the
> construction of intermediate data structures, of course things get boxed
> less if
> less work is done, but that's kind of obvious.)
> I think the .NET devs have done a pretty good job overall. Apart from
> allowing
> mutability, not supporting Void/Unit and completely messing up the
> semantics of
> static inside of generic classes, things work quite well. They are
> sidestepping
> the whole variance issue, but I wouldn't claim that that's not a valid
> solution
> for them.
>