|
|
|
|
|
|
by Animats
3749 days ago
|
|
|
Go was created to do what Google does - server side software run in huge data centers. C++ was too bug-prone, and Python was too slow. Go has the right feature set for that job. Google then provided good libraries for most of the things you'd want to do on a server. It lets mid-level programmers do competent work without much trouble. It's not a great choice for operating system development, real time work, client side code, graphics, games, supercomputing, or "frameworks". That's OK. For the job it was designed to do, the features are there. |
|
|
The Go language FAQ still states that no "No major systems language has emerged in over a decade". Besides ignoring the system languages which did emerge, this sentence misleads the reader into thinking that Go is a systems language.
And I'm not talking about garbage collection here, which is often cited as why Go can't be a systems language. GC makes it hard to write some of the applications of a systems programming language, such as OS kernels and games, but it's not mutually exclusive, and OSes have been written in GC languages before (Lisp Machines, Singularity with Sing#). It's the entire approach: Go offers its own scheduler (which is really great, but if you need to use something else, you're in for some pain) and no support of writing dynamically linked modules. It makes go very inconvenient for most common system applications, unfortunately. Essentially, it's manages to be less high level than C++ (it has fewer robust typing and features), while not being low level enough to beat C++ in the same time (very inflexible binary target, GC-only, no inline assembly).