It's great news. Hopefully there will be a node-like ecosystem for writing small services on Linux soon.
With F#, Swift and C# available, hopefully the proliferation of Javascript can be slowed on the server (without people running to Go).
With the .NET Framework actually declining, Swift still being far away from the server and frameworks like Meteor, JS seems to have a really good position.
With that said I will root for Clojure + ClojureScript. One could theoretically build a framework much more advanced than Meteor, on the same code-sharing principles.
It feels much too pragmatic for my taste. Exactly the kind of thing to come out of Google, to solve their type of problem (scalability, deployment are much more important than the code itself). Personally I don't have googles problems (few of us do!) and I really like a good type system, with algebraic types/pattern matching/generics
C was unprincipled and pragmatic too, it was created with the goal of making UNIX portable. Still, C became one of the most popular and influential languages.
While I prefer ADTs/generics too, let's not forget that many people are less principled and pragmatic factors influence language choice as much (toolchain, ecosystem, popularity, familiarity).
The success of UNIX is inseparable from C and vice versa. C made UNIX one of the first portable operating systems and, by virtue of being low-level, provided performance.
There are good reasons that these startups weren't using OSes using Algol and Mesa. You seem to imply that the success of C and Unix is some historical accident as a result of two startups picking Unix randomly, and their choice was bit a function of the technical properties of UNIX and C. Which, is of course, nonsense.
Sun used Unix because Sun was co-founded by Bill Joy. By that time, Joy was already deeply involved in Unix (per BSD). If he didn't find Unix and C likeable and up to the task, they would have made different choices.
SGI and Sun were just one of many catalyzers, like a lot of programming languages have catalyzers.
Having had exposure to both C and Pascal at around the sane time, I vastly preferred working in C.
I do think there's something intrinsically good about it compared to other contemporary systems languages - I don't think it's just that it tagged along with Unix.
I use Go a lot for backend stuff, and I agree with you. There is a lot of stuff you can do with interfaces to ameliorate the lack of generics--but you still end up missing generics and algebraic types.
It feels "pragmatic" in that Go follows "YAGNI" almost to a fault. It makes the argument that repeating yourself can sometimes be a better choice than more abstraction to increase code clarity. Some disagree with that, which is why it's nice to see other languages taking on similar areas that Go tackles but with differing choices in that area.
If you write Go code, you will realize you will actually not hit that problem often at all.
Right now the annoyance I hit more often is the inability to map a []Foo on an attribute .Name (string) to get a []string. I do that in ruby all the time, and with Golang it really sucks to do a for loop to collect stuff appending to a new array.
people.map(&:name) => ["Joe", "John"]
vs
a := make([]string, 0)
for _, p := range people {
a = append(a, p.Name)
}
