

Having a Go - first time experience with Golang - robotmay
http://robotmay.com/post/26828873843/having-a-go

======
jgrahamc
When you write:

    
    
      cli_host := os.Getenv("STOMP_HOST")
      if cli_host != "" {
        client.Host = cli_host
      }
    

you would be more idiomatic if you use a ; like this:

    
    
      if cli_host := os.Getenv("STOMP_HOST"); cli_host != "" {
        client.Host = cli_host
      }
    

But given how repetitive your setOpts is I think I might have rewritten it
something like this:

    
    
      func getEnv(e string, d string) (r string) {
        if r = os.Getenv(e); r == "" {
          r = d
        } 
    
        return
      }
    
      func (client *Client) setOpts() {
        client.Host = getEnv("STOMP_HOST", "localhost")
        client.Port = getEnv("STOMP_PORT", "62613")
        client.User = getEnv("STOMP_USER", "")
        client.Password = getEnv("STOMP_PASSWORD", "")
        client.Uuid = getEnv("STOMP_UUID", stompngo.Uuid())
      }
    

But then I have a thing about duplication.

Have fun with Go!

~~~
robotmay
Ah ha, I'd seen that style being used in a couple of libraries but I wasn't
sure which was the more accepted standard. I'll make sure I use that format in
the future.

Update for your update:

Aye, I wouldn't normally write so repetitively but I wasn't too sure about the
best practice for things like that and I decided to just hash it out so I
could play with the data. Thanks for the tips; I'm really keen to improve
quickly with Go, as it's very enjoyable.

------
thebluesky
I was planning to use Go on a new project, but there were two blockers that
made me decide against using it: the 32bit memleak issue and lack of support
for older Linux distros.

The go guys seem very dismissive of valid concerns from developers who really
want to use Go:

e.g. Sarcasm for users who need to run on older linux kernels and distros:
<http://code.google.com/p/go/issues/detail?id=3211#c14>

e.g. Solutions for 32bit memory leak is: works for me on 64bit:
<http://www.youtube.com/watch?v=kKQLhGZVN4A>

I bought a book on Go and was planning to use it for a new project, but
decided against it after seeing the disregard for developers with valid
concerns who want to use the language.

~~~
srik
1\. The 32 bit memleak is indeed a prioirity and the Go team has made
definitive statements about dealing within coming couple weeks.

2\. Most of the team is a bit young and cheeky but they do mean business and
actually engage the public very patiently about modifications/improvements etc
in their mailing list. The dismissive attitude is usually them trying to stick
to their core goals of making go an expressive, orthognal and highly readable
language. Usually they have good enough reasons for picking a choice.

I would seriously recommend you to "not browse through" some source code but
rather "play" with it. It really does feel different. Its like the feel of a
quick dynamic language but on a more type safe static language. Its kindof fun
at the least. Not the mention their CSR inspired concurrency approach. Its
really interesting. Give it a shot, what you got to lose?

~~~
thebluesky
Thanks for the info. I would probably take another look at it if they provided
official binaries compatible with RHEL/CentOS 5. A fix or mitigation for the
32 bit memleak would be good too.

------
mseepgood
Great talk by Rob Pike: <http://www.youtube.com/watch?v=f6kdp27TYZs> "Go
Concurrency Patterns" with cute little gophers playing Chinese whispers with
megaphones

~~~
elimisteve
Creating and using 100,000 goroutines in < 1 second is freakin' sweet indeed.

------
laktek
Here's a set of posts I compiled from my experiences in learning Go -
<http://laktek.com/tag/go>

~~~
robotmay
Those look great - added to my reading list :)

------
genwin
The way I see it, Go outshines all other languages _all things considered_ ,
at least for my use case. The combination of general speed (with quick
compilation), goroutines (to relatively simply keep all processor cores
working, for even greater speed), and high-level language features & look &
feel (e.g. garbage collection) seems unbeaten. And what a comprehensive
standard library for a version 1 (blows me away!). All subjective opinion of
course!

------
cletus
I've recently decided to pick up Go myself for a little experiment I'm
running. I highly recommend the free "Learning Go" ebook [1] [2]. It's barely
over 100 pages (huge plus).

There are some things that annoy me.

1\. Reversing type and variable/parameter name is just aesthetics I guess but
it still really bothers me. Perhaps there's a reason (eg parsing speed) but
I'd still prefer:

    
    
        float32 f1
        float32 f2 = 45.4
    

over

    
    
        var f1 float32
        var f2 float32 = 45.4
    

2\. The language is in UTF-8 so you can have snowman variable names but
weirdly what gets exported from a struct or package and what doesn't is
decided by uppercase/lowercase (respectively). This is a very Euro-centric
concept.

3\. The use of braces in struct/array/slice initializers is also a little
weird.

4\. Probably the biggest lacking area--and I realize this is a deliberate
choice--is the lack of some form of generics. I realize there are good reasons
for this. If you look at Java or C#'s generics you'll see that static type
checking with generics can result in some thorny edge cases.

Still, using interface{} is rather awkward and limiting and there aren't
(truly) universal map, filter or reduce functions like you have in Python,
Ruby, etc.

5\. Still immature IDE/debugger support. I tried to set up the Go plugin on
IntelliJ (my preferred IDE) but in creating a project it would fail throwing
NPEs in the logs for reasons not quite clear to me.

In the end I'm using Sublime Text 2 + gocode + MarGo (for syntax completion)
and it's quite nice but Sublime has some things that annoy me too (eg no
"delete line" out of the box; need to add a macro). Also if you're scrolling
through an auto-complete list and scroll too far up or down the list goes away
and you're scrolling through the file.

That all being said, the things I like are a far longer list.

1\. defer for cleanup over finally blocks (far cleaner IMHO). Minor nitpick:
you do this:

    
    
        f := File.Open(...)
        defer f.Close()
    

Personally I'd prefer:

    
    
        defer f.Close
    

which is how you'd refer to functions in Python or Javascript rather than
their return value, but again I guess this is a deliberate choice.

2\. Anonymous functions;

3\. No inheritance/overloading. This may be controversial but I consider it a
plus. structs can still have methods;

4\. Returning multiple values. Python tuples are probably a more general (and
better?) solution for this but it is nice;

5\. Named return variables. Much like defer, this has the potential to really
cleanup error condition/returns in functions;

6\. The concurrency stuff (channels/goroutines/etc) looks nice but I'm still a
novice so I'll reserve judgement.

7\. Unused variables and import statements are a compiler error;

8\. gofmt official style, which will hopefully kill off style dialects.

Anyway that's my experience so far (a few days in).

EDIT: I forgot my biggest beef with Go by far: the name. Seriously, try
searching for "Go". Even "learning go" or "go tutorial" will bring results
mixed with Go, the Japanese game. "golang" helps somewhat.

Compare this with "Clojure", which is a fantastic name in that is means
something and is unambiguous in search terms.

Note to anyone naming stuff out there:

1\. Don't choose any name shorter than 4 characters;

2\. If it's an English word (or a word in any language), misspell it in some
way.

[1]: <http://miek.nl/files/go/>

[2]: <https://github.com/miekg/gobook>

~~~
asolove
See the excellent discussion of Go's declaration syntax [1] and compare with
"The Spiral Rule" for C [2].

[1] <http://golang.org/doc/articles/gos_declaration_syntax.html>

[2] <http://c-faq.com/decl/spiral.anderson.html>

~~~
mseepgood
[1] finally explains to me why so many new languages like Scala and Kotlin and
Go use the right-hand side declaration syntax. And it also automatically
aligns multiple variable identifiers in one column.

~~~
pcwalton
In Rust the choice was much simpler: we didn't want to use the lexer hack, and
we wanted to avoid arbitrary lookahead in the parser. Consider:

    
    
        let hashmap<int,str> x;
        let x;
    

After parsing the "let" we don't know whether to parse a type (which can be
arbitrarily long) or a variable name. Switching to postfix types neatly solves
the problem:

    
    
        let x: hashmap<int,str>;
        let x;

~~~
lobster_johnson
I like how Rust uses colons for the type, compared to Go's colonless syntax.
The colon works as a nice visual delimiter.

I like a lot about Rust, but one thing I vehemently dislike is how type names
are all lowercase by convention. It's unambiguous in variable declarations,
but everywhere else it reduces visual information. In most other languages, I
immediately know that "Foo" is a type and that "foo" is a variable. Even
though Rust allows for omitting the type in many places, it quickly becomes a
sea of lowercase for me.

This, plus the focus on short keywords/identifiers and C++-style syntax (::,
semicolons), makes Rust look a lot gnarlier than Go, overall.

It also seems to me that Rust still hasn't fully adopted its "object syntax"?
One aspect of Go I really like is how functions can be used as methods and you
design entire interfaces associated with a type -- the best of object-
orientation without the worst. Rust also does this, but on the whole it seems
the current standard library is not designed around this philosophy. For
example, code uses `vec::len(foo)` instead of `foo.len()`. Are you moving away
from the OO syntax, or is it simply considered a stylistic choice?

~~~
pcwalton
You'll be happy to know that these issues are being addressed:

* I agree about type capitalization. I try to capitalize my types in new Rust code, and I'm advocating switching to it generally. It is currently on the roadmap. (It's not just a stylistic thing; we can fix several issues in the grammar that way, most notably the distinction between an enum like None and a variable like x.)

* The keywords are going to stay short (although some of them are being revised to read better; e.g. "cont" -> "again", "iface" -> "trait"), but identifiers are going to lengthen in new code.

* '::' may change to '.', to make it easier on the eyes. I personally prefer '.', and am advocating the change.

* You're right that Rust hasn't fully adopted dot-notation. This is an artifact of dot-notation being introduced later in the design, and we're in the process of transitioning code from vec::len(x) to x.len(). We definitely aren't moving away from the OO syntax; in fact we're moving toward traits [1] and maximally-minimal classes as a way to unify OO, Go-like interfaces, and Haskell-like typeclasses under one simple, coherent system.

I'd prefer it if semicolons stayed, however; I think automatic semicolon
insertion is more trouble than it's worth, as it ruins people's house bracing
styles and causes confusing errors. That said, the way a trailing semicolon
changes a block's return value is very confusing, and I'm pretty sure we can
fix that issue.

[1]: [https://github.com/mozilla/rust/wiki/Proposal-for-
unifying-t...](https://github.com/mozilla/rust/wiki/Proposal-for-unifying-
traits-and-interfaces)

~~~
lobster_johnson
Wow. I'm pleasantly surprised that all of my issues are actually being
addressed -- I was thinking that I might be in the minority on these points. I
need to be paying closer attention to the mailing list.

While I love that you are making major changes, I am sure that you are aware
that the instability of the language is a problem for many people. I have been
watching from the sidelines for a good while now, but aside from testing new
builds and reading the developer blogs, I dare not start using Rust for
anything. Niko Matsakis's recent blog entry about mutability was particularly
disappointing as it seems such a basic idea should have been settled much
earlier. I can appreciate the kind of experimental, agile approach to language
design, of course; but while Rust is germinating, I have been forced to fall
back to Go. I really hope the dust settles soon so the language can stabilize
and mature.

As for the semicolons, I think a strict, well-defined rule such as the one
used by Go is sufficient. Actually, Go is a bit too rigid about semicolon
insertion for my taste. The following, for example, will not compile, despite
the fact that the ending brace is expected by the parser:

    
    
        house := &House{
          color: Green,
          floors: 3,
          patio: true
        }
    

On the other hand, Go is perfectly happy about:

    
    
        import (
          "fmt"
          "io"
        )
    

...but I have not looked into why this is a special case.

~~~
pcwalton
The instability of the language is something we've been discussing a lot, but
I think it's better to make a good language than to rush something out the
door and be living with our mistakes years down the road. That said, we are
racing to get the design finalized as quickly as possible.

These design discussions would have happened behind closed doors in most other
places; the fact that you can see all of it just shows how open our
development process is. We deliberately haven't been making much noise about
Rust because we know it's unstable. When we are ready to finalize and commit
to aspects of the language design, we'll make that clear.

Mutability is pretty hard. Consider what C++ and D had to go through with
const/immutable correctness. The design we came up with is pretty novel and
captures all of our use cases in a simple way, but it wasn't easy to arrive
at.

~~~
lobster_johnson
Absolutely, better to have a good language than something rushed.

As an aisde, I'm curious if the core design of the language itself has been/is
done online, as opposed to working closely in an office environment? In my
experience, technical design is something that greatly benefits from being
present in the same room as other people. The second you have to sit down and
actually write out paragraphs about how you're right about some issue, and
debate about it democratically with a group of people, efficiency drops
significantly. I guess my hypothesis is that a small team working in a single
location could bat out a language faster than a larger distributed team, and
that possibly Rust has taken so long partly because it is an example of the
latter.

> The design we came up with is pretty novel

Is this [1]? The roadmap makes it sound like it's up in the air ("one of the
larger unknowns") at this point.

[1]
[http://smallcultfollowing.com/babysteps/blog/2012/05/31/muta...](http://smallcultfollowing.com/babysteps/blog/2012/05/31/mutability/)

