One thing I noticed the last time I worked with go was how hostile the go team was to stdlib changes and additions.
Their default argument parsing library is pretty horrible - it uses single-dash for word flags (thus does not differenciate between -h -e -l -p and -help...) and they refuse to implement double-dash, citing "there's third party libs for that".
It really annoys me. I understand the predicament that the stdlib should remain relatively stable, but setting the wrong example in the stdlib itself is really bad - third party libs or not, you know a fair share of people will stick to the stdlib where possible.
I had the exact same experience with python a few days ago. Python's builtin elementtree can't add doctypes at all and is hostile to patches adding it. The reasoning being "lxml exists". For the simple task of adding a doctype, one must either deal with a cpython-specific extension that is a pain in the arse to build, or hack it in with undocumented functionality in minidom.
I love that the go team is hostile to breaking stdlib changes (which is what changing the flag package would be). It is so nice to be able to upgrade to the latest go version without having to worry about what it might break in production.
It is true that the go team is cautious about what goes into the stdlib. Part of that is their commitment to long term support of the standard library. To be able to do that effectively they need to be discerning when choosing what to have there vs an external library. But that doesn't mean that they don't take big changes. HTTP2 support will be in 1.6 which is a huge addition.
Haskell has problem too, where the Prelude (a std lib imorted into programs by default) is designed for learning the language, and getting real work done requrequires supressing the Prelude to work around its bad performance and unsafe semantics.
They wanted to help get the language off the ground. Without the stdlib at launch, I don't think Go would have been nearly as well received. I feel like it's one of the key pieces people first coming to the language like.
The golang.com/x/ packages seems to be handling extending the stdlib at this point.
You could view the standard/core library as the minimum need to make a language pragmatically useful. You could also view it as trying to prevent fragmentation. However, the stability of standard/core libraries is also what causes them to be "where things go to die" because changing them is very hard to do without breaking things.
In the case of Go they also prefer to let third parties experiment and determine which design works best rather than trying to guess.
So it's all a bit subjective hence the differing opinions. The point is it's people trying to balance trade-offs.
Nope, not under GNU options, they aren't. It's just a culture difference, nothing special.
The Go team comes from an old unix background where long options with a single '-' was standard. GNU changed that, and a good part of the world standardized around it (but not the X11 people for example); now the cultures collide, and people don't understand why the behaviour is different.
I'm not super confident but I think the stdlib flags are a POSIX implementation. However, POSIX is not what most people are used to. For example, POSIX says flags/options come before arguments but most Linux shells allow you to put the flags/options after arguments as well, e.g. `ls ~ -lh`.
The lack of double-dash in the stdlib really annoys me. Almost all command line tools use a single dash for single letter arguments (-h) and double-dash for anything longer (--help).
This looks like it has real potential. I've lost count of the times I've had to scroll through a lengthy tmux buffer just to find the key 2 lines of the stack trace.
Seems like a great tool for wrangling Go's stack trace. Particularly relevant if you're running a large number of go routines since when they panic you'll console will blow up.
Sorry for such a pedantic comment for such a nice tool, but... I noticed that GIFs were attracting my attention, but were too for me to comprehend what was happening. They are not better than static text (you can color it if you want) or image.
Is it common now to present screencasts instead of pasting text copied from for CLI tools?
GIFs are much better in this context because the selling point of the tool is the workflow. Perhaps having GIF playback controls implemented in the browser would improve it.
Correct me if I'm wrong, but you cannot have colored text in GitHub markdown. You can have syntax coloring, but in this case he's showing terminal output.
Because while far far denser and easier to parse by humans, it discards a considerable amount of data. I think it's perfectly sensible for the default toolchain to dump the most complete representation and allow users to use tools to get the representation they prefer.
Because this one involve checking duplicates and does a fair amount of logic. When the process is crashing, all bets are off and you may not be able to allocate memory for this processing. This is why they simply dump all there is to stderr and exit.
