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 :(

Agreed. In particular, I found the "reference value" approach that Go uses for time parsing incredibly quirky, but ultimately intuitive and unambiguous.

http://golang.org/pkg/time/#Parse

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>.

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

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"

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)

Note I said "as a matter of course". I agree it's useful in certain very limited circumstances, like parsing. But certainly not database work, unless you have a very different idea of what that entails than I do. Link to code?

No, you don't. You should never be using recover as a matter of course.

You seem really hung-up on this point. Can you link to some code that illustrates your concerns?

If you're recovering from panics, in general, you're doing something wrong.

    > it's incredibly hard to find a good engineer that knows 
    > his stuff. They generally have PhDs and years of 
    > training in math and whatever particular field they work 
    > on. If you get one that is actually doing novel 
    > algorithm development, each one is a golden goose that 
    > will bring in revenue for the company for years to come.

    > Rust tasks have the same large fixed-size stack as OS 
    > threads. A fine-grained concurrency model like a task 
    > graph would be build on top of them.

    > CSP and channels are meant for getting real (cpu 
    > intensive) work done. You don't just use threads (or 
    > greenthreads) "because concurrency".

While it's not idiomatic in Go to use a channel/goroutine combo as an iterator, for example -- that's too low-level -- it's absolutely idiomatic to use one for other types of higher-order control flow, managing state machine transitions, doing a scatter/gather, and so on.

Those are both sub-problems.

    > Paste and match style (incredibly useful) is "alt-shift-
    > command-v" i.e. four keys . . . Four is too many. Three 
    > is too many for such an important function.

    > I don't take personal calls at my desk. My phone is on 
    > silent at all times when at the office. If I need to 
    > make a call, I step out.
    >
    > Even my desk phone is on silent. It sounds a single beep 
    > when the phone rings.

    > I would like others to do the same.

    > there seems to be quite a few people suggesting that go 
    > is the correct choice for every task.

    > Go's zoo of builtin data structures is really, really   
    > poor compared to Java.

    > And I believe I have explained what doesn't make sense 
    > to me.

A mix of lint-y and style problems, and over-use of named returned parameters.

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L4...

-- comment block should start with Dictionary.

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L5...

-- comment should precede the declaration.

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L6... and others

-- spurious newlines

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L7...

-- needless named return parameters

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L1...

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L1...

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L2...

(many others)

-- prefer early return or continue over if/else

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L1...

-- more boilerplate due to the needless decision to use named return params

Frustratingly non-idiomatic Go code :(

I'm not sure why you classify "a proper exception mechanism" as an "elephant in the room". Go will never have exceptions for control flow, and it's one of the best properties of the language.