8 ms·

Having a Go - first time experience with Golang

53 points by robotmay 14y ago

jgrahamc 14y ago
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 14y ago
  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.
- james4k 14y ago
  I've always had a bit of an issue with these if statements. It might be slightly more concise, but your code also isn't as straightforward to read. In fact, it's really only more concise in its use of vertical space, so for clarity's sake I'm not sure I see the point.
cletus 14y ago
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/ http://miek.nl/files/go/ [2]: https://github.com/miekg/gobook https://github.com/miekg/gobook
- jesstaa 14y ago
  1. Reversing type and variable/parameter name is just aesthetics I guess but it still really bothers me. Perhaps there's a reason. The reason is that it is much easier to read for more complex types. eg. function pointer in C: int (*pt2Function)(float, char, char); function pointer in Go: var pt2Function func(float32,byte,byte) int Try writing a type that is a pointer to a function that returns a function in C. It's a bit mind bending.
- robotmay 14y ago
  I've had that ebook for a while but hadn't read it yet; I'll put some time into it this week I think. Just on the editor front; I've had quite a pleasant time writing Go in vim, but I guess that depends on whether you would class using vim a pleasant time :D
- asolove 14y ago
  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 http://golang.org/doc/articles/gos_declaration_syntax.html [2] http://c-faq.com/decl/spiral.anderson.html http://c-faq.com/decl/spiral.anderson.html
  - mseepgood 14y ago
    [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 14y ago
      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;
thebluesky 14y ago
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 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 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 14y ago
  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 14y ago
    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.
- genwin 14y ago
  Do you know if the memory leak still exists on 64-bit? I wasn't able to determine that. I've read that the solution is to use 64-bit, but I don't know if that really just means that a 64-bit system will take the memory leak far longer to crash it. I'm not too concerned about the attitude of some Golang devs (they are volunteers, after all), but I am very concerned about any memory leak or other serious bug that won't be fixed for a year+.
mseepgood 14y ago
Great talk by Rob Pike: http://www.youtube.com/watch?v=f6kdp27TYZs http://www.youtube.com/watch?v=f6kdp27TYZs "Go Concurrency Patterns" with cute little gophers playing Chinese whispers with megaphones
- elimisteve 14y ago
  Creating and using 100,000 goroutines in < 1 second is freakin' sweet indeed.
laktek 14y ago
Here's a set of posts I compiled from my experiences in learning Go - http://laktek.com/tag/go http://laktek.com/tag/go
- robotmay 14y ago
  Those look great - added to my reading list :)
deleted 14y ago
[deleted]
genwin 14y ago
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!

53 points by robotmay 14y ago

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 14y ago
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.
james4k 14y ago
I've always had a bit of an issue with these if statements. It might be slightly more concise, but your code also isn't as straightforward to read. In fact, it's really only more concise in its use of vertical space, so for clarity's sake I'm not sure I see the point.

cletus 14y ago

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/ http://miek.nl/files/go/ [2]: https://github.com/miekg/gobook https://github.com/miekg/gobook

jesstaa 14y ago
1. Reversing type and variable/parameter name is just aesthetics I guess but it still really bothers me. Perhaps there's a reason. The reason is that it is much easier to read for more complex types. eg. function pointer in C: int (*pt2Function)(float, char, char); function pointer in Go: var pt2Function func(float32,byte,byte) int Try writing a type that is a pointer to a function that returns a function in C. It's a bit mind bending.
robotmay 14y ago
I've had that ebook for a while but hadn't read it yet; I'll put some time into it this week I think. Just on the editor front; I've had quite a pleasant time writing Go in vim, but I guess that depends on whether you would class using vim a pleasant time :D
asolove 14y ago
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 http://golang.org/doc/articles/gos_declaration_syntax.html [2] http://c-faq.com/decl/spiral.anderson.html http://c-faq.com/decl/spiral.anderson.html
- mseepgood 14y ago
  [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 14y ago
    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;

thebluesky 14y ago

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 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 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 14y ago
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 14y ago
  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.
genwin 14y ago
Do you know if the memory leak still exists on 64-bit? I wasn't able to determine that. I've read that the solution is to use 64-bit, but I don't know if that really just means that a 64-bit system will take the memory leak far longer to crash it. I'm not too concerned about the attitude of some Golang devs (they are volunteers, after all), but I am very concerned about any memory leak or other serious bug that won't be fixed for a year+.

mseepgood 14y ago

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

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

laktek 14y ago

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

robotmay 14y ago
Those look great - added to my reading list :)

deleted 14y ago

[deleted]

genwin 14y ago

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!