1,665 karma · joined August 6, 2011
There are obviously lots of additional little features (emoticons, inline images, etc) -- but at least with Slack, you can setup an IRC connector and just use your plain old IRC client.
There are areas where taxi service is so spotty as to be scary, were simply getting a cab is a huge pain (IE: called and ordered) and flagging one down is a non-starter. Even after calling in a cab, they often end up being no-shows (get a better fare en-route, etc)... it is scary when you can't get dependable public transit home from a location (stuck alone, outside, waiting for sometimes hours).
Uber started and initially flourished in areas were taxi service was insanely poor due to bad regulation and/or corruption. Uber was basically a response to the godawful taxi situation in SF.
I know I feel far more comfortable when the people I care about are able to get an Uber/Lyft/(similar) service.
My point was implicit, exceptional simple interfaces are sorta magic. They are effortless, and because they are implicit, there is no harm in creating a 1 function interface (or 10 of them). Because your caller is never going to have to do an ... Implements ThingA, ThingB, ThingC, ThingD, ThingE, Thi... it implicitly supports an interface if it fulfills the signature.
So your interfaces end up being tiny (just what you need) and pervasive. This means the way your system ends up working tends to be far more aligned along interfaces than anything else.
When I speak of composition (in this case the composition of functions) I am speaking of the ability to use functions together rather freely and with little effort. This is a bit hard to explain, but it feels a bit like a modern shell, you can wire together lots of commands (functions), from lots of places that have no awareness of each other with the pipe | operator. In Go, simple, minimalistic interfaces act as the glue and let you compose lots of diverse functions together exceptionally quickly.
I have used interfaces (or equivalent concepts) in dozens of languages and they always felt like far more of a chore, explicitly using X interface or Y interface, ugly complex declarative specs, etc. Go just makes it painless.
io.Copy(dst io.Writer, src io.Reader)
It reads data from reader and writes to writer... simple. Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader). The first way you will probably use it will be to copy between some stream and a file without having to eat up all the memory to store the buffer (not using ioutil.ReadAll for example)... but then you realize you can use a gzip compressor on the writer side, or a network socket, or your own code... and io.Copy works with anything that fulfills its interface.
As you build out a complex application, you start by creating your own functions that take advantage of existing interfaces foo.OCR(dst io.Writer, src img.Image). After that you start building out your own interfaces... like a MultiImage interface that has ImageCount and ReadImage methods that returns the count of images and binary data... but then you realize the images could be big, so you make the ReadImage method return an io.Reader... and now you have gone full circle and are using io.Copy to copy imageX from a stack of images to return to your OCR function that will output the data to an io.Writer which you made actually a gzip writer because text compresses well.
Beyond composition -- obviously, the concurrency and messaging is nice and when you need it vital. The other thing that will help make Go "click" is being very "data oriented" in your design... be vicious and minimal: http://youtu.be/rX0ItVEVjHc (great talk on data oriented design) and be absolutely pragmatic, focus on getting shit done, always...
Motorcycles on the other hand are generally not commuter vehicles, and riders tend to be self-selected for high risk. From people obsessed with speed, to motorcycle gangs who were no gear, to the weekend rider who has very little experience... It even applies to route selection, the trip to the store is well understood, but if you want to have a nice ride on the weekend, you will probably go far off your normal path. Different vehicle type, less miles logged, unfamiliar territory and often inappropriate gear do lead a high risk of injury.
Riding on a motorcycle is risky business, but so is riding a pedal bike in a city. It can be done practically and reasonably, I even used it as my primary form of travel for a little over a year... but it requires proper gear, a full understanding of the bike (and your place on the road), how avoiding an accident differs on a bike from a car.
It will never be as safe as a car, but in the hands of a conscientious intelligent rider, it isn't the death trap it is often saddled with... it is a calculated risk, like many others people take...
It has a level of flux that is astonishing (even compared to other pre-1.0 languages)... now, it could be argued that this is how a pre-1.0 should be, but it makes it very hard to build any serious project around it (note: a few companies have).
I am no stranger to pre-1.0 languages, I have worked with lots of them, but none have been as frustrating (or interesting) as Rust... the question as to will Rust grow into a production language or an academic toy still remains an open one in my book.
Reserving judgement until 1.0 is out.
I like that fact that a lot of the tooling/editor support is not picking a winner nor demanding an IDE. Tools like errcheck, goimports, gorename (announced today), oracle, gocode, godef, godoc, gofmt, golint, gotags, ... (on and on) ... all can be leverage by IDEs, emacs, sublime, vim and others equally... or just used from a console or in your own stacks.
For awfulness: 5/5
Nice to see another boon to the community come from Fred.
The meta-programming on the other hand may well be a huge draw to Erlang shops.
I spent about 18 months on an email client project (was already 3 years in when I joined the team). I can tell you email is insane... so much more broken than you would expect (on all sides).
There is a reason many clients do "gmail" instead of "email". "Email" is a nasty barely functional ball of duct tape greased with WD-40 in the places it needs to go fast -- the fact that it works at all is breathtaking and only explained by the fact that it is one of the "killer features" of the internet.
The number of broken clients and servers is shocking and breathtaking. So you have to accept and expect bad data from everywhere. From the server directly, violating the imap spec, and in the body of the message violating all sanity. Yet, your users will see any failure as "this email client sucks" because the OTHER older email clients have already seen this idiocy and custom coded around it. Email clients end up being giant laundry lists of "if <stupid server> (act way 1)", "if created with <stupid client> (render 'right' way 2)"...
The reason new email clients are relatively slow to be created, and even fewer take off, is they are forced to deal with an insane clusterfuck of standards and corner cases to get to that 80% good enough mark -- or simply build out to one service at a time (we support gmail, hotmail and yahoo... etc).
There are 20+ RFCs you need to deal with the cover the spectrum of "basic" email with calendaring across a number of servers. That is just the "good" standard parts. On top of that you have the hundreds of server oddities that you need to handle else your email client will fail to get email off broken server X. Add to that the hundreds of rendering special cases you need to be aware of (ohh, this game from old outlook, so X means Y).
After you do all that, you have to deal with spam (both how servers tell you about it, how you show it, how you maintain it, etc) and an entire new set of oddities (very similar but simpler) for sending mail.
FastMail has an idea floating around that appears less terrible: http://jmap.io/ -- but I am blissfully out of that industry and simply don't care anymore.
EDIT: For the record, I agree with the article, email will be around for a long time, it is the "point of record" -- many of the "email killers" require your email address to sign up... so...
I love the idea of mosh, but I find the implementation to be lacking... or I am doing it wrong. :)