I get where your coming from (I think... let me know if I've missed your point), but I think the purpose of Go's type system is to offer some safety while emulating a dynamic language.
In some cases, rigid type-safety is necessary, but I have trouble taking this criticism seriously while languages like Python enjoy extreme success. If Python can be insanely useful (and acceptably safe), then why not Go?
tl;dr: Go is not -- from a practical point of view -- a static language. (Note to pedants: I'm talking about Go's use, not it's formal nature).
Better tl;dr: Think "Python's type annotations" rather than "Rust".
Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that.
To me, it's a replacement for Java, not C++. I think that's a reasonable target.
Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.
>Then it needs to stop calling itself a 'systems programming language.'
Why must a systems programming language be static and strongly typed?
I don't mean to be flippant, but to me, 'systems programming language' means 'a language that facilitates productivity for systems programmers'. By that description, Go certainly qualifies.
>Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.
Point taken, but not all system's programming requires such extreme safety.
ASM isn't strongly or statically typed, so that's obviously not a requirement for a "systems programming language".
The requirement most people mean, when they say "Go isn't a systems programming language", is the ability to acurately control execution. With Go, you can't, because of GC.
Google's definition seems to be "building large systems". For the types of large systems Google wants to build, Go works very well.
But others define it as "building operating systems". Go is horrible for that because of garbage collection and inability to directly access the hardware.
>>>
The Go programming language is an open source project to make programmers more productive.
Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.
<<<
Ok, well that's funny. You pick "novel type system" apparently because you find it especially absurd, but I find that that's the only accurate on on the list.
Go isn't expressive, nor concise, nor does it have a flexible type system. But if any of its claims are true, it's that its type system is at least a little novel.
Sure it's not the most exotic type system out there, but its interfaces are very useful and they aren't found in many other languages (not implicitly satisfied interfaces, that is).
Except there is a fairly large difference with interface{}, in that it is typed. interface{} is more like Object in java than void* from C. If you incorrectly cast an interface{} to a type it's not, it will be a runtime error.
Well, yes, kind of. It's not something you would really use a lot. It doesn't help you with generic types, but only with generic functions. Since it only makes sense when coupled with macros, it really only helps with functions that are written out but accessible by the same name. For example, selecting sinf() or sin(), or writing a max() function.
No chance to replace Java, when Java is all about ecosystem, tooling, maturity and talent pool. And it has generics.
I mean I am no Java expert, but e.g Android Studio is miles ahead anything the go team will be able to ship in the next few years. And I don't think they're even focusing on building such tools since they seem to be stuck on building a debugger right now.
You can't distinguish them at runtime from each other.
Your memory consumption is higher, because type erasure requires elementary types to be boxed. Since the boxed value is itself allocated somewhere else, there's indirection. Indirection means CPU stalls. Another consequence is data cache pollution. There are just 512 of 64 byte L1D cache lines.
But if you're worried about that amount of memory consumption, why are you using Java? If you need that much control over memory, Java may not be the language for you.
Ditto if you're worried about the performance hit from cache misses.
Go was never a systems programming language as soon as it made the decision to be garbage collected. Don't get me wrong: in many cases I like GC but you'll never dethrone C/C++ for many use cases with a GC language. I find it interesting that many Go pundits I speak to just don't seem to get this.
I wouldn't even say Go's target market is Java. I'd say it's actually Python. Rob Pike has spoken about this [1].
I like Python. It's fun but for anything nontrivial I've become disillusioned with it because the supposed productivity gains are offset by having to write unit tests for spelling mistakes and typos. So I like Go for this purpose. It's not quite as expressive as Python but it's in a sweet spot IMHO.
The Oberon and LISP machine people would disagree given they wrote whole OS's and platforms in GC languages. The trick is to support manual control & unsafe where necessary. I know it can work for Go with small changes because it worked for Wirth languages that Go was based on.
I'd love support for "check this project" that would essentially be similar to compiling a Go project.
Python is awesome for so many things:
- Quick project iteration
- Web development
- Testing (test suite is actually pretty sweet!)
- General purpose programming and scripting
Currently, not the most productive tool for large projects or complex projects, or projects where static analysis pays huge dividends (usually this fits in one of the previous two categories anyway).
Doesn't mean it has to be: but it'd be really nice to have...
It's one class of errors that doesn't typically happen with a static compiled language, people like to feel 'safe' about the dullest things but typos can be found pretty easily by running the code you just wrote in a REPL or at least structuring your application so that you can quickly get it to the same state to test live... But honestly you can just repeat the typos in your tests, or make new ones, in any case for me at least it's a class of error that comes up very rarely regardless of whether I'm using mitigations like auto-complete. And lastly I'd think if you were unit testing "properly", aiming for good coverage, which unit testing advocates will say you must do regardless of a static or dynamic language, your unit tests should catch various typos as a side-benefit. Testing things like int in -> int out or "reading this function it calls these methods on foo, here's a mock foo and we're just going to make sure all of them get called as expected and I didn't misread/mistype either the code or the test code" seems insane.
I don't think every language needs to be rigid - something like TypeScript's gradual, unsound typing can be very valuable, and I certainly think there's a place for a language where casting is easy and idiomatic. But you can do that and still enable generics, covariance and the like - as TypeScript in fact does.
What's incredibly infuriating to see a language that clearly has everything it needs to offer generics - indeed it clearly has a generics implementation already written, since the builtin types are generic - but it won't let me use them.
In some cases, rigid type-safety is necessary, but I have trouble taking this criticism seriously while languages like Python enjoy extreme success. If Python can be insanely useful (and acceptably safe), then why not Go?
tl;dr: Go is not -- from a practical point of view -- a static language. (Note to pedants: I'm talking about Go's use, not it's formal nature).
Better tl;dr: Think "Python's type annotations" rather than "Rust".