redbad

You should probably go back to your "well payed job".

"I really like JavaScript" might be a compelling personal narrative, but it makes a pretty uninteresting submission to Hacker News :(

1. There is a difference between voting for something and funding it.

2. There is a difference between being employed by a company and being its CEO.

3. These differences are significant.

This is almost exactly how a plot device in Neal Stephenson's REAMDE plays out. In almost exactly the same part of the world. Bizarre.

The code is super awkward, I'm pretty sure buggy, and unfortunately illustrates that the author has only a superficial understanding of Go idioms :(

It seems that antirez believes he's allowing Redis to approach AP and/or CP semantics by providing primitives that users can compose in ad-hoc ways according to their requirements.

Unfortunately, that's not a valid methodology to achieve availability or (especially) consistency.

The NSA has nothing to do with the parent's proposal. Your entire reply is a non-sequitur.

    > Humans use <todo>.

Indeed.

    > Are you suggesting that it isn't in Emacs?

Yes, of course. Emacs is obviously and inarguably not immediately intuitive.

There is no reason why "editing plain text" should be anything other than immediately intuitive. Advanced, time-saving features, like multi-cursors or regexp-based find-and-replace, can and should be progressively revealed through normal use of the software.

This ludditic reverence for user-hostile text editors is one of the more perplexing and frustrating things about our industry.

Text editors appear to be approaching a design ideal. At least, for the ways we currently use them.

    import (
    	"./utils"

This is what's known as a relative import, and it's very bad. You want "github.com/johnnye/short/utils", or (better yet) put your base62 stuff in package main, since it's just one function.

Guarding your library boundary with a recover doesn't absolve your library internals from being nonidiomatic by using panics. (That the stdlib uses panic/recover in a few specific places does not make it broadly idiomatic.)

Without seeing specific code I can't say for sure, but it's very unlikely that any database interaction code is best modeled with panic/recover for error handling. I'm very curious to see the source, at this point.

defer and recover have nothing to do with each other, except that in the few circumstances where it's appropriate to use recover, you often do it within a defer block.

    > are you saying that you don't need to handle exceptions 
    > (whether using defer or recover)

Go doesn't have exceptions. You don't need to handle (i.e. explicitly deal with) panics via recover. If you do, especially if you're not making the panics yourself in e.g. a parsing package, that's a bad code smell and you're probably doing something wrong.