On Tuesday, 9 April 2013 at 08:17:40 UTC, Russel Winder wrote:
On Mon, 2013-04-08 at 23:51 +0200, Paulo Pinto wrote:
[…]
Lets not forget the lack of generics, the religious view
against dynamic linking and errors for unused variables and
imports.
OK so every language has it's religious side: Go's obsession
for static
linking is indeed a problem and cgo is not really the solution.
I already advocated in go-nuts that an import mechanism similar
to Object Pascal, D and many others makes more sense, to no avail.
Another religious element is that the language is tiny (which I
find
good), and distributed version control for imports is included
in the
language (which I think is brilliant). I want this is C++, D,
Java,
Groovy, Python, Kotlin, Ceylon, Scala. etc., etc. Why are 21st
century
languages still not connected to 21st century version control?
For me,
Go has introduced so seriously sane innovation here (*).
First, not all enterprise developers happen to live in GitHub
land or
the other source control urls they support.
Second, as nice as it may be, it has issues with versioning,
branching and security access for the said URLs, which they don't
seem willing to fix.
In the enterprise world not everyone compiles from source
everything.
This raises issues with their approaches.
I am not a fan of the unused variables and imports being
errors, but I
can live with that. What I can't live with is the fascism of
gofmt. Yet
I do :-(
I have yet to find anyone who can tell me why Go must have
generics with
a cogent argument that makes sense to me. OK so C++ has
generics;
templates, how wonderful. Java has generics, and type erasure,
great.
Scala, Ceylon and Kotlin have huge infrastructure to reify
generics on a
platform with unreified generics. At least C# got that right.
Performance and avoiding to write casts everywhere in otherwise
generic code.
I find really unfortunate that most people seem to always focus
on generics in the Java world, when almost every single static
language has some model of generics.
Why is the
Go idea of total separation of state and behaviour not a good
experiment, after all JavaScript, Python, etc. have shown this
works
even without static type checking.
Dynamic languages are generic by nature, of course they don't
need generics.
