There's no doubt Rust is more "important" than Go in the sense that it may have a much greater impact on the software community, but the two languages don't seem to be comparable at all, and they certainly don't compete. Rust is more complicated than Go (it should be, as its more ambitious), and aimed to replace C/C++. Go, as I said, is Java Lite (and like Java, a blue-collar language). Go is great when you want to write a smallish, self-contained Java program and want to spare yourself writing a startup script and requiring (or packaging) the JVM. (I don't know anything about Lua)

Wow, go is totally not Java-lite. Trying to program in it like it is will just cause headaches. The only conceivable way that I can think of that it could be called that is because it is compiled and has a garbage collector. Otherwise... they are very different languages.

Go is what you'd get if python and C had a bastard love child that turned out different from either, but still retained some of the beauty of each of its parents.

And Nimrod would be their legitimate favorite son.

> Go, as I said, is Java Lite

Or Python+.

Interesting all the comparisons to Java, with me coming from an environment where Java is never used, never considered, largely never thought about. If Java is mentioned at all, it's usually something like "my kid took a programming class in college, and they used Java, why would they use something like that?". I suppose Cobol was like that: widely used, very widely used, but not used at all in many circles.

Probably more accurately Python--; it cuts out a lot of features from Python, a great deal of which you weren't using, some others of which there are other ways to do, and ends up with a simpler and also much faster language, in which you will sometimes miss a Python feature, but in my experience not as often as you might think. But definitely non-zero.

(By "not using", I mean for instance that in Python, like Javascript, at any moment, you may set a new method on a particular instance, and the Python runtime must deal with that, such as by spending a lot of time looking up references that never actually change in a real program. This is a really expensive feature that you are paying for all the time, yet rarely using. A great deal of the JIT speedup you can get in such languages is working out how to skip those lookups optimistically until someone actually changes them.)

I miss Python's named parameters with default values. They are surprisingly hard to replicate in Go. Also list comprehensions.

Named parameters can be sort of gotten by passing a struct as the parameter, then you can do

type fooParams struct { Name string Age int Address string }

foo( fooParams{ Name = "Bob", Age = 24 } )

Defaults are a lot harder to do in a way that doesn't just suck. You can make a DefaultFooParam that has all the defaults... but it's not pretty.

List comprehensions never seemed like a big deal to me. It's 3-4 lines for a loop, which is probably easier to read than the list comprehension anyway.

> List comprehensions never seemed like a big deal to me. It's 3-4 lines for a loop, which is probably easier to read than the list comprehension anyway.

that's totally a nope.

    def qsort(L):
        if len(L) <= 1: return L
        return qsort([lt for lt in L[1:] if lt < L[0]]) + [L[0]] + qsort([ge for ge in L[1:] if ge >= L[0]])

I just saw this several days late, but have to comment.... is that really the example you're giving of a list comprehension that's easy to read? Because... yeah no. If I saw this in a code review, the first thing I'd say is "this code is illegible, please reformat to make it easier to read"

This is classic "I'm trying too hard to make my code look clever rather than make it readable and easy to understand".

Unlike Cobol there are few circles where Java, or at least the JVM, isn't used. The ones that come to mind are .Net shops, hardware/embedded shops, very specialized applications (scientific, etc.), console game developers, or – and this is probably the largest one – small(ish) web startups: your Ruby/Python/Javascript crowd before they need to scale. Many of those in the last group would still have some Java/JVM.

> [...] there are few circles where Java, or at least the JVM, isn't used

I was making the very opposite point. I think Java programmers tend to underestimate the circles where it is not used. In particular, it seems that those who would not describe themselves as professional programmers but who nevertheless need to program tend to not use Java. And it's not all Python/Perl/Basic/Tcl/Bash; C++ (and C) are also widely used.