A Rust Contributor Tries Their Hand at Go

I really enjoyed this review. You can tell the author spent some time trying to spot the good and bad things about Go. Too many Go reviews turn out to be: Watch me trying to use Go as a functional programming language and fail miserably because it lacks generics.

Anyway, just like the author I found myself fighting the forced directory structure at first, but it's something I started to like about Go: Go doesn't come with a complicated package management. All packages lie in a directory and you can edit everything with normal shell commands. This keeps things refreshingly simple.

There is one minor syntactical convenience available to make the message example slightly more concise: switch msg := msg.(type) would make msg a message of the specific type inside each case. (So msg would be a DrawLine between 'case DrawLine:' and the next case.) Author might have just wanted different names in the different cases, which is a perfectly defensible reason for doing it the way he did instead.

He says "Go seems to advocate runtime over compile time checking." I think it's less that folks prefer run-time checks on principle than that they simply don't yet have in hand great ways to strengthen compile-time safety while meeting their other goals (meeting backcompat promises, not complicating spec/impl too much, other work like shorter GC pauses or new platform support). As an example of a team member not being a fan of all the runtime checks, bradfitz complains about the occasional gross interface{} here: http://talks.golang.org/2014/gocon-tokyo.slide#50 . And there is active work from the team and community on static checking, though most of that right now is in the form of heuristic checks in external tools, e.g., go vet and errcheck.

All in I love this--I tire a bit of posts that are like "I wrote a toy program [or not even that]; here's Why Everyone Else Is Wrong" (because anyone could give an opinion that informed given a day or two, and hot takes are getting old). But it's cool to see someone who, by virtue of working on Rust (and seeing it evolve) has unusual perspective on tradeoffs and seems to have written, you know, pretty thoughtfully and maturely about them.

I've written a fair amount of Go and his view is pretty consistent with my experience. Go has a good culture of doing things the simplest correct way and only that way. Rust is really interesting because of the stronger compile-time assurances and lighter footprint (looks like it'll be a good candidate for embedding into mobile apps), I'm learning it in the hopes that I'll be able to use it as an alternative to C for portable library code.

> Having interfaces be autoimplemented [...] it's just not what I'm used to and it restricts me from writing certain types of code without using dummy methods like so to get static type safety.

There's a Go idiom for that. If you have

  type Doer interface {
    Do()
  }

and a

  type thing struct {
  }

and you want to make sure that `thing`s implement `Doer`, just add this line:

  var _ Doer = thing{}

_ is a special value that can be redefined at will, so the pattern can be used as many times as needed. From there, the meaning should be straightforward: _ is a `thing` that implements `Doer`, so the compiler will check it. You get to keep implicit interfaces, that you can make explicit as you need.

Apart from that, this post is really great; as someone "used" to Go and not at all to Rust this kind of impressions is always enlightening.

> Visibility (public/private) is done via the capitalization of the field, method, or type name. This sort of restriction doesn't hinder usability, but it's quite annoying.

While the capitalization of identifiers may be surprising, in practice it is one of the best features of go in my experience because no additional context is needed to know whether an identifier is exported. In rust, as far as I can tell, it is not possible without referring to the declaration.

As far as globally changing whether an identifier is exported, it is easy with the gorename tool, no search and replace necessary. Gorename also updates any references to the identifier in other packages in $GOPATH. https://godoc.org/golang.org/x/tools/cmd/gorename

pretty even-handed.

> The other day I had to make a bunch of fields public to satisfy Go's encoding package, and code needed to be updated everywhere with a manual find/replace (the same string was used in other contexts too so it couldn't be done automatically)

gofmt has syntax-level replacements. So you could do:

`gofmt -w -r 'unexportedName -> ExportedName' *.go`

or something similar, and it would do the correct thing, ignoring the string matches where it appears in other contexts.

> Despite the performance costs, having a GC at your disposal after using Rust for very long is quite liberating. For a while my internalized borrow checker would throw red flags on me tossing around data indiscriminately, but I learned to ignore it as far as Go code goes. I was able to quickly share state via pointers without worrying about safety, which was quite useful.

I haven't gotten very far into the article yet, but this paragraph sent up a huge red flag for me. GC does not make the code safe. All it does is ensure that values don't get destroyed while they're still referenced. But you still run the risk of data races. If you're writing single-threaded code then this is fine (because single-threaded code doesn't have data-races), but the program being written here is a concurrent program.

Obviously you can write safe programs in this fashion. But you still have to think about safety. The difference is the compiler doesn't verify safety for you, which means you can write code fast without worrying about the compiler yelling at you, but your program may have race conditions in it.

Anecdotally, a few years ago when I was active with Go, a program of mine would segfault about once a month. It was a command-line utility that I ran maybe a few times a day. The segfault was so sporadic that I could never figure out what was going on. Then Go 1.1 introduced the data race detector. Using that, I was able to discover that the Go runtime was actually spinning up two goroutines when I thought it was only using one (servicing the stdout and stderr of a child process), and the one buffer object I was writing to turned out to be written to from two separate threads. This usually worked, but on that rare occasion it would lose the race and overrun the buffer. This is a bug that plagued me for half a year, and I'm really glad that the Go team created that data race detector because I never would have figured out what was going on without it. But it's a bug that simply cannot happen with Rust.

Not bad, at least a fair look!

One thing that immediately set off my radar (as a Go programmer) is the paintingLoop switch on type.

Yes, sometimes a switch on type is necessary. However, this is not one of those cases.

You want to have a Triangle and Line with a Draw() method and a "Drawable" interface... and then just call into it. The signature of the loop in question then is paintingLoop(ch chan Drawable).

An abuse of naming, but a Quit.Draw() could actually quit, for example. This is just offhand though.

In short, good article, but the Go examples are written with a Rust intuition. Which, I mean, fair enough; I started writing Go with a C++ intuition, with different questionable practices ;)

The unused imports thing seems to be a common complaint, however I just use go-imports, and imports are added/removed automatically when I save the file.

I never ever have to even touch imports, except sometimes when two different packages have the same name.

Note: this was originally posted at http://inpursuitoflaziness.blogspot.in/2015/02/thoughts-of-r... , however I thought it would be nice to go through the Polyglot Weekly editorial process and come up with a better version of it :)

Having next to no Go experience, and zero Rust experience, I found this article a really fun read. Coming from a Node.js background, it was neat to see the concurrency approaches used in both languages compared -- quite different from a single-event-loop :)

My biggest problem with Go is this one [1]

In short, assign nil to a variable, and it ends up not being equal to nil (?!?) Really, how does something like this get approved?

[1] https://golang.org/doc/faq#nil_error

> Eventually I was able to learn the proper style by watching my code get corrected.

Funny thing: I actually benefit from not typing idiomatically! GoSublime runs gofmt whenever you save a file. It's a free check for syntax errors, as it won't fix the formatting if you made a mistake. And because the mistake must be in the non-idiomatic formatting, it's easier to spot too.

> I'd love to see a rustfmt, however!

Seriously, I miss gofmt in any language that doesn't have a similar feature. I'm so surprised it hasn't been copied more!

Interesting point of view to hear. RE: enums - There is an idiomatic way to do enums in go I believe:

  type MyEnum int

  const (
        A MyEnum = iota
        B
        C
        D
  )

What about compilation speed of Go/Rust? Surprisingly there wasn't mention about this in article. I consider slow compilation as a main issue of Rust compared to Go. Am I right?

Having written in both Rust and Go, I found that a very good article.

The big new idea in Rust, of course, is the ownership model and its compile time borrow checker. That's worked out surprisingly well. I expect to see that idea appear in future languages. One could have a Go-like or Python-like language with a borrow checker. It's not inherently tied to Rust.

As a practical matter, programming in Rust is more likely to hit problems with type checking than borrow checking. Ownership problems are usually with your own code. Type problems often involve code written by others, and changes to other modules often induce type errors. Because Rust has type inference, and because it's often not obvious what the type inference engine is doing, Rust can have rather abstruse type problems. Go is rather straightforward in that area.

Go lacks generics and templates. This simplifies the language, but the lack of generics then has to be worked around. Go has too much use of "interface{}". Bolt-on compiler passes such as "go generate" and the protocol buffer compiler have been added. Both are used mostly to get around the lack of generics. Rust has very powerful generics and templates, so powerful that they tend to be over-used. Everything seems to need a generic. Rust is starting at the cruft level it took C++ 20 years to reach. This may or may not work out in practice. It may be necessary to restrain Rust template enthusiasts from getting carried away.

Error handling in both languages is via return values. Go is straightforward, with multiple return values being the normal approach. The Rust mechanism, involving Result<> and Some<> types, is rather clever, but results in wordy code to do simple things. Too much Rust code goes into putting things into Result and Some objects, then analyzing and dismantling those objects. It's not clear that leaving exceptions out of Rust is a win. Negative experience with C++ exceptions may have motivated that design decision.

Rust has Resource Allocation Is Initialization (RAII). Go does not. For both languages, problems come up with resource release. Go has "defer()", which is kind of clunky and can't be encapsulated, while Rust has destructors called when something is deallocated. In both cases, it's hard to handle an error at resource release time. Destructors that do anything non-trivial are usually troublesome. Both languages have this problem. Languages with "with" (Common LISP's "(with-open-file ... ...)" and Python's "with FILEOBJ as HANDLE : " have fewer headaches with resource release errors, since they occur in ordinary code, not at some special destructor time.

goimports-on-save is an essential tool in your writing environment for go. It's not mentioned in the official docs, but using it completely obviates fiddling with your import declarations ever again. While you're at it, you might as well turn go vet-on-save and go lint-on-save as well.

"Unlike Rust, Go is really easy to pick up. It's possible to jump directly into it, and you can be writing useful programs after a single afternoon of messing around or reading."

I think it's safely implied that you put more effort into Rust code, but get more out of it. It's a tradeoff from Go. It's worth it for some programs, and others it's not.

Go for me doesn't work out because it's not C ABI compliant which is a limitation Rust doesn't have. As a language nothing draws me to it in particular. The killer feature is how easy it is to get started with it. Something that is undersold.

Coming primarily from Python I'm still favoring the field over Go until my problems matched Google's. I would probably reach for Erlang for concurrency and Rust for anything low-level going forward.

The most important thing I took away was that Rust has enums as tagged union types; I cannot count the number of times I wished I had this in my day-to-day language.

"Unlike Rust, Go is really easy to pick up. It's possible to jump directly into it, and you can be writing useful programs after a single afternoon of messing around or reading. On the other hand, while basic Rust is easy to pick up, it takes a while to get used to the borrow checker (and in general understand ownership/borrowing). Additionally, most libraries make full use of advanced features (like associated types) and one needs to learn these too to be able to use the libraries."

This is pretty much why I consider these two to be in less competition than first meets the eye. Rust intrinsically involves putting more effort in to the code. You put more effort in and you get much more out, but there's a lot of code for which that's not the right tradeoff, just as there's a lot of code for which it is.

"In Go there's no obvious way to get this. The closest thing is the type called interface {} which is similar to Box<Any> in Rust or Object in Java.... Of course, I could implement a custom interface MyMessage on the various types, but this will behave exactly like interface{} (implemented on all types) unless I add a dummy method to it, which seems hackish."

I think most Go programmers stick to interface{}, but personally I put the tag method on the type, being from the Haskell side of the house on that front. In practice it turns out that often the "tag" interface grows a useful method of some sort, at which point it ceases to feel silly. If nothing else, you've got the ".Handle()" option. See also http://www.jerf.org/iri/post/2917 .

Also, just generally on the performance front... developers who care about performance are at this point subconsciously pretty used to being able to choose between "language like Rust or C++ that really, really cares about performance, but is hard to use" and "dynamicly-typed language that's really flexible and powerful but 50-100 times slower than the other choice". In the limit, Rust will absolutely be faster than Go, no question, but the performance penalty may be more like a factor of 2 in the end... Go's pretty fast, and while you can't go absolutely crazy with optimization C-style, you do get to play with locality optimizations with real structs and real arrays and such. Worrying about the performance differences between C and Python before you write a line of code may be perfectly valid, because the gulf is pretty large... worrying about Go vs. Rust is going to be a much narrower band of validity before you're just prematurely optimizing. Rather a lot of high performance code still has "vtables" in it, used quite extensively.

In practice, I don't expect many people to decide between Go and Rust based on performance needs on similar code... non-zero, yes, but not many. What expect people to choose between them are general software engineering complexity considerations. When it comes down to it, the reason to write Servo in Rust and why Rust needed to be created to do it isn't that there weren't languages that were "fast enough"... it's that the browser has bat-shit insane sharing patterns, complexity beyond the mind of any mere mortal, and you end up with code that either does way too much copying or crashes when it doesn't do enough, because there's no ownership management in the language. That's the sort of reason to choose Rust over Go. If you're making something that looks like a browser, or an office suite, or a big highly-integrated business workflow suite, or something like that, I'd choose Rust over Go in a heartbeat simply because Rust is designed to shine in that environment, and Go ultimately doesn't particularly offer anything to make that scale of that sort of code any better than any other statically-typed language.

My hat is off to the author of this piece; what a beautifully written fair evaluation of two technologies.

Kudos.

Here's part of why the interface thing is useful: it gives you dependency injection almost for free, and it allows modules to be extremely decoupled. You can create a module-local interface describing not just a "generic X" but "specifically what methods of X I want". That way you don't even depend on other object's types, but only on their permitted actions. And making mocks is very easy. The IO libraries use this extensively; they don't depend on where you're getting your IO from. They just require it does this or that.

Bonus, you can define "tolerable minimum" and "nice to have" versions of the same local interface. Define your methods in terms of the first, but attempt to cast to the second.

  if nice, ok := minimal.(Nice); ok {
    // do stuff only possible with the nice to have interface
  }

Example: the HTTP libraries will flush your IO if you give them something flushable, but they don't require it.

It seems he approached this in good faith and gave an honest review. Which seems quite rare for people commenting on Go.

I might be mistaken, but `func bar(){}` is not public, I think you meant to capitalise the "B".

My biggest gripe with Go: Unused variables. Unused anything doesn't let me go on with coding. It's obviously a design decision from the makers of Go, but the way I usually program is "experiment first, then clean up".

Regarding enum support, you can create type safe enums in Go like this:

    type Color int

    const (
      Red     = iota
      Blue
      Green
      Sausage
      Yellow
    )

The `Color` type is not compatible with int, so except for explicit casts and literal assignments, it's type safe.

Though that's quite a different enum style compared to the tagged unions of Rust, his approximation with interfaces is indeed closer to that.

Looks like an error in the Go code in the What I didn't like/No enums section. In the paintingLoop function the type assertion switch should be on the message and not the channel.

Should be "switch msg.(type)" instead of "switch ch.(type)"

Re: Go errors for unused imports

> This rules out some workflows where I partially finish the code and check if it compiles.

Sounds like a great job for an IDE to automatically add/remove the appropriate imports for standard library stuff.

The problem with Go is that you don't grok Go interfaces.

EDIT: downvoters, please explain what's wrong with my comment.

Go interfaces are quite a novel concept, and most developers that jump from language X to Go don't have enough time and experience to understand how they work, and how to design their application around this new model.

Their example of the messaging system/UI application is a straight port of the Rust code, and they lament the fact they have to use interface{} to overcome the lack of object orientation or pattern matching.

    func paintingLoop(ch chan interface{}) {
        // shorthand for a loop over receiving over
        // a channel
        for msg := range ch {
            switch ch.(type) {
                case Quit:
                    // quit
                case DrawLine:
                    // cast to a drawline message
                    line := msg.(DrawLine)
                    // draw `line`
                case DrawTriangle:
                    tri := msg.(DrawTriangle)
                    // ...
                case SetBackground:
                    bg := msg.(SetBackground)
                    // ...
                default:
                    // Need a default case in case
                    // some other type is fed through here.
            }
        }
    }

This is not idiomatic Go. The author here should be leveraging Go interfaces and they wouldn't lose type safety.

    type Drawable interface {
        Draw()
    }

    type Line struct {
        x1, x2, y1, y2 int
    }
    func (l *Line) Draw() { ... }

    type Circle struct {
        cx, cy, radius int
    }
    func (c *Circle) Draw() { ... }

    func paintingLoop(ch chan Drawable) {
        for object := range ch {
            object.Draw()
        }
    }

    func main() {
        ch := make(chan Drawable)
        go paintingLoop(ch)

        ch <- &Line{x1: 10, y1: 10, x2: 50, y2: 50}
        ch <- &Circle{cx: 10, cy: 10, radius: 20}
    }

You wouldn't expect Python programmers to try Haskell over a weekend and have enough experience with it to write a blog post about "Thinks I dislike about Haskell", but it seems much to often people play with Go and, when they fail to translate their ideas to this new language, post yet another "rant" on HN about how Go sucks.

Go has its fair share of shortcomings, but try to _learn_ the language before writing yet another misinformed article.