5 ms·

I have mixed feelings about Go. For those who didn't try it yet here are the biggest advantages of Go: - it's totally easy to learn and can be mastered in a d

by aikah 12y ago

I have mixed feelings about Go. For those who didn't try it yet here are the biggest advantages of Go: - it's totally easy to learn and can be mastered in a day - it's fast and typesafe - the concurrency model is great,no question - I personally like the error system, no exceptions but you can still "bubble up" errors with multiple return types - it has, in my opinion a comprehensive standard library,you can even do websockets and image compression with it. The draw backs : - no generics clearly the biggest drawback, which means a lot of copy and paste - the lack of idiomatic way to deal with dependencies(no defacto package manager) I think the ease of use justifies Go adoption in any team. It doesn't replace ruby or python for web programming ( little value in coding a CMS in Go , rails makes more sense),but when it comes to backend or webservices, it's a killer tool. compared to java, it's as fast and consumes WAY less memory.

semi-extrinsic 12y ago
The lack of a package manager is a good thing, since this is the job of the operating system. That Windows and OSX have crappy/nonexisting package managers does not mean every language should roll its own. If the police in your city are not doing their job, you shouldn't resort to vigilantism, you should stage a protest. Ideally.
- shanemhansen 12y ago
  Package management is the job of the operating system, but this statement doesn't make much sense for go because go binaries are statically linked to go packages. So using an OS-provided version of crypto/tls or net/http isn't really an option. Go dependencies are basically a build-time thing. (cgo is an exception)
- pjmlp 12y ago
  Are you aware how many OSs are out there?
CatDevURandom 12y ago
> which means a lot of copy and paste Again, I don't think Go is perfect but on my list of wants, generics are not in the top 5. Can you qualify "a lot" in a real project you've worked on? Because after writing a good chunk (over 50k lines) of Go code, I haven't felt the sting as much as I hear it complained about. > the lack of idiomatic way to deal with dependencies(no defacto package manager Again, is this really a big deal? There's plenty of options, and if you are shipping any-type of commercial product you are going to want to be vendoring your dependencies in-house anyway. In which case, depending on something like NPM/remote maven repos is not a viable options anyway.
- rubiquity 12y ago
  > Again, I don't think Go is perfect but on my list of wants, generics are not in the top 5. Would you mind sharing your top 5 wants? I'm interested.
  - CatDevURandom 12y ago
    Sure! In order: A Debugger. Better IDE options. Binary sizes small enough to use for embedded programming. Pauseless Garbage Collector. Less awkward variable declaration.
    - bsg75 12y ago
      > A Debugger https://golang.org/doc/gdb https://golang.org/doc/gdb (some limitations IIRC) https://github.com/derekparker/delve https://github.com/derekparker/delve (a work in progress, but promising)
- cgag 12y ago
  All the for loops and array indexing you do in place of simple map / filter / reduce calls would count in my definition of copy and pasted code.
- sigmaml 12y ago
  I documented a real-life experience here: http://oneofmanyworlds.blogspot.in/2014/01/another-go-at-go-failed.html http://oneofmanyworlds.blogspot.in/2014/01/another-go-at-go-.... Read the requirement, elaborate a little more by me in some of the comments, and see how the combinations I had to deal with quickly multiplied to cause high tedium.
BuckRogers 12y ago
I'm in a similar boat. I've tried Go, and partially agree with your sentiment that the ease of use justifies usage of it in any team. Even with its flaws, it's a tempting feature. But I'm not sure if bringing -anything- into an existing stack should be done lightly though since someone has to maintain whatever is brought in. Even if the ramp up time is shorter than usual. For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks? I say this as someone who has never really ran into issues with Python performance, but am looking towards learning Rust once it hits 1.0 for writing my first non-Python library because if I can find something CPU intensive enough, I can justify deep diving on Rust. Doesn't mean I won't ever run into performance issues, but even Rust may not be necessary (for me), with PyPy/Pyston around. Go itself is more a replacement for other tech, rather than complimentary, which in my view is the biggest drawback not on your list. I like things with big ecosystems that work well together so you're not stuck on an island, and the Python/C(++)/Rust world has great interop. Unless you're a true Go diehard about the language for whatever reasons, this isn't really what I think many like myself are looking for. I see more value in simply adopting another implementation of a shop's existing platform, if you have so many options at least. I'll be really interested to hear responses to this, as I don't feel interop with Go has been discussed often. Seems people who really like Go are either 'all in' or not at all, figuratively and literally.
- unoti 12y ago
  > For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks? Two big things here, for my applications. 1. Memory. You mention CPU use, but memory use is even more critical for what I do. For game servers, for example, lower memory usage for an application can change the multipliers on how many users I can handle per server. This can make a dramatic (like 20x) difference in what you can offer users for free vs charging. 2. Static compilation. This makes a massive difference over Python in terms of catching and correcting problems at compile time vs run time.
  - 12y ago
wallyhs 12y ago
Don't forget about the tooling: unit testing, benchmarking, generated documentation, code formatting, and emacs+vim plugins are included in the official package. I think these are often overlooked when describing its benefits. You can jump in and start working right away. In discussions about error handling in Go, I rarely see mention of panic used for private exception handling. If a module exposes a small surface area, the public entry points can recover from panics and return them as errors. Private functions can then use panic to report errors: func PublicEntryPoint(input string) (output []byte, err error) { defer func() { if e := recover(); e != nil { output = nil err = e } }() err = nil output = privateFunc(input) // no need to check for error here return } func privateFunc(input string) []byte { foo := otherPrivateFunc(...) // no need to check for error here // ... } func otherPrivateFunc() int { // ... panic(fmt.Errorf("Something is wrong")) } I would panic-recover a specific type of error instead of the generic "error" type, but I'm simplifying for the example. Also, it is not recommended to panic across module boundaries.
ascotan 12y ago
I sort of agree with the go authors that there is not idiomatic way to deal with dependency management at all. (see: https://golang.org/doc/faq#get_version https://golang.org/doc/faq#get_version) They all have their ups/downs and mostly it has to do with the language they are supporting. Nodejs: + transparent code on download - virtually impossible to mirror - executes arbitrary 'script' blocks that install stuff on your system - subpar transitive dependency management scheme Java: + great transitive dependency management + private repos/mirrors are easy with well supported tools - black box byte code with no licenses - overly complicated software (ivy/maven) Python (pip): + simple and easy - virtual environment hell There are things that i like and don't like with go get: + dirt simple and used from the command line + code comes into src/. This means that you can see the code and the licenses that you are pulling in. This makes it easy to inspect code in your project. I don't have a hidden code repo in my home directory or some crap. + I can clearly see the licenses that i'm pulling in. If you have a GPL in your project it's pretty trivial to audit this (unlike other tools were you have to track down the homepages of 20 random people). - code is pulled from HEAD. Frankly this sucks. Hopefully people get their act together and release their software and got get will be able to pull a release. I can see the advantage of pulling from head if you're constantly iterating and monitoring for fixes. However, pulling from HEAD introduces the risk that there is a major untested defect in what you just pulled. Overall as long as there is not a huge chain of dependencies in the code that you're pulling, and as long as you're relatively confident that HEAD isn't going to bust you release, it's a great system. Honestly I think that it makes the developer more wary about pulling in random half-baked code from the internet into their project. Maybe that's a healthy thing.
- nothrabannosir 12y ago
  go get first searches for a go1 branch or tag and pulls from that, if present. master branch is only a fallback.
doomrobo 12y ago
Is it truly typesafe if the interface{} idiom is commonly used in lieu of real generics?

by aikah 12y ago

semi-extrinsic 12y ago

The lack of a package manager is a good thing, since this is the job of the operating system. That Windows and OSX have crappy/nonexisting package managers does not mean every language should roll its own. If the police in your city are not doing their job, you shouldn't resort to vigilantism, you should stage a protest. Ideally.

shanemhansen 12y ago
Package management is the job of the operating system, but this statement doesn't make much sense for go because go binaries are statically linked to go packages. So using an OS-provided version of crypto/tls or net/http isn't really an option. Go dependencies are basically a build-time thing. (cgo is an exception)
pjmlp 12y ago
Are you aware how many OSs are out there?

CatDevURandom 12y ago

> which means a lot of copy and paste Again, I don't think Go is perfect but on my list of wants, generics are not in the top 5. Can you qualify "a lot" in a real project you've worked on? Because after writing a good chunk (over 50k lines) of Go code, I haven't felt the sting as much as I hear it complained about. > the lack of idiomatic way to deal with dependencies(no defacto package manager Again, is this really a big deal? There's plenty of options, and if you are shipping any-type of commercial product you are going to want to be vendoring your dependencies in-house anyway. In which case, depending on something like NPM/remote maven repos is not a viable options anyway.

rubiquity 12y ago
> Again, I don't think Go is perfect but on my list of wants, generics are not in the top 5. Would you mind sharing your top 5 wants? I'm interested.
- CatDevURandom 12y ago
  Sure! In order: A Debugger. Better IDE options. Binary sizes small enough to use for embedded programming. Pauseless Garbage Collector. Less awkward variable declaration.
  - bsg75 12y ago
    > A Debugger https://golang.org/doc/gdb https://golang.org/doc/gdb (some limitations IIRC) https://github.com/derekparker/delve https://github.com/derekparker/delve (a work in progress, but promising)
cgag 12y ago
All the for loops and array indexing you do in place of simple map / filter / reduce calls would count in my definition of copy and pasted code.
sigmaml 12y ago
I documented a real-life experience here: http://oneofmanyworlds.blogspot.in/2014/01/another-go-at-go-failed.html http://oneofmanyworlds.blogspot.in/2014/01/another-go-at-go-.... Read the requirement, elaborate a little more by me in some of the comments, and see how the combinations I had to deal with quickly multiplied to cause high tedium.

BuckRogers 12y ago

I'm in a similar boat. I've tried Go, and partially agree with your sentiment that the ease of use justifies usage of it in any team. Even with its flaws, it's a tempting feature. But I'm not sure if bringing -anything- into an existing stack should be done lightly though since someone has to maintain whatever is brought in. Even if the ramp up time is shorter than usual. For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks? I say this as someone who has never really ran into issues with Python performance, but am looking towards learning Rust once it hits 1.0 for writing my first non-Python library because if I can find something CPU intensive enough, I can justify deep diving on Rust. Doesn't mean I won't ever run into performance issues, but even Rust may not be necessary (for me), with PyPy/Pyston around. Go itself is more a replacement for other tech, rather than complimentary, which in my view is the biggest drawback not on your list. I like things with big ecosystems that work well together so you're not stuck on an island, and the Python/C(++)/Rust world has great interop. Unless you're a true Go diehard about the language for whatever reasons, this isn't really what I think many like myself are looking for. I see more value in simply adopting another implementation of a shop's existing platform, if you have so many options at least. I'll be really interested to hear responses to this, as I don't feel interop with Go has been discussed often. Seems people who really like Go are either 'all in' or not at all, figuratively and literally.

unoti 12y ago
> For backend/webservices, I initially tended to agree Go is a killer tool. But if you are a Python shop, why would I bring this into my stack instead of using PyPy (or soon, Pyston) for CPU-intensive tasks? Two big things here, for my applications. 1. Memory. You mention CPU use, but memory use is even more critical for what I do. For game servers, for example, lower memory usage for an application can change the multipliers on how many users I can handle per server. This can make a dramatic (like 20x) difference in what you can offer users for free vs charging. 2. Static compilation. This makes a massive difference over Python in terms of catching and correcting problems at compile time vs run time.
- 12y ago

wallyhs 12y ago

Don't forget about the tooling: unit testing, benchmarking, generated documentation, code formatting, and emacs+vim plugins are included in the official package. I think these are often overlooked when describing its benefits. You can jump in and start working right away. In discussions about error handling in Go, I rarely see mention of panic used for private exception handling. If a module exposes a small surface area, the public entry points can recover from panics and return them as errors. Private functions can then use panic to report errors: func PublicEntryPoint(input string) (output []byte, err error) { defer func() { if e := recover(); e != nil { output = nil err = e } }() err = nil output = privateFunc(input) // no need to check for error here return } func privateFunc(input string) []byte { foo := otherPrivateFunc(...) // no need to check for error here // ... } func otherPrivateFunc() int { // ... panic(fmt.Errorf("Something is wrong")) } I would panic-recover a specific type of error instead of the generic "error" type, but I'm simplifying for the example. Also, it is not recommended to panic across module boundaries.

ascotan 12y ago

I sort of agree with the go authors that there is not idiomatic way to deal with dependency management at all. (see: https://golang.org/doc/faq#get_version https://golang.org/doc/faq#get_version) They all have their ups/downs and mostly it has to do with the language they are supporting. Nodejs: + transparent code on download - virtually impossible to mirror - executes arbitrary 'script' blocks that install stuff on your system - subpar transitive dependency management scheme Java: + great transitive dependency management + private repos/mirrors are easy with well supported tools - black box byte code with no licenses - overly complicated software (ivy/maven) Python (pip): + simple and easy - virtual environment hell There are things that i like and don't like with go get: + dirt simple and used from the command line + code comes into src/. This means that you can see the code and the licenses that you are pulling in. This makes it easy to inspect code in your project. I don't have a hidden code repo in my home directory or some crap. + I can clearly see the licenses that i'm pulling in. If you have a GPL in your project it's pretty trivial to audit this (unlike other tools were you have to track down the homepages of 20 random people). - code is pulled from HEAD. Frankly this sucks. Hopefully people get their act together and release their software and got get will be able to pull a release. I can see the advantage of pulling from head if you're constantly iterating and monitoring for fixes. However, pulling from HEAD introduces the risk that there is a major untested defect in what you just pulled. Overall as long as there is not a huge chain of dependencies in the code that you're pulling, and as long as you're relatively confident that HEAD isn't going to bust you release, it's a great system. Honestly I think that it makes the developer more wary about pulling in random half-baked code from the internet into their project. Maybe that's a healthy thing.

nothrabannosir 12y ago
go get first searches for a go1 branch or tag and pulls from that, if present. master branch is only a fallback.

doomrobo 12y ago

Is it truly typesafe if the interface{} idiom is commonly used in lieu of real generics?