6 ms·

Currently working with Node.JS and we want to introdcure Go in some new modules. Have 3 major concerns; - Lack of Generics. I know this has been beaten to deat

by eknkc 13y ago

Currently working with Node.JS and we want to introdcure Go in some new modules. Have 3 major concerns; - Lack of Generics. I know this has been beaten to death but after using a dynamic typed language all this time, it is even more painful. - Weird dependency management. No way to lock dependency versions, even if I fork something and depend on it, nested dependencies can fuck up at some point. We need something like NPM to manage our dependencies in a sane way. Importing from live git paths seems like the worst possible solution to this. And there seems to be no widely accepted 3rd party package manager. - Google... At some point, I'd expect the compiler to require a Google+ account to enable optimizations. /s

burntsushi 13y ago
> Importing from live git paths seems like the worst possible solution to this. Then don't do it. Check your dependencies into your repositories and update import paths.
- hdevalence 13y ago
  What happens when the dependencies have bugfixes or security flaws? Why is it better to spread the responsibility for updates over all Go authors instead of to the authors of the libraries in question?
  - nknighthb 13y ago
    You make an explicit, knowledgable decision to update the dependency, like you should be doing with all software in a production environment.
    - frowaway001 13y ago
      Why is this supposed to involve tons of stupid stuff instead of adjusting a version number accordingly?
  - mseepgood 13y ago
    > What happens when the dependencies have bugfixes or security flaws? Copy the new version into the repository, run the import rewriting script and check it in. > Why is it better to spread the responsibility for updates over all Go authors instead of to the authors of the libraries in question? Because you want to have full control over your dependencies. What if the author introduces a breaking change or removes the repository from the internet? Do you want to risk your business by being at the mercy of someone else's repository?
    - gmjosack 13y ago
      What about when the library you want to use has a non-compatible license for distributing it with your source code?
    - deleted 13y ago
      [deleted]
  - burntsushi 13y ago
    Update them when you want. Just like you would with a package manager. If you need to stay up to date, then have something monitor their commit logs.
- eropple 13y ago
  Checking dependencies into my repositories is worse. It hugely increases friction for upgrades (which means fewer people will do it) and pushes monitoring for updates down onto the consumer rather than the maintainer (which means some people will forget and get owned). This is the problem that Maven, RubyGems, etc. have fixed for so very long that I find it really hard to take Go seriously when this is floated as a solution. And that seems to be a regular occurrence in Go: the willing championing of bad but "simple" solutions (error codes as far as the eye can see!) under the mistaken assumption that things are complex just to be complex rather than that they're complex because they solve a bigger problem.
  - burntsushi 13y ago
    > It hugely increases friction for upgrades I can imagine a script that's just a few lines that downloads go-gettable dependencies and updates import paths. You run it at exactly the time you want to update. > have fixed for so very long that I find it really hard to take Go seriously when this is floated as a solution By a large margin, I spend the least amount of time configuring my Go packages for release than for any other language.
    - eropple 13y ago
      I can "imagine" a lot of things, too, or I can change one number in a pom or a Gemfile. Because the infrastructure is both predictable and standardized. (And doesn't require barfing your dependencies' changes into your source tree to do it. Funny, that.) "Write a script" is a poor solution for an endemic problem.
      - burntsushi 13y ago
        It's not an excuse. As I said, I spend much less time configuring Go packages than I do for packages written in other languages.
        eropple 13y ago
        Your claim strains my credulity to the snapping point. Please explain how manual operations are faster (and no more error prone than a transitive dependency solver). Bear in mind that it is a one field change in a Gemfile or Composer or Maven/SBT/whatever-Java.
- schmichael 13y ago
  You don't actually import from live git paths. You import from your local filesystem ($GOPATH). The compiler doesn't care how code gets into $GOPATH. A single tool, "go get", pulls code directly from 3rd parties and puts it in $GOPATH. If you're uncomfortable or frustrated using "go get" there are a number of 3rd party options.
  - burntsushi 13y ago
    I think you may have responded to the wrong comment...
mseepgood 13y ago
> No way to lock dependency versions, even if I fork something and depend on it, nested dependencies can fuck up at some point. Just copy the dependencies into your repo and adjust the import paths. If necessary, flatten the dependencies of dependencies.
Robin_Message 13y ago
Is it possible to depend on a named branch on a remote git path? Because, with some sensible conventions, that would be a suitable way to manage dependencies. (i.e. if you change your major version, start a new branch. if you change your minor version, start a new branch but continue to update the old one also. Actually, without tool support, that's going to get painful, but the idea is sound and requires only local tooling.)
- bearbin 13y ago
  Tags are probably more sensible for this - tag major versions and then people can specify what tag they want.
- tiziano88 13y ago
  this is already supported by Go through tags: http://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies http://golang.org/cmd/go/#hdr-Download_and_install_packages_...
dilap 13y ago
W/o generics you lose two things: 1. Type safety 2. Convenience (1) is certainly no worse than a dynamic language, where you don't have type-safety anywhere. (2) doesn't seem that bad to me. You'll write code like this: x := customStack.Pop().(SaysHello) // error here if x isn't a member of the interface SaysHello x.Hello() As opposed to a dynamic language: x = customStack.Pop() x.Hello() // error here if x doesn't define hello Disclaimer: I've just poked at Go a little bit. I'm thinking about trying it out as a replacement for some Python code I have. Further disclaimer: As a C++ programmer back in the day I used to make a lot of fun of Java for not having generics (it's had them for a long time now, of course). Lately I've been doing Objective-C (where the situation is like Go, but worse -- no generics nor interfaces; it's all just dynamic), and I've been surprised at how not having generics is Not As Bad As You Might Think. It's basically equivalent to a 'dynamic' language.
- dkuntz2 13y ago
  You only lose type safety if you're writing generic containers. If you don't need a customStack or something similar you'll be fine. While I think it's good to know how to write containers, and how they work, how frequently do you really need to write a custom container? What's wrong with the built in ones (provided they exist)?
  - dilap 13y ago
    Yes, didn't mean to imply you lose all static type safety -- you're still way better off on that front than in a language like Python or JavaScript. Basically, if you're happy with a dynamic language, Go makes things better most of the time, but sometimes you have fall back to dynamic checking, because of the lack of generics. Custom containers: Well, it's definitely true that you can get pretty far with just arrays and hash tables -- which Go special-cases! -- but you're probably gunna want something fancier eventually...
bostik 13y ago
I use go occasionally for minor projects, and I have learned to live without generics. In a couple of projects I ended up implementing $myproj/types which exports all the data structures I want. At that point adding the types.TypeName.Min()/.Max()/... becomes natural. It's already effectively a custom struct, so I have no problem writing the helper functions to deal with them. Heck, I used to do that in C all the time anyway. However... The dependency management is my pet peeve #1. I see no problem pulling dependencies from external repositories and building them locally. That practice spans back to at least BSD ports. What I dislike is the fact that I can't specify the version or commit I want to depend on. I find that the current implementation for "go get" assumes everyone is either a hard-core hacker, always living on the edge (and sometime pushing it) - or they have a full-fledged internal repository infrastructure in place to deal with all the mirroring and continuous integration needs. Go decides internally which revision to checkout and build, using a priority list of hardcoded tag/branch names. If those are not available, it defaults to master:HEAD, /trunk or whatever equal alternative is supported by the underlying SCM. You can not specify "I want to use _this_ version, period" which is a crying shame. I understand that internally Google doesn't use go get at all. They have their own mirrored repos for everything they need during their builds. Understandable. But ignoring the well-established practice of user-specified upstream component versions is just rude. It forces some "makes sense only in very large organisation" type of practices down the developers' throats.
- coldtea 13y ago
  >Heck, I used to do that in C all the time anyway. Not a very encouraging notion, considering the issue is quite trivial, solved in 200 other languages, and it's 2014 already.
- stock_toaster 13y ago
  Have you looked at godep? I have been using it lately and it has been working pretty well. https://github.com/kr/godep https://github.com/kr/godep
  - bostik 13y ago
    Oh, thank you so much. I think I've heard of it at some point but it had escaped my mind. That goes on to my pile of things to try out.
shurcooL 13y ago
> I know this has been beaten to death You don't say. 1. http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html http://commandcenter.blogspot.com/2011/12/esmereldas-imagina... 2. https://github.com/kr/godep https://github.com/kr/godep 3. http://golang.org/LICENSE http://golang.org/LICENSE

by eknkc 13y ago

burntsushi 13y ago

> Importing from live git paths seems like the worst possible solution to this. Then don't do it. Check your dependencies into your repositories and update import paths.

hdevalence 13y ago
What happens when the dependencies have bugfixes or security flaws? Why is it better to spread the responsibility for updates over all Go authors instead of to the authors of the libraries in question?
- nknighthb 13y ago
  You make an explicit, knowledgable decision to update the dependency, like you should be doing with all software in a production environment.
  - frowaway001 13y ago
    Why is this supposed to involve tons of stupid stuff instead of adjusting a version number accordingly?
- mseepgood 13y ago
  > What happens when the dependencies have bugfixes or security flaws? Copy the new version into the repository, run the import rewriting script and check it in. > Why is it better to spread the responsibility for updates over all Go authors instead of to the authors of the libraries in question? Because you want to have full control over your dependencies. What if the author introduces a breaking change or removes the repository from the internet? Do you want to risk your business by being at the mercy of someone else's repository?
  - gmjosack 13y ago
    What about when the library you want to use has a non-compatible license for distributing it with your source code?
  - deleted 13y ago
    [deleted]
- burntsushi 13y ago
  Update them when you want. Just like you would with a package manager. If you need to stay up to date, then have something monitor their commit logs.
eropple 13y ago
Checking dependencies into my repositories is worse. It hugely increases friction for upgrades (which means fewer people will do it) and pushes monitoring for updates down onto the consumer rather than the maintainer (which means some people will forget and get owned). This is the problem that Maven, RubyGems, etc. have fixed for so very long that I find it really hard to take Go seriously when this is floated as a solution. And that seems to be a regular occurrence in Go: the willing championing of bad but "simple" solutions (error codes as far as the eye can see!) under the mistaken assumption that things are complex just to be complex rather than that they're complex because they solve a bigger problem.
- burntsushi 13y ago
  > It hugely increases friction for upgrades I can imagine a script that's just a few lines that downloads go-gettable dependencies and updates import paths. You run it at exactly the time you want to update. > have fixed for so very long that I find it really hard to take Go seriously when this is floated as a solution By a large margin, I spend the least amount of time configuring my Go packages for release than for any other language.
  - eropple 13y ago
    I can "imagine" a lot of things, too, or I can change one number in a pom or a Gemfile. Because the infrastructure is both predictable and standardized. (And doesn't require barfing your dependencies' changes into your source tree to do it. Funny, that.) "Write a script" is a poor solution for an endemic problem.
    - burntsushi 13y ago
      It's not an excuse. As I said, I spend much less time configuring Go packages than I do for packages written in other languages.
      - eropple 13y ago
        Your claim strains my credulity to the snapping point. Please explain how manual operations are faster (and no more error prone than a transitive dependency solver). Bear in mind that it is a one field change in a Gemfile or Composer or Maven/SBT/whatever-Java.
schmichael 13y ago
You don't actually import from live git paths. You import from your local filesystem ($GOPATH). The compiler doesn't care how code gets into $GOPATH. A single tool, "go get", pulls code directly from 3rd parties and puts it in $GOPATH. If you're uncomfortable or frustrated using "go get" there are a number of 3rd party options.
- burntsushi 13y ago
  I think you may have responded to the wrong comment...

mseepgood 13y ago

> No way to lock dependency versions, even if I fork something and depend on it, nested dependencies can fuck up at some point. Just copy the dependencies into your repo and adjust the import paths. If necessary, flatten the dependencies of dependencies.

Robin_Message 13y ago

Is it possible to depend on a named branch on a remote git path? Because, with some sensible conventions, that would be a suitable way to manage dependencies. (i.e. if you change your major version, start a new branch. if you change your minor version, start a new branch but continue to update the old one also. Actually, without tool support, that's going to get painful, but the idea is sound and requires only local tooling.)

bearbin 13y ago
Tags are probably more sensible for this - tag major versions and then people can specify what tag they want.
tiziano88 13y ago
this is already supported by Go through tags: http://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies http://golang.org/cmd/go/#hdr-Download_and_install_packages_...

dilap 13y ago

W/o generics you lose two things: 1. Type safety 2. Convenience (1) is certainly no worse than a dynamic language, where you don't have type-safety anywhere. (2) doesn't seem that bad to me. You'll write code like this: x := customStack.Pop().(SaysHello) // error here if x isn't a member of the interface SaysHello x.Hello() As opposed to a dynamic language: x = customStack.Pop() x.Hello() // error here if x doesn't define hello Disclaimer: I've just poked at Go a little bit. I'm thinking about trying it out as a replacement for some Python code I have. Further disclaimer: As a C++ programmer back in the day I used to make a lot of fun of Java for not having generics (it's had them for a long time now, of course). Lately I've been doing Objective-C (where the situation is like Go, but worse -- no generics nor interfaces; it's all just dynamic), and I've been surprised at how not having generics is Not As Bad As You Might Think. It's basically equivalent to a 'dynamic' language.

dkuntz2 13y ago
You only lose type safety if you're writing generic containers. If you don't need a customStack or something similar you'll be fine. While I think it's good to know how to write containers, and how they work, how frequently do you really need to write a custom container? What's wrong with the built in ones (provided they exist)?
- dilap 13y ago
  Yes, didn't mean to imply you lose all static type safety -- you're still way better off on that front than in a language like Python or JavaScript. Basically, if you're happy with a dynamic language, Go makes things better most of the time, but sometimes you have fall back to dynamic checking, because of the lack of generics. Custom containers: Well, it's definitely true that you can get pretty far with just arrays and hash tables -- which Go special-cases! -- but you're probably gunna want something fancier eventually...

bostik 13y ago

I use go occasionally for minor projects, and I have learned to live without generics. In a couple of projects I ended up implementing $myproj/types which exports all the data structures I want. At that point adding the types.TypeName.Min()/.Max()/... becomes natural. It's already effectively a custom struct, so I have no problem writing the helper functions to deal with them. Heck, I used to do that in C all the time anyway. However... The dependency management is my pet peeve #1. I see no problem pulling dependencies from external repositories and building them locally. That practice spans back to at least BSD ports. What I dislike is the fact that I can't specify the version or commit I want to depend on. I find that the current implementation for "go get" assumes everyone is either a hard-core hacker, always living on the edge (and sometime pushing it) - or they have a full-fledged internal repository infrastructure in place to deal with all the mirroring and continuous integration needs. Go decides internally which revision to checkout and build, using a priority list of hardcoded tag/branch names. If those are not available, it defaults to master:HEAD, /trunk or whatever equal alternative is supported by the underlying SCM. You can not specify "I want to use _this_ version, period" which is a crying shame. I understand that internally Google doesn't use go get at all. They have their own mirrored repos for everything they need during their builds. Understandable. But ignoring the well-established practice of user-specified upstream component versions is just rude. It forces some "makes sense only in very large organisation" type of practices down the developers' throats.

coldtea 13y ago
>Heck, I used to do that in C all the time anyway. Not a very encouraging notion, considering the issue is quite trivial, solved in 200 other languages, and it's 2014 already.
stock_toaster 13y ago
Have you looked at godep? I have been using it lately and it has been working pretty well. https://github.com/kr/godep https://github.com/kr/godep
- bostik 13y ago
  Oh, thank you so much. I think I've heard of it at some point but it had escaped my mind. That goes on to my pile of things to try out.

shurcooL 13y ago

> I know this has been beaten to death You don't say. 1. http://commandcenter.blogspot.com/2011/12/esmereldas-imagination.html http://commandcenter.blogspot.com/2011/12/esmereldas-imagina... 2. https://github.com/kr/godep https://github.com/kr/godep 3. http://golang.org/LICENSE http://golang.org/LICENSE