"I feel like writing about the Go programming language (or 'Golang') today, so instead today's topic is computer stuff. For the record, the language I've programmed the most in has been Python, so that’s the perspective I'm analyzing it from." Some good and bad things about Go.

I took a look at Rust awhile ago... but it just didn't look like a fun language to use. So I'm curious about why you find it more suitable than Go.

D is one of those languages that I keep meaning to poke at, but never get around to (because there's really nothing there except nicer syntax.)

As for Go:
I don't care for exceptions. Multiple returns with an error works well in my opinion.
I don't frequently use enumerations.
Generic types would be nice (or rather better polymorphism support in the same vein as Haskell's would be nice, but then again most of my complaints with Go end up being "well if it was more like Haskell...".)
CGO is certainly a weak point of Go's...
I have no great desire for dynamic linking, so I really don't care if only static linking is available by default.
I'm not a huge meta-programming fan... so the lack there isn't a big deal to me either.

To me, the nicest thing about Go is its standard library and documentation. I also like its clean syntax (for a C-like language.)

The only thing I don't like in Rust is the Perl syntax influence in how pointers get declared.

D is one of those languages that I keep meaning to poke at, but never get around to (because there's really nothing there except nicer syntax.)

It is really a better C++, not only syntax.

You get to do meta-programming with proper language support, not the C++ template hacks.

Safer than C++, because you are require to state which code is unsafe. In C++ even if you restrict yourself to the safe language constructs, you need a static analyzer to proof it.

Whereas D is safe by default unless you make use of system modules/sections.

Go strides exited already in D before Go was created.

Additionally both languages have:

- some form of automatic memory management
- modules
- support for concurrency
- follow the school of thought where the developers have the same facilities as the compiler writers to create data structures.

You may want to check out the ATS language, though I'm still warming up to the "look" of the syntax. No time to post my thoughts, so here's the blurb from their site. (There's also a kernel and some linux drivers written in ATS):

"ATS is a statically typed programming language that unifies implementation with formal specification. It is equipped with a highly expressive type system rooted in the framework Applied Type System, which gives the language its name. In particular, both dependent types and linear types are available in ATS. The current implementation of ATS (ATS/Anairiats) is written in ATS itself. It can be as efficient as C/C++ (see The Computer Language Benchmarks Game for concrete evidence) and supports a variety of programming paradigms that include:

Functional programming. The core of ATS is a functional language based on eager (aka. call-by-value) evaluation, which can also accommodate lazy (aka. call-by-need) evaluation. The availability of linear types in ATS often makes functional programs written in it run not only with surprisingly high efficiency (when compared to C) but also with surprisingly small (memory) footprint (when compared to C as well).

Imperative programming. The novel and unique approach to imperative programming in ATS is firmly rooted in the paradigm of programming with theorem-proving. The type system of ATS allows many features considered dangerous in other languages (e.g., explicit pointer arithmetic and explicit memory allocation/deallocation) to be safely supported in ATS, making ATS a viable programming language for low-level systems programming.

Concurrent programming. ATS, equipped with a multicore-safe implementation of garbage collection, can support multithreaded programming through the use of pthreads. The availability of linear types for tracking and safely manipulating resources provides an effective means to constructing reliable programs that can take advantage of multicore architectures.

Modular programming. The module system of ATS is largely infuenced by that of Modula-3, which is both simple and general as well as effective in supporting large scale programming.

In addition, ATS contains a subsystem ATS/LF that supports a form of (interactive) theorem-proving, where proofs are constructed as total functions. With this component, ATS advocates a programmer-centric approach to program verification that combines programming with theorem-proving in a syntactically intertwined manner. Furthermore, this component can serve as a logical framework for encoding deduction systems and their (meta-)properties.