3 ms·

> Batteries included: argparse, pty, locale, configparser, json, uuid, http. All of these excellent modules are used by asciinema and are part of Python’s stand

> Batteries included: argparse, pty, locale, configparser, json, uuid, http. All of these excellent modules are used by asciinema and are part of Python’s standard library. Python stdlib’s quality and stability guarantees are order of magnitude higher than of unversioned Go libs from Github (I believe discrete releases ensure higher quality and more stability). Go also has most of the listed libraries(like http, arg parsing, json) included in stdlib. I'd argue that the the http library in Go is one of the best out there :) Can't disagree about dependency management, hopefully it gets addressed sooner rather than later. There was a good discussion with the Go team on the topic at Gophercon today.

JamesMcMinn 10y ago
That was my initial reaction too, however I think the author was listing _all_ of the libraries used by Asciinema, rather than just the ones they had to find outside of the standard lib. Their point being that Python includes them all, so there's no need to go external.
topspin 10y ago
Dependency management is what drove me away. I drank the Kool-Aid; had the language specification printed and studied it with care. What a wonderful, concise language. Then I tried to actually use it for something. That something involved a few large dependencies and although I was personally able to cope with the dependency problems, after about six weeks I concluded I was wasting time; there was no way I would ever advocate to an employer or co-worker this platform. Solid, easy dependency management and easily reproducible builds are non-optional, and Go doesn't provide either without a bunch of legwork. The folks behind Go have heard this a thousand times and it has done nothing to persuade them to deal with it. That's a no-"Go" for me.
jzelinskie 10y ago
My experience with finding and using a good, terminal-based progress bar library led me down the road to fixing some termios-related issues[0]. I've yet to find many great Go libraries for abstracting the terminal in a cross-platform way. [0]: https://github.com/cheggaaa/pb/pull/55 https://github.com/cheggaaa/pb/pull/55
nameless912 10y ago
Re: dependency management: do people not know about Godep, or am I vastly overestimating its usefulness? Because so far, one of my favorite things about the language is that I can freeze things at the commit level and in the end it's all git so if I need a specific tag I can just grab it and re-Godep. For me at least,Go's idiosyncrasies are far and above more pleasant to deal with than, e.g. Python dependency hell.
- spriggan3 10y ago
  > Re: dependency management: do people not know about Godep, or am I vastly overestimating its usefulness? How many Go package managers out there ? that's right that's the problem. Why invest in this one when most of the community don't use it, don't even tag their releases properly, and frankly just don't care about anything not in the core library or not written by Go maintainers? this is a fucked up situation. I read in this thread that Go is "battery included", well no, it has a few percs and a lot of issues. Go maintainers "We are very opinionated about things but somehow we let the community handle package management because we delivered an half backed one (go get) that fits our needs and we don't care about yours" are a joke.
  - nameless912 10y ago
    I mean, in my opinion a package manager creates as many problems as it solves. Look at pip or npm, both of them are huge, messy, buggy monstrosities that only further complicate packaging in their respective platforms. Maybe Go would be well served by a well written package manager. Maybe. But I've never seen one that makes the process unequivocally better. go get really is good enough for the simple case, which is, 99% of the time, what people want. For me, huge complex dependency graphs are a big code smell. I get concerned whenever I see a program that pulls in lots of very large dependencies using a very fragile mechanism (example: Pip/setup tools) it bothers me. My question is, what would "fix" the situation for you? A pip-style package manager? Because go get has all the important features (in my opinion) without all the pain that comes from such a complex tool. I admit that a lack of semantic versioning is a major pain point right now, but that's only because the go community hasn't found a good solution, in my opinion. But I've actually been working on that particular problem and I think I've nearly solved it. It's just a matter of time before someone figures it out.

JamesMcMinn 10y ago

That was my initial reaction too, however I think the author was listing _all_ of the libraries used by Asciinema, rather than just the ones they had to find outside of the standard lib. Their point being that Python includes them all, so there's no need to go external.

topspin 10y ago

Dependency management is what drove me away. I drank the Kool-Aid; had the language specification printed and studied it with care. What a wonderful, concise language. Then I tried to actually use it for something. That something involved a few large dependencies and although I was personally able to cope with the dependency problems, after about six weeks I concluded I was wasting time; there was no way I would ever advocate to an employer or co-worker this platform. Solid, easy dependency management and easily reproducible builds are non-optional, and Go doesn't provide either without a bunch of legwork. The folks behind Go have heard this a thousand times and it has done nothing to persuade them to deal with it. That's a no-"Go" for me.

jzelinskie 10y ago

My experience with finding and using a good, terminal-based progress bar library led me down the road to fixing some termios-related issues[0]. I've yet to find many great Go libraries for abstracting the terminal in a cross-platform way. [0]: https://github.com/cheggaaa/pb/pull/55 https://github.com/cheggaaa/pb/pull/55

nameless912 10y ago

Re: dependency management: do people not know about Godep, or am I vastly overestimating its usefulness? Because so far, one of my favorite things about the language is that I can freeze things at the commit level and in the end it's all git so if I need a specific tag I can just grab it and re-Godep. For me at least,Go's idiosyncrasies are far and above more pleasant to deal with than, e.g. Python dependency hell.

spriggan3 10y ago
> Re: dependency management: do people not know about Godep, or am I vastly overestimating its usefulness? How many Go package managers out there ? that's right that's the problem. Why invest in this one when most of the community don't use it, don't even tag their releases properly, and frankly just don't care about anything not in the core library or not written by Go maintainers? this is a fucked up situation. I read in this thread that Go is "battery included", well no, it has a few percs and a lot of issues. Go maintainers "We are very opinionated about things but somehow we let the community handle package management because we delivered an half backed one (go get) that fits our needs and we don't care about yours" are a joke.
- nameless912 10y ago
  I mean, in my opinion a package manager creates as many problems as it solves. Look at pip or npm, both of them are huge, messy, buggy monstrosities that only further complicate packaging in their respective platforms. Maybe Go would be well served by a well written package manager. Maybe. But I've never seen one that makes the process unequivocally better. go get really is good enough for the simple case, which is, 99% of the time, what people want. For me, huge complex dependency graphs are a big code smell. I get concerned whenever I see a program that pulls in lots of very large dependencies using a very fragile mechanism (example: Pip/setup tools) it bothers me. My question is, what would "fix" the situation for you? A pip-style package manager? Because go get has all the important features (in my opinion) without all the pain that comes from such a complex tool. I admit that a lack of semantic versioning is a major pain point right now, but that's only because the go community hasn't found a good solution, in my opinion. But I've actually been working on that particular problem and I think I've nearly solved it. It's just a matter of time before someone figures it out.