You beat me to it, so I'll just add that figlet in combination with the inestimable cowsay (http://en.wikipedia.org/wiki/Cowsay) produces excellent results.
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.
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?
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
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.
Absolutely. I'm happy to `apt-get install` something, but the conceptual overhead of "let me configure a $language development environment" is high enough that I'm not going to bother just to install this awesome looking tool.
I'd love it if this had been packaged in a way similar to Python or Node tools, where installation is as simple as 'install Python and pip; pip install my-program', and more-experienced users (or those who want source) can clone the git repo.
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.
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 ..
I son't know but I love ncurses software and find the actual UI "beautiful since it gets me the information quickly and quickly lets me get things done.
I find my wee-chat with 256 color urxvt with Source Code Pro font in Light Solarized to be the best looking IRC client ever :)
I'm going to be honest... This is an ugly looking pig of a command line tool. The giant ascii art looks bad and does nothing for its usefulness or usability.
I've got nothing against it. it's a fun little hobby app, but yeah, I've got to agree with the commenter above this is FAR from any standard definition of a "beautiful" app.
I'm excited about this not because I want to use it, but because it is a great example of an Elixir app. I'm in the process of learning Elixir, and it was cool to see someone else's code and be able to make sense of most of it. Thanks for posting this!
I don't know Elixir, but it does some questionable things. For instance, it appears to read and process the entire ascii_chars.txt file for each character in the output. It's not a big file, but it wouldn't be difficult to read it once.
Ya know, I was just thinking about doing something like this just a couple of days ago, but instead I wrote a python script to get the weather from forecast.io api, then brought that into my tmux status bar.
I'm sorry if this comes across as negative, but this is an example of using the wrong tool for the job, IMO.
I love Erlang and Elixir because BEAM gives me easy concurrency, metaprogramming and best of all, fault tolerance via supervisors. For a service that I need to stay alive, this is great. For a simple command line utility, I'd lean more toward a compiled language like Go, Haskell, Common Lisp, etc.
66 comments
[ 2.1 ms ] story [ 147 ms ] thread1) 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.
As far as I can tell, the Go environment is simply being used as a cheap installer, is that correct?
Also, you left off GOROOT from your Go environment :)
You may have read it that way but the question was explicitly referring to "working Go environment"
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.
I'd love it if this had been packaged in a way similar to Python or Node tools, where installation is as simple as 'install Python and pip; pip install my-program', and more-experienced users (or those who want source) can clone the git repo.
And FYI, Go is in quite a few distro repos so you might be able to just:
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.
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 ..
I find my wee-chat with 256 color urxvt with Source Code Pro font in Light Solarized to be the best looking IRC client ever :)
http://fungi.yuggoth.org/weather/
Pretty cool to track the temperature with your own home temperature.
Put this in a function. Done.
Gist here since copying and pasting above didn't work. https://gist.github.com/zaargy/384889cb44960e8559d5
Wouldn't call it beautiful - the ascii art is really distracting.
https://gist.github.com/jhwhite/2df093eff1f9bab74144
Btw, Thanks for your kind words!
I love Erlang and Elixir because BEAM gives me easy concurrency, metaprogramming and best of all, fault tolerance via supervisors. For a service that I need to stay alive, this is great. For a simple command line utility, I'd lean more toward a compiled language like Go, Haskell, Common Lisp, etc.