Program your next server in Go

I'm saying it.

The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in? no.

...rust is verbose. It is statically typed, it is less productive than some other languages and it is hard to learn.

Now, you get a whole lot of other benefits in exchange for that, absolutely, and technically speaking, rust is a super awesome and sophisticated language.

...but right now, it has neither the ecosystem nor simplicity for picking up and practically solving high level problems.

If you have a problem, right now, you want to solve: pick go.

...unless your problem is something that rust would be better at, and those things are low level things, like building game engines, not high level things like building web applications and cross platform desktop chat applications or machine learning solutions to driving cars.

You can build high level applications in rust, and in C++; the point I'm making is that unless you actually have a reason for picking them (and there are plenty...), don't.

Pick the tool for the job; rust is a great tool for the right job.

Go is a better tool for a lot of applications; and a totally useless one for others.

/shrug.

We don't need to pretend rust is general high level language you should pick up and use for any problem domain. It's not. You're shooting yourself in the foot if you use it as though it was.

Rust's type system is a bit less awful, and it's better oriented towards immutability-by-default. Its concurrency model is more explicit (which is to say, more verbose to use, but gives you a lot more control).

In a situation where Go is acceptable (i.e. GC is acceptable) you should probably be looking at OCaml (probably what I'd recommend; http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... may be worth a look) or Haskell rather than Rust though. If you're talking about a long-running server process then I'd add Scala/Ceylon/F# to the list.

> The fact that you can synchronize on literally any object means that your object lock is effectively part of your public API

I'd argue that the fact you can lock on any object is a strength. These days, hardly any Java developer will use synchronized on methods and instead prefer the idiom:

    public class A {
        private Object lock = "";

        public void foo() {
            synchronized(lock) {
            }
        }

This allows Java code to be extremely granular in what gets locked, which has enabled very powerful multithreaded constructs and libraries such as ForkJoinPool and many others described in the Java Concurrency In Practice book.

Java for sure has good tools for concurrency, and you listed some of the very interesting choices!

However the flexible nature of Java concurrency also has the drawback that you might need to integrate different libraries that utilize different concurrency solutions (blocking threads, actors, non-blocking eventloops) with each other. This can end up in a lot more effort than if you try to use multiple libraries in an ecosystem with a single opinionated concurrency solution (like Go for blocking IO or node for pure nonblocking IO).

The weakest ecosystem regarding this is imho C++, where most concurrency/IO solutions only work well if you don't try to also use other solutions in parallel (e.g. QT plus glib plus boost asio plus libuv...).

> The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in?

I agree with that, Rust is not a scripting language. Dynamically-typed scripting languages have proven their efficiency for prototyping.

> rust is verbose. It is statically type, it is less productive than some other languages

Than scripting languages yes, but it's exactly on the same side than Go on this point. Scripting languages are extremely convenient for small projects, but are more difficult to maintain in the long run if the project grows too big. (I personally live coding JavaScript, and a the project grows we are progressively add a static-typing layer (flowtype.org) to our code for the sake of maintenance).

> it has neither the ecosystem nor simplicity for picking up and practically solving high level problems.

There is a real trade-off between scripting languages (Python, Ruby and Nodejs), and statically-typed ones (Java, Go, and Rust), but it's not related to being high-level or not. In term of abstractions and features, Rust is at least as high-level as Java & Go.

> If you have a problem, right now, you want to solve: pick go.

We are using some Go at my company because we wanted to follow the trend, but frankly unless you want to built a simple system with no dependencies, Go is not ready to solve problem «right now» either, because the ecosystem is still really poor. If you have a problem, right now, you want to solve, you should probably still pick Java over Go, even if a lot of people (me included) don't like Java … Basically I think Java is the most important factor of success of the Go language: Go feels like Java, but in a younger and trendier way.

> We don't need to pretend rust is general high level language you should pick up and use for any problem domain. It's not. You're shooting yourself in the foot if you use it as though it was.

Rust is a «general high level language», with the same high-level generality than Go or Java.

I bet one can chose any* Go or Java code sample, and rewrite it in Rust with around the same amount of code and without introducing any memory issues (what you wouldn't be able to do in C or C++). I think that's a good illustration of Rust being a «general high level language».

*unless it depends on a library that has no equivalent in Rust (as I said before, the youth of Rust's ecosystem is the reason not to use Rust in S1 2016).

> and it is hard to learn.

It is indeed, no discussion about that.