Go rant

[retard]

Mon, 14 Dec 2009 19:51:10 -0500, Sean Kelly wrote:

> bearophile Wrote:
> 
>> This is a mostly boring rant against the Go language:
>> http://monoc.mo.funpic.de/go-rant/
>> 
>> Near the end it contains an interesting bit:
>> >Too, why this divide, again, with reference types and value types? Did
>> >they not learn from the problems this caused in Java? While Java
>> >slowly struggles its way free of that tarpit, the Go designers leap in
>> >headfirst.<
>> 
>> Can someone here explain me this problem better?
> 
> If I had to guess I'd say that he's referring to that fact that value
> types in Java are second-class citizens.  The standard containers can
> only hold objects, so boxing is necessary, and that's such a pain in the
> ass that now boxing is automatic, leading to a lot of hidden
> allocations.  I wouldn't think this applies to D however.  D is a
> systems language and so must provide value types to deal with explicit
> memory layout of structured data, etc.  Also, D uses templates instead
> of generics, and so doesn't have any of Java's container problems. 

The fact that boxing is necessary in Java has not so much to do with it 
not being a systems programming language. The problem is that Java VM 
doesn't reify the those types on runtime. I could easily write a new VM 
for Java and avoid all that boxing (although not being nearly as advanced 
in other areas). C# implementations also manage to solve this by not 
erasing that type info.

I don't know why the Sun engineers aren't fixing this. I guess there are 
some political and organizational problems involved. They fear that Java 
is getting too complex so they keep it simple, but slow and unproductive. 
That's not the only problem in JVM. Languages are getting more and more 
functional these days and many enterprise Java projects use ad-hoc single 
method interfaces to emulate lambdas. They're now solving the dynamic 
language support in Java 7, but JVM probably isn't getting c++0x/d/c#/
python/ruby/php/smalltalk/functional language like closures. Soon 99.9% 
of active programming languages have closure support - being able to say 
list.filter(\e => !e.isBadElement) seems to be the next cool thing..

> I have absolutely no idea how all this applies to Go, however.

Well, if it doesn't run in a VM (c++/d like template implementation) or 
global program optimizations are done, this shouldn't become a problem. I 
might be wrong, though.