I think the tldr; of this (often raised...) argument boils down to:
Don't use rust if you're asking that question.
If you could implement your solution in go or rust, then go is probably a more appropriate choice; it's a good high level solution for high level problems.
Rust is not a good solution for high level problems; it's a good solution for low level problems where go would be a terrible choice; and it's a good solution for high level problems where other choices are even worse (eg. C++).
They're both good languages, and you'll learn way more from picking up rust than you will from picking up go, so if you're just screwing around and want to learn a language this year, absolutely, pick rust or clojure. Go isn't on the list for 'interesting programming languages'.
...but if you have an actual problem you're trying to solve, I would be hard pressed to enumerate the reasons why you would pick rust if the problem was solvable using go. Maybe because your C dependencies would be easier to call from rust than go? That's all I can think of.
> Rust is not a good solution for high level problems
Who is saying that ? Not the Rust team, nor the Rust users …
Rust is a general purpose programming language, and it's pretty high-level (in terms of features, think about functional programming for instance). The only reason I wouldn't advise everyone to write their stuff in Rust atm, is the youth of the ecosystem (which is growing rapidly, but is still a bit too early-stage): their is no intrinsic limitation in the language that make Rust «not a good solution».
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.
> 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).
I would and many more people also would but for sure it would be harder/more complex in C/C++ than in Go. You wrote that as it would be impossible to do it in C or C++ which is not true.
I've wrote that you can do it with memory safety which is possible BUT it's more complex in languages like C/C++ that do not guarantee memory safety (it's your responsibility). If it was not possible then you would not have anything on your screen right now. I am writing that because someone that is not familiar with those languages would get impression from your comment that memory safety is impossible in C/C++ which is not true.
Verbose low level memory safety and a high level trait system is a massive step up from C++/C. It's of mixed value if you're doing something you could do in java or go. It's of questionable value if you're doing something you could just whip up in python or js.
Perhaps you're right; rather than just straight out saying go, I'll preface my answer next time I hear the go/rust question:
'Should a write my next project in go or rust?'
'If you didn't use either, would you write it in C++?'
'...no?' -> 'Then pick go.'
'...yes?' -> 'Wtf dude, there's no way you could do it in go then. use rust.'
Because Go is a garbage collected language, programs will often require more memory than they would in Rust, although pretty often that's an acceptable trade-off. If the trade-off is acceptable though, it might be worth looking at Nim and D too.
Rust is not a good solution for high level problems; it's a good solution for low level problems where go would be a terrible choice; and it's a good solution for high level problems where other choices are even worse (eg. C++).
They're both good languages, and you'll learn way more from picking up rust than you will from picking up go, so if you're just screwing around and want to learn a language this year, absolutely, pick rust or clojure. Go isn't on the list for 'interesting programming languages'.
...but if you have an actual problem you're trying to solve, I would be hard pressed to enumerate the reasons why you would pick rust if the problem was solvable using go. Maybe because your C dependencies would be easier to call from rust than go? That's all I can think of.