Turns out I recently wrote a dashboard client (quick hack in Ruby, soon converted to Go) for our status monitor app server (in Go, exposes only an API to get the results). The monitor is on Digital Ocean and the dashboard is on premises and runs on ArchLinux (on an old spare machine, soon a RPi because noise and thermal exhaust, and why wwe'll convert the client to Go, to lower overhead as much as possible), switches to vt8 on boot and does its thing straight into tty8. It can also be run locally, is responsive to resize, and triggers notifications via the bell (pcspkr on the dashboard machine, terminal bounce+tab icon on OS X Terminal.app) when something bad happens.
Learning about terminal escape sequences and capabilities (SIGWINCH, alternate screen, doing coloring non naively, clear part/all of line/screen) was quite fun and not that hard.
Going terminal/VT is incredibly interesting for us when building such tools because the setup is extremely simple, robust, secure, and portable.
This package will certainly allow us to go to the next level much more easily.
Are there other in-terminal applications that have browser-like presentation options like this? Specifically with padding/margin and a "responsive" view?
yaronn, I totally appreciate that. I like seeing projects based on blessed, and yours might be the first major library to do that. The drawille ascii art in blessed-contrib is awesome, and it's good because I think it belongs in a separate library. It might be too specific for blessed core. That being said, I definitely want to add a table widget to blessed eventually. It should be in there.
Well, you could go all out, grab https://github.com/chjj/term.js, plug that into termui using WebSockets or something, and it would most likely work:
On the other hand, you can easily code your own without too much hassle. https://github.com/rcarmo/raspi-cluster includes a minimalist Dashing clone with a Go backend and real-time updates.
Nice to see this project is progressing since it was last posted. I personally have a similar thing hacked together for some specific server monitoring stuff, would love to someday port all our analytics over to something like this.
I remember those days fondly.. my BBS was still running in 2012 (via telnet), been wanting to find time to get it back online again. Though, RIPScript is kind of a waste artifact at this point, text-mode art is still pretty cool, and seeing a bit of activity.
You can build awesome software projects using almost any toolset. C, or C++, or Ruby, or Go, or Java, or…
The question is – is the trade-off worth it? Lack of generics makes things more awkward – but it's also simpler, so maybe it's a net gain? Some people think it is, and some people think it's not. But it's a useful conversation to have.
Considering how many cool projects are being written in Go lately, it seems that a lot of people either don't mind the lack of generics or like the rest of Go enough to power through. I'm personally in the latter camp, though I can't say I've written anything remotely as cool as this.
From what I've seen though, most of these projects are executable applications, often with a small code base and written by at most a handful of people. I don't think this is the type of code that really benefits from generics.
As a Scala developer I heavily use generics, but generally only when writing libraries. Application code, code that becomes the final executable and isn't mean to be reused, is usually very light on generics and many other fancier aspects of the type system. Perhaps it goes without saying, but it's only when writing generic code do generics really become important.
To me, Go seems good for one-off projects like this. The code is straightforward and it's small enough that it's not a big deal to hand-write functions that could have been generic. But for large projects or for writing highly reusable code, Go seems really unfit for the job, and I think it's those kinds of projects people have in mind when they criticize Go for not having more powerful features like generics.
Every time I have to write a duplicate XYZServiceResponse instead of ServiceResponse<XYZ>, I don't think "Hey I can't do stuff", I think "I have to copy and paste the same code AGAIN."
Good pull, but are there really that many use cases in production code where you need to consume JSON that you don't have an expectation of what types of data are coming your way?
if you have a standard ServiceResponse wrapper with meta information and a 'response' field that is the actual contents of the response. Leads to FooServiceResponse, BarServiceResponse vs. if you just have a generic ServiceResponse<T>
Or maybe programming languages aren't like saws at all and your analogy is fundamentally compromised by this. They are tools, but they are there own tools. Good at what they are good at and people are apt to use what feels right. More power to them.
You're pretty hilarious. There's no SCIENCE here, there's religious fanaticism on both sides driven by anecdotes from thousands of amateurs. Where's the rigorous study that shows if Go or Haskell is better for building quality software?
These tools don't solve some mythical perfect "math" problem. They solve a "social" problem. We write software to help people. Wether a language has generics or not almost certainly not the most important factor that drives the success or failure of a project. But hey, I haven't done a rigorous study to back that up. At least I can admit that.
Is there something about generics I'm missing? Other than during discovery, when do you have input that you cannot anticipate its type and you are forced to modify it?
I think you're missing something about generics, yes. Firstly, often you don't know the type you're working with because you're writing a generic library, made to be used generically. Secondly, often you want to write some generic data structures or algorithms and parameterize them over multiple known types, and generics help you avoid repeating yourself but maintain strong static typing.
> How precious. I thought that the novelty of "my website is a terminal" had worn off by now, but oh well.
Gratuitous negativity violates HN's guidelines and is not welcome here. If you have criticisms to make, make them substantively. This is not a site for spewing bile.
It’s a personal website, not a landing page (and hosted on a platform that encourages experimenting). I’d argue that in this case not everything needs to be optimized for the new user’s sake.
Ugh, my bad. I don't even know why I thought it was a landing page to begin with. Still, the same argument applies: for a personal website by a non-celebrity (status), it's pointless indirection to have to (for newcomers) explicitly have to ask for how to access other sites, and accessing other sites is the whole point of the website (besides the "novelty"). Oh, that and changing the 'terminals' background colour, I guess.
Projects like this make me want to have an excuse to use them.