redbad · HackerTrans

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

redbad

12년 전discuss

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.

redbad

12년 전discuss

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.

redbad

12년 전discuss

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

redbad

12년 전discuss

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

redbad

12년 전discuss

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.

redbad

12년 전discuss

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

redbad

12년 전discuss

    > Humans use <todo>.

Indeed.

redbad

12년 전discuss

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

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

redbad

12년 전discuss

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.

redbad

12년 전discuss

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

redbad

12년 전discuss

    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.

redbad

12년 전discuss

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.

redbad

12년 전discuss

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.

redbad

12년 전discuss

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?

redbad

12년 전discuss

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?

redbad

12년 전discuss

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

redbad

12년 전discuss

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

Like ritchiea, I admit I don't have a huge breadth of experience, but I've worked with enough PhDs to say with confidence that, more often than not, they represent a net negative contribution to an engineering team. Novel algorithms aren't useful if they can't run in production, and the PhD's I've known, with one or two exceptions, lacked both the ability and desire to produce production-quality code. I grew to deeply resent those "engineers" who would read papers for half the day, make buggy commits to prototype repos that never got released, and refuse requests from both peers and managers alike to contribute to the team's extant backlogs.

redbad

13년 전discuss

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

In the absence of other context (I don't really know much about Rust) I would then argue that Rust tasks miss the point of CSP.

comments