121–127 of 127 posts
Earlier quoted context omitted.
Actually if you import "net" go links to libc.so and some others.
I believe "net" does so for native dns lookups. You can disable that by building go with 'CGO_ENABLED=0', if desired.
Earlier quoted context omitted.
> all of his bullets apply to GHC Haskell too No chance. Using the `go` tool to install packages is at least an order of magnitude less annoying than using `cabal`.
When did you last use `cabal`? Cabal works much better now, and most of the problems were due to over-conservative version ranges combined with an over-eager reinstallation policy that overwrote packages in a breaking way. That was fixed about 6 months ago, IIRC.
And I'm not really referring to its weird behavior. To use cabal, you have to write a cabal file to specify dependencies, build instructions, etc. With the `go` tool, no such meta data is required. Everything that is needed to build a package is inferred from the source by the `go` tool. This is what makes it less annoying than most other distribution tools.
Of course, most other distribution tools support a larger number of options, so perhaps its not a fair comparison. But that is irrelevant to typical workflow annoyances.
Earlier quoted context omitted.
When did you last use `cabal`? Cabal works much better now, and most of the problems were due to over-conservative version ranges combined with an over-eager reinstallation policy that overwrote packages in a breaking way. That was fixed about 6 months ago, IIRC.
A few weeks ago. And I'm not really referring to its weird behavior. To use cabal, you have to write a cabal file to specify dependencies, build instructions, etc. With the `go` tool, no such meta data is required. Everything that is needed to build a package is inferred from the source by the `go` tool. This is what makes it less annoying than most other distribution tools. Of course, most other distribution tools s…
Earlier quoted context omitted.
If we look at CPAN http://search.cpan.org/search?query=redis&mode=all , there are a few things right in the search results. We have version numbers, release dates, and a review score. All of those give you a chance at finding a half decent library. The first result was updated a week or 2 ago and has 4 significant digits in the version number. None of it's a guarantee but it's a place to get started.
It doesn't seem to be a place to get started for Go though. I just did a search for "golang redis" and it showed me a single perl redis lib? I like the idea of the reviews and ratings though. Normally I would put almost no value in a rating system but we need to somehow separate the good from the bad without having to dive in and look at and profile code from 20 diff libs on a daily basis.
Earlier quoted context omitted.
Try http://godoc.org/ Because Go uses URLs for package names its easy to build tools like godoc.org that automatically aggregate packages from the web.
It's a good start but it needs many more features to be considered usable. For example, I just did a search for "redis" and about 30 libs came up. Half of them don't even have a description. How can I know which one to pick at a glance? Asking me to evaluate and profile 30 different libs for just a single task is unreasonable. Also this page isn't even on Google's first page for when you search for something. I didn'…
godoc.org is an interesting service because its package list is produced as a by-product of people using it to read package documentation.
Earlier quoted context omitted.
I write haskell code all day. I spend my day writing it at work (with occasional HN breaks obviously) and then I go home and write personal projects in it. I advocate haskell on a semi-regular basis. I certainly fall on the pro-haskell side of things. But GHC absolutely does not meet all those bullet points. Compiler speed is not some minor difference, it is absolutely massive. Build times of 30 seconds vs 2 seconds,…
> Compiler speed is not some minor difference, it is absolutely massive. Build times of 30 seconds vs 2 seconds, and that is without counting the 10 seconds of cabal resolving dependencies I simply did not play with Go to know the compilation speeds. I believe you that it is a massive difference, and it is indeed a major Go advantage. > GHC does not come with command line docs. The haddocks are available from the com…
Hoogle is roughly the equivalent. It doesn't come with ghc though, and the rather lengthy dependency list has caused problems getting it installed before. Is there a command line only version that doesn't need all the web stuff?
>Did you try -optl-static?
Yeah, no such luck. It turns out go can't do this either though, so that one shouldn't have been on the list in the first place.
>There are tools to format Haskell code by certain conventions on hackage.
The "being included with the compiler" aspect is pretty big here. People are much more likely to format their code if they already have the tool to do it. I'm not sure what you mean by tools available on hackage though. Stylish-haskell is about it, and all it does is align and sort imports/pragmas. Gofmt can basically rewrite go code however you want it to. Sort of like if hlint were built in to stylish haskell and did the replacements instead of suggesting them.
Earlier quoted context omitted.
A few weeks ago. And I'm not really referring to its weird behavior. To use cabal, you have to write a cabal file to specify dependencies, build instructions, etc. With the `go` tool, no such meta data is required. Everything that is needed to build a package is inferred from the source by the `go` tool. This is what makes it less annoying than most other distribution tools. Of course, most other distribution tools s…
Well, how can it infer the dependency on particular versions? Or on particular implementations of some interface you're using?
> Of course, most other distribution tools support a larger number of options, so perhaps its not a fair comparison. But that is irrelevant to typical workflow annoyances.
If you need to stick to a particular version of a software package, the common workflow involves using existing tools. (i.e., fork.)