Comparisons to D or OCaml would be interesting (it'd be good to see that "new language for 0install" post redone with nim as one of the candidates). I think people are shoehorning Rust into the "compiled, typesafe, but strict and impure general-purpose programming language" niche, just because there aren't as many nice options there as we'd like.
Why would you say it's not competing with D and Rust? Performance-wise Nim should be in the same ball-park, and you can do systems programming in it. For me Nim is a universal language which I can use for almost anything.
Nim does not have the memory safety without garbage collection features of Rust. If you want memory safety in Nim, you have to use the garbage collector (which, last I looked, is not thread safe either, although I see that Boehm is now an option).
It's easy to write (a) an unsafe language that has no GC, or (b) a safe language that relies on GC for safety. It's also easy to write a language that is in category (b) but lets you drop down to category (a) in an unsafe dialect. It's a very difficult problem to write a safe language that does not rely on GC, and I know of no other industry language that has done it. Unfortunately, people often lump Rust into categories (a) or (b), without realizing that what makes it interesting is that it isn't in either. Nim may be in category (b) (if the thread safety issues in the GC have been solved, or you use Boehm, or your app is solely single-threaded) with the ability to drop down to category (a), but it is not in Rust's category.
While Ada doesn't provide the parallelism safety mecanisms from Rust, is is pretty much a safe systems programming language, specially the SPARK dialect.
And I do conceed that using RAII or memory pools is a bit more cumbersome than in Rust.
EDIT: Forgot to add that for me systems programming safety has been for a long time what Modula-3, Oberon and Ada offer. Only recently it became clear to me that Rust safety module is more broad.
Yeah, Ada/SPARK is safe too. But as I understand it achieves that by removing deallocation (from a single untyped heap) entirely, which is pretty limiting, though sufficient for a lot of embedded work.
In general Ada code, deallocation is considered unsafe and requires specializing the Unchecked_Deallocation() procedure. This is because Ada 83 allowed for optional GC.
In Ada 83, the safe alternative was to use memory pools.
With the newer revisions, support was added for RAII and Ada the ability to define custom refereced counted data structures, similar to how they are doing in C++.
So speaking of Ada 2012, you can get Ada's safety in terms of contracts, data types, numeric ranges, constrained types, access types (Ada pointers).
For heap related safety, it is possible if RAII, memory pools or RC access types are used. But like C++, this is one area where the compiler doesn't force the developer to use it.
D maybe, since it has a GC, but Rust not as much. A lot of defaults are different, affecting how libraries and idiomatic code are written and what situations it can be used in without turning things off or avoiding features.
Rust is where you can write code that relies on a custom allocator. Or a program that doesn't allocate memory. It's usable for the really low level stuff. Because of this everything must be explicit. Nim is implicit. It doesn't require you to declare a main() function, for example.
There's 1 thing that can't be done in Nim that you can do in Go though. And that is the goroutine system. Something like that needs to be explicitly baked into the language. You can try to emulate it with your own thread pools but you will never get the same level of preemption.
However few people will ever need this feature, and erlang/elixir probably does it better, though at a the cost of speed.
Just about everything is better than Go. Nim, Rust, OCaml, Haskell... Did you read the submission? And for further enlightenment, the link to the previous post on the blog about what makes Nim special? Here's a link to a rant comparing Go and Rust, which includes some links of its own highlighting further issues with Go: http://www.quora.com/How-do-Go-and-Rust-languages-compare
I like to think of Go as a niche language with excellent tooling for small-medium microservices and various forms of networking clients and servers. When you look at it in that light, it's not a bad language. It's an okay language missing a lot of features (many based on good intentions, some due to what I consider poor design) that could make it a good language.
Rust is objectively much better, but I suspect that for the next 5 years, Rust will only remain popular for systems programming but not application/web dev, and Go will only remain popular for what it's currently doing but not systems programming (with some semi-exceptions like Docker and Kubernetes, though that's not really systems programming).
I've read both the submission and the articles that exist inside that Quora link you posted and I am still not convinced. IMO what makes a language better is end products and not features. When Rust becomes stable, its community will produce great software but I don't think all of the rest languages you mentioned have produced (or will do) better software than Docker, Kubernetes, OpenShift, etcd, btcd, and a ton of other Go software.
> IMO what makes a language better is end products and not features.
It's useful to distinguish between "the language" and "the tool". Some programming languages are terrible from a language design perspective (PHP, JavaScript, MATLAB), but they still have great tools (IDEs, build tools, package managers) and libraries to help programmers create good and interesting software.
The tooling around Go is good but not that great. What makes Go better than all those languages is that it's more complete: a language that does not get into your feet, good tooling, great community, and more. IMHO saying that a language is better or worse based only on "the language" is silly.
From my personal perspective - it's a major plus when choosing a language - under the general auspices of "readability counts". I find Python-like languages much easier to read and maintain - and significant whitespace is a not-insignificant factor in that.
It's an advantage for me, not for you. I've had experience with both and I prefer significant whitespace. The only place where I found it to be a problem was in Jade templates since HTML is kind of white-space sensitive (spaces between tags cause spaces in the output). I do like programming with significant whitespace.
No, the Python community consists of a mix of people who think that the manner in which whitespace is significant in Python (most languages have significant whitespace of some form) is advantageous, people who think it is neither advantageous nor disadvantageous that are attracted to the language for other reasons, and people who think that it is disadvantageous, but not so much as to negate other advantages they see in the language.
It is a mistake to conclude that because language X has feature Y, the entire community around language X thinks that feature Y is a positive feature.
As a Python programmer, I find the Nim version needlessly cryptic, glyph-laden and ALGOL-esque, with many of the unattractive traits of Python from 10-15 years ago. If I get the choice to start out in a codebase which looks like this from brand new, I'll certainly pass. That's sad when "prettier" is really all that's being offered here.
Nim can't be a faster Python when it isn't a Python, but a much younger language which lifts a few cosmetic choices but intentionally breaks with Python in large ways. If it is trying to replace Python, many of these breaks are poorly chosen and reflect a lack of understanding of why Python and its ancestors were unique.
Aside from this, many of the practical refinements of Python are dropped in favor of fancy and shiny features that are better for arguing on HN than actually using. If I really want macros, Lisp never went away, but they aren't doing Nim's readability any favors.
Go is much more mature than Nim and encapsulates a huge amount of thinking and experience in language and compiler design. Nim would like to be Go. But it isn't.
It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.