Unlike the main post, this is a good use of ASCII art. i.e. to show a drawing/symbol not to make numbers more difficult to parse...

This is much much better. Closer to "beautiful" than the one featured here.

Yeah, it's beautiful if

1) you think mutable variables are beautiful

2) you think stuffing everything into one file is beautiful

3) you think defining functions at the root namespace is beautiful

4) you think consecutive repeated property accesses stuffed into a consecutively repeating boolean check like this are beautiful: if h.Time == "0" || h.Time == "100" || h.Time == "200" || h.Time == "300" || h.Time == "400" || h.Time == "500" || h.Time == "600" || h.Time == "700" || h.Time == "1400" || h.Time == "1500" || h.Time == "1600" || h.Time == "2300"

5) if you think embedding ANSI color codes across all strings instead of centralizing all that ugliness somewhere is beautiful

6) if you think not separating your command-line-handling code from your problem-modeling code is beautiful (see: Hexagonal Architecture http://alistair.cockburn.us/Hexagonal+architecture)

7) If you think having no fucking test suite to speak of, given all that mangled mutating code is beautiful (to me this is the MOST egregious non-beautiful thing in the entire "project")

Then, yes. WeGo is beautiful.

Frankly I'm shocked that what people call "beautiful" can differ that fucking much.

I think the parent was referring to the console display output rather than the code itself.

lol. then I guess I will step off my pedestal and agree. I mean... I think Figlet does a better job than all of these, but anyway

Can anyone explain why a dependency of this app is a "working Go environment"? I thought one of golang's selling points was the fact that it created a simple binary.

As far as I can tell, the Go environment is simply being used as a cheap installer, is that correct?

In my opinion its more like: Go comes with a package-management/install system onboard, and for every 'go install', there's a full copy of working sources which someone, some day, might consider reading and contributing to ..

So I think, at least as a go newbie, that its quite handy that pretty much every tool I might be interested in - because it was written in Go - comes with full sources onboard as a basic, starting-gate, expectation. At least, I am quite happy to be learning Go this way ..

Because he's sharing the source code rather than a compiled binary. It's no different to having make + gcc listed as a dependency for C++ code.

Strictly there is a little hindrance for the non-gopher user because this won't work until they set up a Go workspace, i.e. decided where they want GOPATH to be, set that, and added $GOPATH/bin to PATH to have the executable be runnable.

    $ env -i $(which go) get github.com/schachmat/wego
    package github.com/schachmat/wego: cannot download, $GOPATH not set. For more details see: go help gopath

Indeed, but that's a separate point. The question was why Go was listed as a dependency and my answer was because it's a source code repository.

Also, you left off GOROOT from your Go environment :)

> The question was why Go was listed as a dependency

You may have read it that way but the question was explicitly referring to "working Go environment"

Only because that was the terminology used on the Github readme. He was quoting it verbatim rather than asking what environmental variables needed setting. The reason I think this is because he also went on to say "I thought one of golang's selling points was the fact that it created a simple binary." which relates directly to discussions people make about JIT compiled (eg Python, Javascript, etc) vs AOT compiled (eg C++ and Go).

It's also worth noting that you're only specifically discussing environmental variables, where as a development environment is more than just that. Aside having your build tools in PATH (and lets not forget that gcc and make need this just as much as go does), you need supporting shells for the ./config(ure) scripts, any source libraries for C++ includes, and so forth. So you could equally use the same "working [language] environment" terminology to describe C++ - or in fact any other programming language too.

Which is why I think he was asking why he needed Go installed to begin with.

Alright, well hopefully somebody gleans something from our little thread either way.

So request a binary then. You're basically moaning that an open source project is shipping source code.

And FYI, Go is in quite a few distro repos so you might be able to just:

  apt-get install go-lang
  mkdir -p ~/go/src ~go/bin
  export GOPATH=~/go
  go get github.com/schachmat/wego
  go install github.com/schachmat/wego

However considering this is an open source CLI tool, I don't think it's at all unreasonable to expect he user to do a bit more manual work to compile and run this tool from the command line.

In fact, quite frankly, I find it rather disgusting that someone should share their work and source code like this and have others moan simply because they're too bloody lazy to compile it themselves. I mean seriously guys, this is Hacker News, not PC World Magazine.

It actually does work this way. 'Install Go; go get github.com/me/my-program'. Done.

Wow thanks for sharing.. this is really is beautiful!

That's really mind blowing! Thanks for sharing this.

Thanks, wego is very beautiful and quite useful!