A couple of things of the top of my head:
* goroutines and efficient multithreading, both in terms of syntactical constructs and language implementation. Go doesn't have await/async because it fundamentally doesn't need them.
* a type system that works without inheritance or subtypes but rather static duck typing, quite different from any other language
* very memory efficient layout of data structures, internal pointers
* small set of builtins with maps, slices, channels (that do have 'generic' types for their members) to reuse, rather than re-implement
* comes with a well designed build and packaging system
* comes with a very convincing standard library
It's worth taking a look. C# surely is a nice language, but it inherited many of the design flaws of Java, in particular with respect to the runtime and memory layout. Google does use Java internally a lot, Go gets uptake in spite of that competition.Regardless of language merits, licensing C# can indeed be a problem, as can be the operational complexity of managing Windows running on hundreds, thousands, ten thousands etc of machines.
* Their implementation sucks so much that most decently built
concurrency implementation will beat Go-routines by a wide
margin. Just have a look at all those people on the Go mailing
list whining about the scheduler. Not even talking about the
fact that building concurrency mechanisms into the language is
plain stupid. We all saw how well that worked out in plenty of
other languages before.
* You know why pretty much no one uses structural typing?
It's not because the “brilliant” designers of Go “invented” it,
it's because most language designers realized that it is a poor
idea before shipping the language. I think it is pretty telling
that in languages which support both nominal and structural
typing pretty much nobody is using structural typing.
* I'm not seeing how a language which requires passing around
void* pointers in every data-structure and casting at pretty
much every corner can be considered memory efficient.
* Hard-coding collection classes with special cased syntax into
the language, so that everyone who needs to have something
slightly different is completely fucked ... what is this? 1980?
* Their packaging system is an unmitigated failure. Nuff' said.
* Do they have a working Unicode implementation yet (I mean more
than the “We use UTF8 for strings ... which is like 0.5% of
what Unicode is about”)? What about (Big)Decimal? A working
date/calendar abstraction which isn't a terrible joke?It's worth noting that they're aware of the schedulers problems, and Dmitry is working on a significant revamp. https://docs.google.com/document/d/1TTj4T2JO42uD5ID9e89oa0sL...
If you actually checked your “claims” you would see that people are singing so many praises that the mailing list is continually filled with proposals to fix the worst parts of Go's packaging system.
If you actually have problems with Go's packaging, and care about it enough to write as much as you have, why didn't you simply point out the flaws?
> So your post is meaningless and useless.
Can I hand you some tissue so that you can get rid of your angry tears? That Go reality distortion field seems to be strong. > why didn't you simply point out the flaws?
Because there are already dozens of people who did that already?Do you really expect people to scour a newsgroup to find the meaning of your vague and unsubstantiated claims?
Someone could similarly say "Scala is an unmitigated failure of a language. If you want to know why, just track down its detractors on the Internet. There are dozens." Would you be impressed by that?
Go is from the unixy C culture, C# is from the Java/win32 culture and the libraries and tools reflect that.
Having said this, Go can be a nice replacement for many use cases one would use C for.
"Yes, C would be hardly mentioned here if it wasn't being developed at Bell Labs."
Fully agree, most likely if UNIX hadn't been adopted at important American universities, C wouldn't have spread as it did.
I don't think you actually have much understanding of enterprise environments otherwise you would know how ridiculous the idea that Go or C# is going to take over from Java anytime soon.
I know I never managed to like generics in Java. Don't know C#, though.
- Lack of type definitions. If it was possible to declare types in Java, the generic declarations wouldn't need to be so monstrous;
- The common co-variance/contra-variance issues with the generic types;
- Lack of support for builtins;
- No way to specialize generic algorithms for specific types