redbad's comments

redbad | 12 years ago | on: Ask HN: I am a good developer but have a serious gaming addiction

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

redbad | 12 years ago | on: Why I Won't Switch To Go from Node.js

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

redbad | 12 years ago | on: Gay Firefox developers boycott Mozilla to protest CEO hire

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 years ago | on: Did Malaysian Airlines 370 disappear using SIA68/SQ68 (another 777)?

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 years ago | on: Sane Concurrency with Go

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 years ago | on: It's Go Time On Linux

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 years ago | on: Redis 2.8.7 is out

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 years ago | on: Meetup fighting against DDOS extortion

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

redbad | 12 years ago | on: How pCell works and why its a bigger deal than anyone realizes

    > Humans use <todo>.

Indeed.

redbad | 12 years ago | on: Atom

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

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

redbad | 12 years ago | on: Atom

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 years ago | on: Atom

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

redbad | 12 years ago | on: Show HN: link shortening API in Go

    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 years ago | on: Toward Go 1.3

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 years ago | on: Toward Go 1.3

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 years ago | on: Toward Go 1.3

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 years ago | on: Toward Go 1.3

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 years ago | on: Toward Go 1.3

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

redbad | 12 years ago | on: Julia, the One Programming Language to Rule Them All

    > 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 | 12 years ago | on: Chinese Whispers in Rust

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