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.

Go's lack of generics and its incapacity for functional programming are mostly unrelated.

As an example in favor of their coupling it is very hard to write generalized functions for list operations without generics (without duplicating code). It is especially hard if you want to maintain type safety and don't resort to type erasure (interface{}).

What is the connection? There are tons of functional languages (Tulip, Racket, some Lisps) that are untyped or optionally typed.

Strong types are awesome, but you don't need them for FP. Go isn't good at powerful typing or functional programming.

Maybe that was the case in the past? Now there's Shen, so now you can get a lot more type safety in Common Lisp than in Go.

My closest encounters with Lisp is writing elisp, which lacks all these amenities. Thus my comment.

(locally (declare (optimize (safety 3)))

  (defun list-int-p (list)
    (every #'integerp list))

  (deftype list-int ()
    `(satisfies list-int-p))
  
  (defun xxx (list)
    (declare (type list-int list))
    list))

It's better than nothing, but it still bombs in prod, instead of giving you a static analysis error.

The nice thing about static types being a core part of the language (ML, Haskell, C#,...) is that you have concise syntax and type inference at all the required spots. Otherwise (Clojure) you have to be pretty verbose, as if you were writing Java.

And this is one of my problems with it. Either a language is statically type safe, or it is dynamic. You can then fully embrace the mentality of those languages.

However Go is in the league of languages created to be popular with the average Joe and just like Java before it, it's neither here nor there.

A zip code is a string even though it looks like a number.

Likewise C/Java/Go "types" are tags even though they look like types. Real types are numbers that obey type algebra, which C/Java/Go have no idea exists.

The Algebra of Algebraic Data Types: https://www.youtube.com/watch?v=YScIPA8RbVE

For example, if you save the following code[1] into a file and try to load it into SBCL, it will give a compile time error:

    (ql:quickload 'defstar)
    
    (use-package 'defstar)
    
    (declaim (optimize (debug 3) (speed 0) (safety 3)))
    
    (defun* factorial ((x (integer 0 *))) ;; x is an integer from 0 up to +inf
      (if (zerop x)
          1
        (* x (factorial (1- x)))))
    
    (defun main ()
      (factorial "foo")  ;; Compile time error: "foo" conflicts with its assert type UNSIGNED-BTYE
      (factorial -1)     ;; Compile time error: -1 conflicts with its assert type UNSIGNED-BTYE
      (factorial 1.0)    ;; Compile time error: 1.0 conflicts with its assert type UNSIGNED-BTYE
      (factorial 0))     ;; Works

    $ sbcl --load compile-time-safety.lisp 
    This is SBCL 1.2.7, an implementation of ANSI Common Lisp.
    More information about SBCL is available at <http://www.sbcl.org/>.
    
    SBCL is free software, provided as is, with absolutely no warranty.
    It is mostly in the public domain; some portions are provided under
    BSD-style licenses.  See the CREDITS and COPYING files in the
    distribution for more information.
    To load "defstar":
      Load 1 ASDF system:
        defstar
    ; Loading "defstar"
    
    
    ; file: /home/rol/src/lisp/compile-time-safety.lisp
    ; in: DEFUN MAIN
    ;     (FACTORIAL "foo")
    ; 
    ; caught WARNING:
    ;   Constant "foo" conflicts with its asserted type UNSIGNED-BYTE.
    ;   See also:
    ;     The SBCL Manual, Node "Handling of Types"
    ; 
    ; compilation unit finished
    ;   caught 1 WARNING condition

The main problem with this sort of compile-time checking is that it's implementation dependent, so some Common Lisp implementation may not provide it. You can configure the defstar library that I used on this code so that it automatically adds calls to "(check-type ...)". But then you are back at doing run-time checking of types.

--

[1] - The defstar library can be found on Quicklisp or here: https://bitbucket.org/eeeickythump/defstar/

It's pretty much just a nicer way to write all of the "(declaim ...)" and "(declare ...)" needed to provide the most information to the Common Lisp type system.

HKTs are very useful for e.g. typeclasses (used for Monad, Functor, etc. definitions) but you don't need them. Strictly speaking, you don't even need types at all (even though they're great).

You're crazy if you do FP without HKT though.

> 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.

You replied:

> Which part of his review was about functional programming in particular?

I think you totally missed zuzun's point. The point was not that this review was about functional programming, the point was that this review was not about functional programming.

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 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

Agreed, that sentence was a bit unclear from me. I did mean that they're okay with losing compile time safety over other benefits.

> 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.

Aww, thanks :D

For more detailed information on the garbage collector improvements and roadmap for 1.5 and beyond, this document is the Roadmap and discusses improvements being made including a maximum of 10 ms STW out of every 50 ms. https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo...

edit: fixed incorrect link

You should use locks for thread safety though.

That being said from a Rust background I like to be able to know what's going on at the lower level and Go makes that harder, but that's not a major issue whilst programming.

[1]Or internalize the borrow checker, which is something which eventually, automatically happens to all Rust programmers AFAICT. It actually spills out into other programming languages too so you get a nice involuntary mental tool to ensure safety in C++ :)

It's often possible to avoid sharing by passing discrete data around via channels. As a general rule, if it only has one owner, it's thread safe.

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

  type Doer interface {
    Do()
  }

  type thing struct {
  }

  var _ Doer = thing{}

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.

Then make a Draw() method on the single object default to what you expect. The simple inline explanation is:

    type SingleObject struct {
        Cowboy
        Shape
    }

     Woody.Cowboy.Draw() 
     Woody.Shape.Draw()

They all are the same interface and can be passed into each other's methods, leading to a logical error.

Yes, sometimes this isn't an option when you want to satisfy the interface for two different libraries, but I've not seen this occur very often. More likely you're in control of one of the interfaces; so rename your method to be more descriptive.

This is assumed in the description of the problem. Go has no solution for it. (Java doesn't either, but this is one of the things that C# got right over Java; it's unfortunate that Go has the same issue.)

> , but I've not seen this occur very often.

Sure, it's a problem in theory. Whether it's a problem in practice is a different question. I'd be interested to see examples of this problem in the wild.

http://stackoverflow.com/questions/2598009/method-name-colli...

http://stackoverflow.com/questions/4033329/multiple-interfac...

http://stackoverflow.com/questions/11343238/java-implementin...

http://stackoverflow.com/questions/17484325/implementing-mul...

http://stackoverflow.com/questions/9863835/two-interfaces-wi...

http://stackoverflow.com/questions/19959371/calling-same-met...

http://stackoverflow.com/questions/14290902/multiple-interfa...

etc. etc. I got bored after the first page of Google results :)

> I encountered such a case where a legacy "Address" class implemented Person and Firm interfaces that had a getName() method simply returning a String from the data model. A new business requirement specified that the the Person.getName() return a String formatted as "Surname, Given names". After much discussion, the data was re-formated in the database instead. – belwood

Further down someone hit a similar issue with the getString() method in some of the Android frameworks.

Even so, this problem could still have been fixed by just renaming the method to be more descriptive because they were still designing it. The only time this would be a problem in Go is if you had two unfortunately and oddly named methods in two libraries where you can't control either.

Edit: And to take it a step further, I would say that since interfaces are Go's only resource for representing generic behavior, go developers are more mindful of the methods they add to interfaces, in both number and descriptiveness.

How else do you write a function that can take multiple types of structs, all of which have a Name field, and select that field? (Other than reflection.)

I mean, there are a bunch of Go packages that have types with a method named precisely that: https://www.google.com/search?q=golang+"getname"

> Even so, this problem could still have been fixed by just renaming the method to be more descriptive because they were still designing it. The only time this would be a problem in Go is if you had two unfortunately and oddly named methods in two libraries where you can't control either.

Like in the Android case mentioned above? The Android system frameworks required a getString() method, while the MVVM library the commenter was using required an incompatible getString() method. Neither could be changed without a lot of headache.

> How else do you write a function that can take multiple types of structs, all of which have a Name field, and select that field?

That presentation that you linked to says to use struct embedding aka composition. And if you don't want to do that then I'd say you're "probably" framing the problem wrong, but we really need a more concrete example to discuss this further otherwise we'll just be talking past each other.

You can see this through the lens of i.e. Peter Norvig writing a Sudoku solver vs. that object modeling guy, or you can look at it through the lens of "the language should capture problems as safely and completely as possible".

You can take either perspective too far.

When Pike suggests implementing generics with "go generate", I feel like he's taking it too far. Here, I think maybe we're too far the other direction.

We have at least three examples of this being an actual problem in practice that could not be worked around. Two in Java, and one in Golang itself. I don't know how you can come to the conclusion you did.

In particular, "struct composition" does not solve the problem any more than inheritance would in Java. This comes up in cases in which the structs in question have separate declarations and you don't want to force all of your method's callers to inherit from your class/embed your struct just to call your function.

- https://golang.org/pkg/database/sql/driver/#Rows -- Columns is a getter

- https://golang.org/pkg/database/sql/driver/#Stmt -- NumInput is a getter

- https://golang.org/pkg/image/#Image -- ColorModel and Bounds are getters

- https://golang.org/pkg/reflect/#Type -- Align, FieldAlign, NumMethod, Name, PkgPath, Size, Kind, Bits, ChanDir, IsVariadic, Elem, Key, Len, NumField, NumIn, NumOut are all getters

And so on.

The reflect package could, for example, have the Type-returning methods return a struct using structure embedding to handle most of those fields. But they didn't write the API that way, because it would be annoying to do so. So they used interfaces with getters instead. This isn't Java "astronaut" design—it's just how you program in a language with interfaces.

Look at the implementation of PkgPath() for example: https://golang.org/src/reflect/type.go#L446

There's only one implementation of PkgPath(), and it does nothing but address a struct field. The functions could expose uncommonType directly, but they didn't. That's because getters are a common design pattern in Go.

You correctly observe than in order to conform to a Golang interface, struct fields have to be exposed through setters and getters. But all those examples are interfaces, not structs.

The gap between your summary here and the Golang idiom is that Golang doesn't want you to make everything an interface. Generally, Golang interfaces seem to fit one of two molds:

* Interfaces that any systems programmer could predict needing ahead of time, like io.Reader and io.Writer.

* Interfaces that are born "bottom up" to allow for a very specific bit of code reuse.

Golang's standard library does not have a lot of interfaces that are conceived of as hooks for future functionality and opportunities for decoupling, which is a stark contrast from Java libraries, which do.

Does Java tend to use getters unnecessarily where fields could have sufficed? Absolutely. Go does not, and that's a great thing about the language. But I think that's irrelevant to the point at hand about explicit interface names. In none of the cases where the name collision problem was an issue would moving things to fields have helped. For Next() in Golang, it was actually a method with behavior that was causing the problem, not a simple getter. For getName() in Java, the problem was that two different libraries that needed to work abstractly with a user object needed different "views" of the same field to work properly, and there was no way to disambiguate—observe that with fields, you'd have the same problem! Likewise for the Android library. In these cases, you really want explicit interfaces.

The right objection, in my mind, is not "just use fields" but is instead "use the adapter pattern". That is, acknowledge that yes, this is a problem in practice, but when it arises you can just make a separate type wrapping your type and implement different methods on that wrapper. That is indeed a solution that works around the issue. The question from a language design POV is then whether the benefits of structural interfaces outweigh the downsides, one of which is requiring programmers to write adapters to solve name conflicts. Reasonable people can differ on that, and I think it's obvious I disagree with Rob Pike here. But presenting fields as an adequate substitute for getters is inadequate (since you really do need getters), unappealing (since getters are great, which is why Go uses them) and pretty much totally tangential to the problem.

For the record, in Juju we have hundreds of interfaces and hundreds of thousands of lines of code, and AFAIK have never had this be a problem.

For the given Next problem, you can easily make a wrapper type that simply masks the underlying Next() method with its own implementation.

    type MyType struct {}
    func (m *MyType) Next(i int) {
        // do base next stuff
    }

    type ForSql struct {
        *MyType
    }
    func (f ForSql) Next() bool {
        // do sql-next stuff
    }

    mt := &MyType{}
    doSomeSqlThing(ForSql{mt})

Compare this to the benefits of implicit interfaces (decoupled code, easy composition, using third party code as your own interface type without needing a wrapper type)... hopefully it's pretty obvious this is a large net positive.

I implemented a DB driver that had its own Next() method. Later I wanted to implement the SQL package interface. That interface contains Next() (http://golang.org/src/database/sql/sql.go?s=40568:40595#L157...).

Choices - break backwards compatibility and change the interface I control or convolute the type definitions to create a type specific to the database/sql interface.

This limitation in combination with methods only being distinguished by name, not by parameters, turns out to be very annoying -- especially as interfaces profliferate.

You can easily make a wrapper type that simply masks the underlying Next() method with its own implementation.

    type MyType struct {}
    func (m *MyType) Next(i int) {
        // do base next stuff
    }

    type ForSql struct {
        *MyType
    }
    func (f ForSql) Next() bool {
        // do sql-next stuff
    }

    mt := &MyType{}
    doSomeSqlThing(ForSql{mt})

edit: just to clarify: I don't like the idea "write more descriptive (over-verbose) method names" as solution for this problem.

And this is called the "adapter pattern" in Java. It's also very annoying to have to use it when you hit it.

https://play.golang.org/p/t0gjJHjU7y

Edit: another variation on the same idea: https://play.golang.org/p/FqSFpMKQuv

There is a paragraph in the faq (https://golang.org/doc/faq#guarantee_satisfies_interface) and one in "Effective Go" (https://golang.org/doc/effective_go.html#blank_implements), but I couldn't find much more than that.

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

Isn't this the same as the argument for Hungarian Notation? And isn't it a bit of a slippery slope? Why not add an 'i' for integers, so that no additional context is needed to know whether a variable is an integer. Etc.

There is a lot of information about a particular identifier that it would be nice to know at any given time, and in my opinion it's arbitrary to pick just one and make it a language rule. A much better solution is for to use IDEs or text editor plugins to visually show (using color, formatting, bits of UI) that information in a user-configurable and context-dependent way.

"Simonyi’s original concept for Hungarian notation was called, inside Microsoft, Apps Hungarian, because it was used in the Applications Division, to wit, Word and Excel. In Excel’s source code you see a lot of rw and col and when you see those you know that they refer to rows and columns. Yep, they’re both integers, but it never makes sense to assign between them. In Word, I'm told, you see a lot of xl and xw, where xl means “horizontal coordinates relative to the layout” and xw means “horizontal coordinates relative to the window.” Both ints. Not interchangeable. In both apps you see a lot of cb meaning “count of bytes.” Yep, it’s an int again, but you know so much more about it just by looking at the variable name. It’s a count of bytes: a buffer size. And if you see xl = cb, well, blow the Bad Code Whistle, that is obviously wrong code, because even though xl and cb are both integers, it’s completely crazy to set a horizontal offset in pixels to a count of bytes."

It's actually a practice I now use myself in certain contexts.

[0] http://www.joelonsoftware.com/articles/Wrong.html

[0]: https://blog.mozilla.org/research/2014/06/23/static-checking...

    type Kelvin int
    type Celcius int

    func SetReactorTemp(temp Celcius) {}

    func GetOperatingTemp() Kelvin {}
 
    temp := GetOperatingTemp()
    SetReactorTemp(temp) // compile error

As soon as you open the types basket you have quite a lot of overhead that you didn't have before (it's a tradeoff, as ever). Not only that, but types won't help you on the readability front - not without an IDE. Spolskey's argument is that a naming convention can make the code look obviously wrong, and there's nothing wrong with that.

Hungarian notation has its place. I've used it before, and I'll do it again. Used correctly it can make the code safer and clearer. Types give you that too, but a naming convention is as simple as it gets, and it's free!

I also disagree about overhead. Defining new types is an O(1) cost, and decent modern languages should have type inference so that there isn't a recurring annotation cost either. Even accounting for the cost, if the benefit is 10 units and the cost is 1 unit, saying only that “it's a tradeoff” is a bit absurd. When there are tradeoffs, engineers don't throw up their hands and flip a coin, they calculate the costs and benefits and use the best solution. Types easily win in that calculation.

I don't disagree with using notation to fill the gaps when you must work in a weaker language, but we shouldn't pretend that it isn't a weakness.

I stand by my assertion that there are situations where a little notation is a good thing.

A better argument for notation is the readability of the code (which I place a high value on). That's a place where the types don't help as much, but the notation does.

Being able to declare that a variable is in radians, for example. (Bonus points if it can auto-convert.)

    type Radians float
    type Degrees float

    func (r Radians) ToDegrees() Degrees {
        // maths here
    }

I meant as in quite literally being able to use something of type Radians in something that expects Degrees and it "just works", and vice versa.

I dislike Go's overuse of "explicit being better than implicit", and this is no exception. It's supposedly to prevent bugs, but it adds so much more verbosity that half the time you're adding more bugs by the additional verbosity than you're fixing via the reduction of magic.

    typedef rad_f float;
    typedef degree_f float;

The closest thing I've found to what I mean is C#'s implicit cast system:

http://nathan.ca/2014/02/type-rich-programming/

In Hungarian Notation, the type is enforced by a declaration, but it's documented by the prefix.

In go, the enforcement and documentation are one and the same.

>> bool iMyInt;

It's obviously wrong, but the compiler will happily compile it. When you declare the following in go:

>> type NotExported struct {}

You still know it's exported, no matter what BS the programmer writes.

> 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.

I wish I'd known this a week ago, but I'll keep it in mind for the next time I'm poking at Go :)

and it works well with vim-go integration on vim for example

https://github.com/DisposaBoy/GoSublime/pull/569

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.

<3 Go's race detector (also the deadlock debugging support). Used it quite often though I didn't hit it much.

Agreed, none of this is a problem with Rust :)

Wait, does it mean that go makes your code running in more threads without you knowing? When can that happen? Sounds scary if true.

I don't remember the precise details anymore, but my recollection is I was spawning a child process and passing Writers to use for stdout and stderr (looking at os.exec, I don't immediately see anything that matches my recollection, so I'm wondering if maybe I was using a different package). I expected that it would internally do something like select over stdout and stderr in one goroutine, therefore making it safe for me to pass the same buffer object for both (because I wanted to combine writes). But instead it was spawning 2 goroutines, not 1. And there was no evidence in the API that what I was doing was wrong, the only way to know was for the data race detector to flag it.

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 ;)

But yes. It was written with Rust intuition, and whilst I ried to learn the Go way of doing things, I obviously didn't pick up everything :P

Thanks though; I'll try to use this pattern in the future!

I love how "opinionated" and slim Go's design is. The less variation in code, the better, in my opinion. It might not be as "fun", but frankly I have a lot more fun programming when I don't have to deal with esoteric solutions to problems.

Generally using multiple channels and select is good when you have multiple threads sending. When there is a single sender, putting everything in one channel feels better to me.

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

  var x int
  _ = x  
  

It was an interesting experiment to make these things errors only, but it's clear that it has failed.

The problem is the S/N of warnings. Our programmer removed a warning so that real warnings wouldn't drown in a see of false warnings.

The question is then, can we have our cake and eat it too? We don't want to completely forget about low risk warnings, we just almost completely. Maybe we could have some kind of exponential backoff when you ignore warnings?

1. Synchronous by default 2. Interfaces

Point 1 to me feels silly to admit. But man, i still do a fair bit of JavaScript/Node for work (our frontend, mainly) and it is just so.. tiresome to me, to constantly feel on the edge of bugs because some functions are expected to be synchronous (return values) and others are intended to callback.

I'm not even talking "nested-hell", i'm simply referring to the mental overhead that i apparently use when using any JavaScript function. It's not difficult.. it's just not enjoyable. It's.. tiresome for me.

Point 2 is simply because i really like interfaces. Back from my Python days, a few libraries had invented ways to support interfaces and i really really liked them, but not the overhead they required. Being able to expect the behavior of an object with certainty is the main part of duck-typing to me, and seeing that from a more static language (when compared to python/js) is really enjoyable.

I know you didn't ask for a writeup, i just had to agree with you and felt the need to share my experience from a similar standpoint. :)

One approach I've been playing with in JavaScript-land is using Promises for all return values, this means that you consistently know how to interact with a return value, whether its concrete-value is available immediately or at a later time -- this doesn't really solve the problem of consuming other people's libraries however!

They seem rather harmless to me, so i'm curious on your perspective. I see them as no more dangerous than an explicit type (or any function, for that matter).

You're asking for a specific behavior, and you know that what you get will have that specific behavior. A Reader or Writer is a simple example of that. Sure, you don't know what it's writing to, but that's outside your scope and likely the scope of the function - right?

Perhaps i misunderstand you, i'd love further explanation/examples _(pertaining to Go's interfaces)_ :)

How am I supposed to switch between types being able to do either of these, without listing all types that might occur – as this might not be possible

(I’m thinking about Haskell’s type classes as a solution to this, btw)

Basically, you don't do that in Go. Go has interfaces, but they're implemented implicitly. So rather than "I get an object", you say, "I get an object that implements interface X", and you use whatever methods X has.

That just means its up to you to name interfaces in a reasonable way. Which is one down side - if you have an "Add" method, it's back to your question about what it means to add, depending on the implementation.

Nothing does this as well as Haskell as far as I can tell.

So in your example, you might have an Adder interface that simply checks for the Add() method, but if you know you're going to need VectorAddition, Addition, and Appendable, make a new interface that implements all three, then use that.

You can do this in one large interface, or 3 small interfaces that you use to compose a 4th, larger interface (usually the preferred way). Example:

    type Adder interface {
      Add()
    }

    type VectorAdder interface {
      VectorAdd()
    }

    type Appender interface {
      Append()
    }

    type VectAddAppendable interface {
      Adder
      VectorAdder
      Appender
    }

A good example of this is in Golang's stdlib IO package. There's Reader, Writer, and ReadWriter. ReadWriter simply requires both the Reader and Writer interfaces. It's a very common paradigm.

Does that solve your issue?

Pretty much why i never got into node development.

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

http://npf.io/2014/05/intro-to-go-interfaces/#toc_4

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!

For example, if your class is named FooBar and you are declaring a FooBar variable by typing foobar, Visual Studio will just auto-fixit as you type. Same goes for properly formatting if statements, declaring functions required by interfaces, etc... In comparison, Xcode requires you to "confirm" the autocompletion fix by hitting enter, which is less ergonomic in my opinion.

When I started writing python on my own, I dislike some of the PEP8, I liked two spaces, not 4, etc... But then as soon as I started working with teams, my personal preferences no longer mattered, sticking to PEP8 make made life way easier.

I think eventually we'll just store the AST in our version control systems, and use interfaces that we will adjust to our preferences when editing, diff'ing etc...

  type MyEnum int

  const (
        A MyEnum = iota
        B
        C
        D
  )

https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html...

(rust enums can have associated data too, but its not their main usage in idiomatic code)

That said I wonder why they named it enum.

Because it's a type-safe enumeration? ADTs are pretty much a superset of C-style enums, an ADT with all-dataless constructors is equivalent to a C enum:

    enum Foo { Bar, Baz, Qux, Quux }

    > println!("{}", Foo::Qux as u8);
    2

    > enum Foo { Bar = 5, Baz, Qux, Quux }
    > println!("{}", Foo::Qux as u8);
    7    

[0] even more so C++ developers as they have `enum class` which is also type-safe and not implicitly converted to integrals

OTOH I haven't written a line of Rust of yet, so enum might be more familiar in use.

The issue with `union` is it might hint at things which are not available (e.g. the union of an int and a float where you can access to the raw data as either).

A Rust enum is really an encoding of the `struct { enum, union }` pattern, but it degenerates to an enum if there's no union part (no data payload), not to a union. So calling it an enum makes more sense.

    type Shape struct {
            Rectangle *Rectangle
            Circle *Circle
            Triangle *Triangle 
    }

    func NewRectangleShape(r *Rectangle) *Shape {
        return &Shape{rectangle: r}
    }

"A circle, triangle, or rectangle" is not the same data structure as "Something that can be drawn". Certainly if you have a function that draws something given a Draw() method, having the function take a "Drawable" is appropriate. But it's not the only use case; sometimes you really mean "A circle, triangle, or rectangle" and in that case, a struct is absolutely what you want.

However, I was writing a rather tiny library so it wasn't a major factor, so I didn't notice this until much later.

I did intend to add a blurb about this when posting to Polyglot Weekly, but I .. forgot ;P

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.

(I've just browsed the rust docs, never written anythign in it)

    fn do_stuff() {
      // already inside a function!
      {
        // allocate here...
        let x = Giraffe();
      }
      // should be deallocated by now. right?
    }

It would be nice to have a cheatsheet full of Go tips & tricks like gofmt/goreplace for replacing idents, and goimports-on-save, and whatnot. TBH I didn't really look for such non-in-built solutions when starting though, so I would have missed it anyway :P

I can't fault new users for this; the non-discoverability of these awesome tools for new users is a genuine fault of the Go ecosystem.

Just a "Tips" or "Useful Tools" list at the end of the Getting Started page or the How to Write Go Code page would be better. Just to make users aware that such tools exist.

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.

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.

As far as we're concerned, the most compelling reason for Servo to exist is performance, especially in layout and rendering. Many of the wins of Servo layout have come from carefully coding to the optimizer to allow it to eliminate virtual dispatch and procedure call overhead, break apart structures, stack-allocate where possible, and (in the future) use SIMD. As a result, the performance profile of most of Servo layout tends toward flat loops as opposed to deeply nested stacks of virtual call upon virtual call—much friendlier to the branch predictor, i-cache, and intraprocedural optimizations. At the same time, we get a lot of responsiveness wins from having a threaded design where pauses in one thread—most importantly, JS and the DOM—do not impact responsiveness in the other threads, which becomes very important when CSS animations are involved, especially common ones that require reflows.

Now with Go, we'd have the choice between a compiler that basically doesn't do any optimizations beyond very simple ones (6g/8g) and a compiler that lacks good GC integration (gccgo). The former would negate all of the advantages of our careful coding to the optimizer and would probably make Servo layout, in parallel mode, slower than the sequential layout of other browsers. (Despite what djb says, compiler optimizations really matter!) And the latter would cause the stop-the-world GC times to spike, jeopardizing our smooth animations, which arguably matters even more than raw reflow performance to the user experience. (That's not even counting the fact that since Go's malloc is reportedly extremely slow compared to that of Java, it relies heavily on escape analysis, which gccgo doesn't do…)

There are other reasons too, such as the fact that integrating a good JS garbage collector and Go's garbage collector would basically be impossible without rewriting one of them and making major sacrifices along the way (like making JS GC multithreaded or making Go's GC conservative, like Blink did with Oilpan). But performance is the main reason.

Yes, but if that were the only concern, you wouldn't need Rust to do it. C++ already exists, and it can do all those things. (Well, the "break apart structures" may be a bit unclean depending on exactly what you mean, but that alone wouldn't be worth writing a new language for.) My interpretation of C++'s raison d'etre in modern times is "zero-cost for abstractions you don't use", whatever its heritage may have been in the past. If that were the whole story, you just would have started a new C++ renderer from scratch.

You need Rust because actually writing that code in C++ would be unmanageably complicated due to the ownership problems that Rust addresses. C++ is already unmanageably complicated (IMHO) when trying to write a browser engine, also requiring that level of performance would basically take it into the realm of the impossible.

You need the complexity management first. Managing the complexity buys you the cognitive budget to write the fast code, too. It is not as if the C++ render authors do not want to write fast code, or as if they are unaware of the recipe you just laid out.

I said I wouldn't write it in Go because it is already disqualified due to the complexity issues. Even if I didn't care about the performance gap, I still would have no desire to write a browser engine in it because it would be a nightmare, just like the C++ engines are, and for pretty much the same reasons, in addition to others. The performance gap between Rust and Go here is essentially unmeasurable, because in this task, Go won't even cross the finish line. (By my standards, at least. I consider the C++ renderers to also not cross the finish line. The fact that memory-unsafe code can be bashed into submission with sufficient man-millenia doesn't mean I have to agree that memory-unsafe programming languages are a good idea.)

More importantly, there isn't any language that focuses on _making SIMD work right_ -- even C/C++ do an awful job of this with it's tacked-on __mm_foobar functions.

Rusts idea of having SIMD live as near-primitive datatypes (f32x4 etc) follows Dart a bit and overall I think it's a good approach -- albeit very incomplete right now.

I seriously hope that emphasis will be placed into making SIMD feel like a first-class citizen in the language and not a tacked-on feature as I've seen in so many other languages.

http://sierra-lang.org/

Whether or not you can afford this very much is an upfront thing. You cannot push something like this off until later. For things like a web browser or game engine or other highly-interactive, highly-latency-sensitive, high-ram-using thing it's known far in advance that the GC will be a curse.

This is why C++ continues to be the language of choice for those sorts of systems. Control over memory is crucial for them.

> ... there is no other language I can think of with such a small surface area that I can tell students in the first week to learn and deliver an assignment by the second week

...

> 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.

I don't consider the two to be in competition (aside from "which hip new language should I learn today") either, though it's less due to the easy-to-pick-up thing and the Rust mentality that:

- If it can be a footgun, be explicit (unsafe, exhaustive matching, unwrap)

- If you can do it at compile time, DO IT DO IT DO IT DO IT (all the compiletime type safety, ownership, etc). All abstractions should be zero-cost or with minimal cost (at runtime). Try to write your code so that tests won't be necessary (because a successful compile should be a test), and then write tests anyway!

(This mentality is pretty prevalent in both the Rust stdlib/language and external libraries. The equivalent of interface types in Rust (`Box<Trait>`) is generally frowned upon and only brought out when absolutely necessary, for example)

Go doesn't really embrace either of these principles, so it doesn't compete that way. You're right, developers already are used to making those choices.

> 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.

Not necessarily. As mentioned before, the Rust way of doing things generally leads to a lot of optimized stuff. Taking the vtable example -- Go code that I've seen uses vtabley things everywhere (the stdlib is peppered with interface types). Using vtables isn't bad, but when you use it for stuff that could have been solved by static dispatch (for large codebases -- that can be everywhere), then it can become an issue. In Rust a vtable is a last-resort that people will grumble about before picking up and using (but will use it whenever absolutely needed). Sure, a single vtable isn't much of a performance optimization, but when all your APIs use static dispatch due to this mentality, the collective optimization is huuuge.

> 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.

For many applications, I agree. Systems programming is one where this doesn't apply, but for stuff like a distributed consensus algorithm implementation (which I was doing), both Go and Rust are perfect. And I'm pretty sure that if I'd had more practice in Go, I would have been confused which language to write it in. (Right now I love Rust and am not great at Go so of course I would use Rust if given a choice)

For stuff like a browser, it's not so much that there are batshit insane sharing patterns, it's more because a browser is huge and performance matters a LOT. (I think pcwalton above explains why better than I can)

As a lecturer, Python would be my other choice, nowadays, for a small surface area language.

I suspect Go has the advantage here simply because it barks at you at compile time over certain errors. Pedagogically, something that students have to run that checks the syntactic validity of their program is probably win.

I emigrated from Lisp->C->Tcl->Perl->Python over about 30 years and Python is still the thing I reach for when I have to whip up a program (yeah, Lisp was nice but I could never afford a machine with enough memory for it not to be a toy--memory was expensive at one point, you youngsters).

Go doesn't really interest me that much. It's a little better at a broad range of things, but nothing that pulls me from the existing set of languages. I'd rather use Erlang for concurrency, for example. Maybe if I had Google-sized codebases I'd care more.

Rust interests me because it is in the same range as most languages for most things but is a LOT better at a very few things.

I'm waiting to hear somebody use Rust in a video game engine. I suspect that C++ will vaporize (one can hope) once someone proves that Rust works in production.

I too am a Python fan for scripting though :)

> Rust interests me because it is in the same range as most languages for most things but is a LOT better at a very few things.

Me too, for similar reasons. It's like C++, but without all the stuff I didn't like about C++ :)

> I'm waiting to hear somebody use Rust in a video game engine.

http://github.com/PistonDevelopers/piston

I need to think about this a lot. I've got a particular project in mind (VLSI design) and the thing that has always stopped me is that the UI toolkits can't deal with concurrent actions. OpenGL and multi-threading are asking for disaster with C/C++.

Rust might let me break that logjam.

Clojure was close, but JOGL still remains a disaster.

Yes, but by definition, we're discussing optimized code here.

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Yeah yeah, benchmarks blah blah, but the point here is, compare with, oh, say, this:

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

As I said and will repeat without blinking, Rust will always be faster than Go (and the problem in the shootout Go beat Rust on is in my opinion certainly simply an unoptimized Rust implementation, no question), but language deltas of 2x or 3x in practice are dominated by algorithms and IO far more often than 50-100x. For all the long list of reasons that Rust is faster than Go, all of which are true, they add up to much less than developers are used to. Intuitively, when you hear "go is slower than Rust because vtables and bad optimization and GC and its pauses and interfaces" you probably mentally expect Go to be like 10 times slower, when instead it's 2-3.

This is relevant because I don't think Rust advocates should sell "speed!" too hard as the primary thing they have... C++ will pretty much forever be able to keep up on the raw speed front, especially in benchmarks. What it has is complexity management, at speed. But complexity management first.... Rust could probably take a straight-up 2x speed penalty over C++ and still write a renderer than ran faster than C++, because it'll be a better renderer.

Scotty! We need more CORE[s] !"

Sounds like an awesome professor! It's a pity he didn't get you to use Nim.

Kudos.

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
  }

    _ = unusedVar

    type Color int

    const (
      Red     = iota
      Blue
      Green
      Sausage
      Yellow
    )

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

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

> 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 only time in my experience that it has trouble is when there is a namespace conflict and it has to guess. Generally that's easy to avoid though, and uncommon.

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.
            }
        }
    }

    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}
    }

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

But point taken. I will try to use this pattern in the future.

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

I believe I was pretty clear in the article that I didn't know the Go way of doing things and this was about what Go looked like from a Rust point of view. This was not supposed to be a rant, just a post that sort of illustrates the differences between the languages. IMO it actually gives a clearer idea of what Rust is like than it does of Go since the "Rust way" of doing things is clear from the comparisons..

They're not: https://realworldocaml.org/v1/en/html/objects.html#ocaml-obj...

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

You've conveniently ignored the case of the non-drawing commands. Should they be Drawables with a Draw which does not draw anything?

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

The OP has been upfront about his limited knowledge of Go, and his rust knowledge coloring his thinking.

In particular, you can't implement Quit using a virtual method, unless you do something like have every function return a boolean to the caller indicating whether it wants to quit (or panic and recover, but that's too awkward for words).

You also can't have methods that set local variables in the caller, unless you do something like pass in their addresses to the function, which gets awkward quickly if you have a lot of local variables.

How would you do that using ADTs?

This is pretty related to the so-called expression problem. OO-style methods are good at extensibility, but they're bad at adding extension points (method calls), since you have to update every one and calls are limited in expressive power compared to the body of a switch statement. Functional-style ADTs are bad at extensibility (adding a new type requires updating all pattern matches), but they're good at adding new extension points, since you don't have to touch the data types and pattern matching is powerful. Supporting both styles in a language gives programmers the freedom to choose the best one for the task at hand.

That doesn't mean the article isn't interesting or useful though. It's helpful for any language community to see what a new comers first impressions are and then tailor the onramp appropriately in their documentation.

You are unneccessarily hard on the author here I think.

This assumes the structs themselves know how to draw. This is usually (not always) an antipattern, because it conflates data with behaviour.

I should be able to swap out the drawing implementation without having to change the data. For example, given a circle (cx, cy, radius) I should be able to draw it using SVG or OpenGL.

The enum way is not necessarily "unidiomatic Go". Even if you have something that turns data structs into "strategy" objects that know how to render, you need a matching statement, or you need to build something like a "map[Type]Drawer", which is in my opinion less elegant.

This allows developers to quickly say "I know Go. Here's what's wrong with Go." since they believe they have learned all there is to know about it. This is good, since that's part of why Go is approachable.

However, this has downsides. As you showed, there are succinct features that can make the difference between "this is a bad thing" and elegant code.

OK, it seems I'm trying hard to defend Go. I like it, I seldom (but do) miss generics, I miss some Haskell/Rust features and wish it were a little less simple. But I don't understand why there are dozens of similar "things about Go" articles posted every week on HN, all repeating the same stuff.

The one from Evan Miller was both entertaining and in-depth, but that's the exception.

Our comments are ultimately feedback. We're a community and we want constructive feedback to help each other learn. When giving feedback, just remember to be constructive and consider how your tone could be perceived. I'm sure that you had the best intentions but the undertone of the comment read to me (and many others) as very cutting/attacking.