The lack of polymorphism and parameterized types makes Go the C of 2010s. This practically means that in a few years we will have someone, somewhere, creating Go++ and the story will repeat itself.
Go supports several types of runtime polymorphism, including interfaces and closures. It just doesn't support polymorphism through OO-style inheritance.
C supports runtime polymorphism, for that matter, it just requires a bit of boilerplate to set up and use function pointers and tagged dispatch.
You might be right about Go++ (ObjectiveGo?) being inevitable, though.
The mostly painful situation isn't at all what you mean, it has nothing to with inheritance at all.
In Go, it is impossible to do "container" polymorphism. That is, write a function that manipulates, say, an array or maps of "somethings", where the only thing it does with the somethings is assign them, read them (to return one), or check if two "something"'s are equal to one another.
The necessity of this functionality can be seen by the fact the Go stdlib can ACTUALLY DO THIS for the built-in functions, but no facility is provided to do the same for user code.
"The necessity of this functionality can be seen by the fact the Go stdlib can ACTUALLY DO THIS for the built-in functions, but no facility is provided to do the same for user code."
Right. Go has generic types. Channels and maps are generic types. It just doesn't have user defined generics. This is a lack.
Getting around this is creating a new level of cruft on top of Go. "Generate" and reflection are being used to work around the lack of generics. It's going to be tempting to use "generate" to invoke a macro language. That may not end well.
Swift looks a bit like "Go++" to me, at least on a purely syntactic level. I expect Apple to open source it sooner rather than later, at which point it will become a viable option to develop web-based services in.
ATS' type system looks particularly intimidating. Do you know of any company that uses it for RESTful services?
What I think makes Go attractive is not just the static typing but a combination of C-like syntax, GC, a simple type system (admittedly arguable) and a broad range of libraries. None of the languages you have named combines the first three but Swift does. If it is released as open source under a reasonable license the library situation, which is its biggest weakness at this point, should take care of itself.
>Swift's syntax is hardly any different
from languages in the ML family.
Call it superficial if you like but I consider the syntactic features that Swift derives from curly brace languages (not just the curly braces themselves but the syntax for generics, the lack of double semicolons, etc.) what makes it a lot more appealing than any ML I've been exposed to.
Beyond my own preferences I think this matters for language adoption. The name "Go++" implies it will be recruiting from Go users. (It's probably why Scala went with curly braces.) Here being associated with Apple might actually be a detrimental factor for Swift.
>All the languages in the ML family
have automatic memory
management. Be it RC, GC, or
compiler dataflow models like affine
types.
I never said they didn't. What I said was that none of the languages you listed combined garbage collection and a curly brace syntax. Rust and ATS are memory safe but their memory safety features require greater programmer effort to use (especially ATS', I imagine).
>Swift's type system, is just like any
ML language.
You're right. I was mistaken to claim the type system as an advantage Swift has over other candidates for "Go++".
That said, I am not sure about the OO model, which Swift carries over from Objective-C. I have not used OO in OCaml. How does it compare to Swift's?
>Unless Apple decides to rewrite
WebObjects from Java into Swift that
is.
While that is not impossible it is unlikely. Regardless, I expect the users of the language to port something like Java's Spark long before that happens. It will only happen if and when Apple makes the language open source, of course.
