How is go better than rust?

[Theemathas Chirananhavat]

As rust 1.0 is almost here, I can point out quite a few things that rust is better than go. However, I don't really see how go is better than rust. As both rust and go are meant to replace C++, they would definitely become rival languages.

So, how is go better than rust?

[Francisco Dalla Rosa Soares]

Do you really have to put the question in this "I want a flamewar" way?

Why don't you write an email or blog post comparing Rust and Go and let people have a discussion based on that instead of using this challenging and, depending on the interpretation, aggressive language?

This list is for Go users and I don't think nobody here has the obligation to convince you that Go is better than Rust. 

They both have different concepts and views of what is important so it's you first have to define your paradigm, your starting axioms to then, based on those, decide what is "better" or "worse" as those are very very relative concepts.

On Fri, Dec 12, 2014 at 11:02 AM, Theemathas Chirananhavat <theem...@gmail.com> wrote:

As rust 1.0 is almost here, I can point out quite a few things that rust is better than go. However, I don't really see how go is better than rust. As both rust and go are meant to replace C++, they would definitely become rival languages.

So, how is go better than rust?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Gerrand]

On 12 December 2014 at 13:02, Theemathas Chirananhavat <theem...@gmail.com> wrote:

So, how is go better than rust?

This is a silly question.

There are a lot of reasons to choose a programming language, and everyone's selection criteria are different.

They are different languages for different purposes. This is golang-nuts, not apples-oranges-compare.

Andrew

[atd...@gmail.com]

*Sigh*

[Dave Cheney]

Excellent response Francisco.

[Jesse McNelis]

As many people have noted Rust and Go are quite different languages
with very different approaches.
C++ has traditionally been used to solve a very wide range of
problems, there is lots of space in there for a variety of approaches
to replace C++ in a variety of areas.

Rust gains enforced static thread safe memory by trading it against
lots of bookkeeping and annotations.
Go tries to avoid a lot of that bookkeeping and annotations and
instead relies on dynamic analysis (the race detector) to help find
such issues.

Rust has a large feature set(not as large as C++ but still quite
large). These features can be helpful but they can also be a burden.
Go intentionally avoids a lot of features allowing you (and your whole
team) to keep the language in your head.
The lack of features can be a pain at times, but it's also quite a relief.

For me, I learned Go in a day. My attempts at Rust have been hampered
by difficulty understanding various features and annotations. Most
specifically the lifetime and borrowing annotations.
I imagine others will struggle too.

[Hesam Rabeti]

Go is not made to solve everyone's problems. It is a very opinionated language. It doesn't even let you format your code the way you want. Just like how there are tons of people still using C, there will be tons of people that use Rust. Those who use Go use it for a reason. I mainly use it because of the simplicity and clarity of code.

[Dan Midwood]

Better is always subjective.

They're targeting similar application use cases, but also targeting dissimilar styles of developers. But, to put it simple:

* Go has fans because it's a small, straight forward and extremely easy to understand language. 

* Rust has fans because it's more complex and that complexity bring greater expressiveness and power.

I think Rust will find fans from the fp programmers, and particularly from the languages with more advanced type systems, and I think Go will find fans from the more dynamically typed languages that are looking for a step up in safety.

In short: Better is subjective and both are good

p.s like other commenters have said, it's extremely flamebaitey to post x-lang vs y-lang questions, and saying things along the line of "I can see how not-your-lang is better, but how is your-lang better?" is condescending and just inviting defensive and dismissive responses.

[Qian Qiao]

On Fri Dec 12 2014 at 11:02:50 AM Theemathas Chirananhavat <theem...@gmail.com> wrote:

As rust 1.0 is almost here, I can point out quite a few things that rust is better than go. However, I don't really see how go is better than rust. As both rust and go are meant to replace C++, they would definitely become rival languages.

So, how is go better than rust?

Have you written anything substantial in both languages?

If you haven't done it in both, then there's no point asking the question, because what you think is good might never get used, and there might secret gems in one language that you'll never discover.

If you have done it in both, then draw your own conclusions. I don't think what we say is going to change your mind, especially from the way you phrase your original post.

-- Joe

[Archos]

Different languages for different applications.

Go pros:

+ Great standard library
+ Cross-compiling to other sytems and architectures
+ Static linking, so you get easy deploy with a single binary

Go con:

+ The garbage collector is useless for some types of applications of low level (audio, video).
+ The static linking wiil do that your full application is in memory. It is not a problem into a server but in desktop/mobile apps. if you install a lot of Go applications.

Rust is a language more complex than Go because it was built for systems-level applications like you might code up in C, without a significant performance hit.

Personally, I use Go to build web services, and Rust for desktop apps.

The next version of Go is ver exciting since the compiler and linker will be in Go. So you could transpiling it to Rust to have a Go compiler written in Rust, just to be integrated with Servo (browser engine in Rust being built by Mozilla and Samsung) ;)

[Taru Karttunen]

On 12.12 02:26, Archos wrote:
> Go con:
>
> + The garbage collector is useless for some types of applications of low
> level (audio, video).
> + The static linking wiil do that your full application is in memory. It is
> not a problem into a server but in desktop/mobile apps. if you install a
> lot of Go applications.

btw we are doing audio and video with Go code and are quite happy with
it.

- Taru Karttunen

[cm...@golang.org]

I think it's pretty obvious how many ways Go is better than Rust, but I'll list a few off of the top of my head:

1. "Go" is 2 letters, "Rust" is 4 letters
2. Go's mascot is a gopher, whereas Rust's mascot is a gear. Gears can't get degrees, swim, build robots, go spelunking, or pilot small aircrafts like Gophers have done in the past. Gophers are clearly more ambitious and way more adorable.
3. In Rust, a logical compilation unit is a crate, while in Go it is a package. I know it's holiday season, but I'd rather receive a petite package than a chaotic crate (unless that crate is full of adorable gophers).

On Thursday, December 11, 2014 6:02:44 PM UTC-8, Theemathas Chirananhavat wrote:

[Gustavo Niemeyer]

Rather than aggressive, I find the question as coming from someone with little experience in programming languages and in online rants related to programming languages. From that angle, it was the response which was rather aggressive.

My recommendation for the question author is to read prior rants that compare those languages, but rather than taking these rants at face value, try to observe how the people involved in the conversation represent both sides of the argument. After reading a few of those, it'll become more clear what is being valued by the proponents. This should also provide a hint about what each language will be better at.

Then, the best next step is to try writing an application on each. This will highlight where your opinion stands with regards to those language choices, and whether you can confirm what other people said, or maybe whether there are additional edges that the conversations missed but that are relevant to you.

You'll also quickly learn that people invest a lot of their time on learning to be good at specific programming languages for whatever reason, and when people challenge the value of those programming languages, they're also unintentionally challenging that choice and the non-trivial investment made. People get very defensive/aggressive in those situations.

[Ugorji Nwoke]

Agreed.

I was going to write a blog post comparing them and respond, but I might not get to it on time.

I find the response to the OP extremely unfair. We should not care so much about the text of the question, because everyone is not a native english speaker, and even native english speakers do not always construct their questions well. 

We should instead look to the spirit of the question.

His question is fundamentally: 

"It's clear to me where Rust is better than Go. It's not clear to me where Go shines. As both are targeted as C++ replacements, can you shed some light on Go's value proposition". 

That is a very fair question to someone considering which of these 2 promising languages to use. I did this exact same analysis a few months ago. Once my blog post is ready, I will share. 

But in general, Francisco's response was unfair. It was unfortunate that Dave and Andrew, leaders in the Go community, co-signed on it. 

My 2 cents, FWIW.

[atd...@gmail.com]

The question should be asked better. It was quite tactless. I see nothing wrong with Andrew's or Francisco's answers, or Dave's agreement.

(mine might have been a bit strong, but I feel it is justified)

If you need information, you should ask with discernment. Period. He is not the only non-native speaker posting here (and for what it is worth I am not a native English speaker either but I guess it doesn't count).

And I doubt the OP has little experience with programming languages given the recent thread on generics that he started. So within that context, I understand my *sigh*

If he is willing to rephrase his question and be more explicit about the features he likes from Rust, I guess people would perhaps be more inclined / happy to answer.

But it is really not even the place to discuss about it. He should really choose for himself by trying both language. I do find the question quite silly.

[Jesper Louis Andersen]

On Fri, Dec 12, 2014 at 3:02 AM, Theemathas Chirananhavat <theem...@gmail.com> wrote:

As rust 1.0 is almost here, I can point out quite a few things that rust is better than go. However, I don't really see how go is better than rust. As both rust and go are meant to replace C++, they would definitely become rival languages.

You have to be very specific when you define one language to be "better" than another. For instance, adding more features on top of a programming language does not a priori make it more expressive. Rob Pike wrote a "less-is-more" argument a couple years ago on this subject, which is worth reading:

http://commandcenter.blogspot.dk/2012/06/less-is-exponentially-more.html

Pike's central argument is that the right features, coupled in the right way, can make a language more expressive than just adding features on top of features.

Language choices are essentially deciding what should be easy and hard in a project. Often, while a choice makes some problems very easy to solve, it can make other problems extremely hard to solve. For instance, picking a language with no good built-in concurrency (as a language feature or library) makes it very hard to implement concurrent solutions to problems. My experience falls into the line of "you will always get into trouble somewhere". The reason for this is obvious: the language makes certain problems easy and the hard problems then pop out of the woodwork. The naive programmer then starts the project all over, in a new language, because it will "phase shift" the problems away. But often, then the hard problems also shifts to another subdomain. And you are back to square one.

Language differences are almost always sinisterly subtle. What makes languages feel different is hidden from the casual observer. Often, the theoretical language design is intertwined with actual implementation choices, and real world design constraints. I tend to say "you need to implement something nontrivial in a language to learn its warts", because otherwise you don't get a feel for the subtleties the language possesses.

In practice, this often removes language rivalry as well. If a languages ceases to be used for new projects, it is because a replacement arrived which really does supplant the other language in all aspects. But more often, the differences are straightened out and this means languages end up in the niches where they still excel. Java sought to supplant C++ and did so for many projects. Yet, there are still projects better written in C or C++. When Go came out, many people proclaimed the death of Erlang. But the languages are subtly different in the problem spaces they encompass, so both languages still exist and are going strong[0].

And people use the most astounding arguments for their language choices. For instance, it is sometimes touted that Rust, with its "no garbage collection"-policy is better for implementing operating system kernels. Yet, the Mirage project[1], a unikernel, uses OCaml as the main vehicle. And OCaml is garbage collected, providing a nice counter-example to that argument. Another common argument is that "no garbage collection" is a necessity for low-latency hard realtime work. Erlang would be a counterexample. So would any decent low-latency GC (Azul, Go 1.5 tentatively). If you don't believe me, you can take this web server benchmark, and check latency for the Cowboy web server written in Erlang[2]. Cowboy achieves a 3.7ms maximal latency, which beats every other implementation, many of which are no-garbage-collection solutions.

Time will tell exactly what niches different languages fit. The problem space Go was built for is one it covers quite well. I don't see it loosing any traction in that area in the near future. Quite the contrary.

[0] Erlang programs have the ability to self-heal in the event of programmer failure or minor system error. Go programs, with their large shared memory heap can't really support this kind of capability. On the other hand, Go programs execute much faster due to them being native code compiled and Erlang usually being interpreted.

[1] http://www.openmirage.org/

[2] http://www.techempower.com/benchmarks/ [round 9, latency, look for maximal latency]

--

J.

[andrewc...@gmail.com]

You can point our things that rust is better at? like what?

[Ian Lance Taylor]

On Fri, Dec 12, 2014 at 4:31 PM, <andrewc...@gmail.com> wrote:
>
> You can point our things that rust is better at? like what?

Like others on this thread, I don't think that is likely to lead to a
productive conversation.

Ian

[Theemathas Chirananhavat]

I would like to clarify and explain a few things.

First, I am sorry for the possibly aggressive wording of the question. I actually meant "I feel that rust is better than go,and I think that these two languages have similar goals. Why do you prefer go?" (Sorry again if that is still bad wording)

As for why I prefer rust over go, this blog post made by someone else http://yager.io/programming/go.html pretty much matches my thoughts. Although I disagree on the sections about type inference and unsafe code, I agree with most of the stuff there.

I was expecting my question to be controversial (aka flamewar-inducing), but I hope that it would be a constructive discussion.

For the replies that actually answered my question, they did actually make me rethink about some stuff. Thank you.

On Dec 12, 2014 9:03 AM, "Theemathas Chirananhavat" <theem...@gmail.com> wrote:

As rust 1.0 is almost here, I can point out quite a few things that rust is better than go. However, I don't really see how go is better than rust. As both rust and go are meant to replace C++, they would definitely become rival languages.

So, how is go better than rust?

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/h4qr1m1EbGQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[David Thomas]

I just want to say that I think this is a fantastic response, and one that is aimed at the audience who would most likely identify with the original question. Thanks for the interesting examples and links.

[Henrik Johansson]

Not sure. I know that Rust has looked at Go and taken ideas that they like for example removal of split stacks.

Channels and the task concept they heavily borrowed although Go was not first it surely made these more popular outside the whole traditional CSP/Actor scene.

It could be productive bit it takes some time and effort. A simple X is better than Y... Maybe not so much.  

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[andrewc...@gmail.com]

I just found it interesting that some people feel the need to defend against an unsubstantiated claim - I agree that this thread isn't conducive to much productive talk, I've made my point so I won't post further.

[Theemathas Chirananhavat]

I feel that your argument resembles the good old "dynamic vs static typing" debate.  (checked by compiler vs testing the program) However, I disagree with some of your points.

Lifetime and borrowing are meant to reduce, not increase, the manual bookkeeping. Most of the time, no bookkeeping is needed, and both the programmer and the compiler are happy. In the harder cases, which are bug-prone, the compiler would warn and the programmer just has to be explicit about the ownership management.

Personally, I find the lifetime rules less confusing than python's scope rules, but it might be just that my thought process is weird.

You might want to read this http://doc.rust-lang.org/guide-ownership.html

[Ian Lance Taylor]

On Fri, Dec 12, 2014 at 5:01 PM, Theemathas Chirananhavat
<theem...@gmail.com> wrote:
>
> First, I am sorry for the possibly aggressive wording of the question. I
> actually meant "I feel that rust is better than go,and I think that these
> two languages have similar goals. Why do you prefer go?" (Sorry again if
> that is still bad wording)

I suppose that is marginally better than your original question, but
it still seems unlikely to be productive. Language flamewars are
matters of opinion. The only people who can speak in any meaningful
way are people who have done serious programming in both languages,
and even then it's still just opinion, albeit more informed.

> As for why I prefer rust over go, this blog post made by someone else
> http://yager.io/programming/go.html pretty much matches my thoughts.
> Although I disagree on the sections about type inference and unsafe code, I
> agree with most of the stuff there.

I think that page (which I've seen before) is a fairly typical example
of why people who like lots of language features won't like Go. A
person who wants generics plus operator functions plus algebriac types
plus general type inference plus immutability plus pattern matching is
a person who wants a complex language. There are obvious benefits to
complex languages. There are also costs.

(Oddly that page seems to ignore Go's unsafe package, although that is
a very minor point.)

It's worth noting that all of the features I listed were considered
for Go. So far, all have been rejected. They weren't rejected
because we didn't know about them, but because we didn't need them.


Anyhow, I have not written any serious programs in Rust, so I can't
answer your question in a useful way. I will note that although it
may be true that Rust and Go have similar goals, it's clear that they
have very different approaches.

If you want something comparable to the page you cite, but about Rust,
it might be interesting to read
http://www.reddit.com/r/rust/comments/29ywdu/what_you_dont_love_about_rust/
It may be approximately as accurate or useful as the one about Go. I
don't know.

Ian

[Theemathas Chirananhavat]

Actually, I view rust as a procedural language plus the type system of functional languages. However, your argument made me realize one more thing in common between the two languages.

I think rust will get people from statically typed languages that want to step up in safety, just the same way as people from dynamically typed languages move to go.

On the other hand, I feel that the philosophy of go is almost the same as of the various lisp languages. The problem is, I don't understand them either.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/h4qr1m1EbGQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Theemathas Chirananhavat]

Thank you. That page you linked (which contains quite some well-informed posts and some confusing posts) made me realize that I missed quite a few (a lot?) of warts in rust. I will rethink about those problems.

[Milan P. Stanic]

On Sat, 2014-12-13 at 08:01, Theemathas Chirananhavat wrote:
[...]

> "I feel that rust is better than go,and I think that these
> two languages have similar goals. Why do you prefer go?"

Go is simple and have clean syntax. And it is designed to be practical.

I have tried both but dumped Rust mostly because horrible syntax for my
eyes (readability is really important). And not only because that.

I don't want to say that the Go doesn't have 'bad parts', but if
something is simple one can relatively easy cope with these 'bad parts'.

[branimir....@gmail.com]

Go is far simpler and easier to program. I have programmed in both go and rust, and gave up on rust so far.
Most problems I got in rust is from rules about immutability when passing data to threads.
I found rust really painful, mostly because of that. I will wait for version 1.0 and see what changed
from last time I did something in it.

[mikets...@gmail.com]

Go is orthogonal, and orthogonality in a language is on top of my list.
Go is the best think to come since sliced c++ :).

Mike.

[farsheed...@gmail.com]

Hey guys, cool down.  This is a simple question with a simple answer.

Go is not better than rust,  It's simpler and easier to learn.  Just it.

[Dave Cheney]

Farsheed, you have replied to a thread, and a contentious one at that, that has been dormant for three years. This is poor netiquette, and has potentially reopened an unproductive debate. Please do not do this in the future.

Thank you

Dave