bluefish

Still I believe you are correct, by having a publicly stated policy about their planned inaction when served a secret warranty is effectively the same as making a public announcement. Ballsy, but kudos to them for making a statement about their privacy beliefs.

I'm not an iPhone developer, nor have I ever developed anything for the Mac platform specifically. Based on the stories I've read online it does sound like Apple isn't handling their iPhone app store well, but I do take issue with the part of your comment I've quoted.

I'd like some examples about why you would expect to be treated poorly (or as you put it abused) by Apple. Is it only based on their track record with app developers? If so perhaps it's a problem rooted in the iPhone app process itself and not systemic to the whole company, as you imply. I would need more examples of Apple's abusive policies to understand your statement, for now though I'm not going to write off Apple as horrible corporation because some app developers cry foul (to which, according to the blogger's own admission, Apple attempts to promptly respond to and rectify).

For most things it feels pretty fast. A simple timer output showed less than 1, 1, 2 or 3 milliseconds for most operations including File I/O.

Importing files via node's 'import' and 'require' functions is, for lack of a better adjective, Erlang-ish. You must declare in the file you are importing which functions you would like to expose by making them members of a special object called 'exports'. For example if you have a factorial function in a file called factorial.js you must declare it as 'exports.factorial = function() { ... }'. This seems 1) strange, 2) not very Javascripty and 3) like it can severely limit the reuse of server-side js libs with other server-side and non-server-side js implementations. This was the biggest let down for me, since my dream is to be able to write libs that work on both the client and the server.

There was a weird bug I found when writing to a file. If I created a loop like so:

var times = []; for (var i=0,j=1000; i<j; i++) { var t1 = Date.now(); var file = new node.fs.File(); file.open('test.log', 'a+'); file.write(i + ' ' + new Date() + ' Hello World!\n'); file.close(); times.push(Date.now() - t1); }

'file' would contain only 250 new lines of text, while the array times would show it's length to be 1000. I'm assuming this is some kind of bug, as the number of new lines added to the file seems fixed at 250. Setting the loop to 249 produced a times array with 249 items and a file with 249 new lines. Setting the loop to 251 produced a times array with 251 items and a file with 250 new lines. My C++ is very poor, but my guess is that each event has a queue which is hard coded at 250 and my loop over flowed the queue. This could also be a potentially huge issue with writing libraries around node.

It would be nice to see those two issues resolved or explained in better detail, particularly the import / export functionality.

I'm not familiar with how other libraries might be implemented, like mysql, sqlite, etc so I guess I'm wondering if this implementation will eventually support external libraries. Also wondering how node compares to, say, narwhal:

http://github.com/tlrobinson/narwhal/commits/master

which seems to be more of a std lib than a full runtime. Also, can narwhal be imported by node?

All in all, really exciting. I've been wanting js on the server forever.

Perhaps what you meant was "Working on my startup." To which I would agree. If I could be doing anything right now it would be working on my own projects and working towards being able to sustain myself through the application of my own skills. Perhaps that's not what you meant, but heed my warning, startups are not a panacea for programmers.

I really like Python and have the exact opposite opinion as you. That is, to me, Rails is very like Ruby and Django is unlike anything else done in Python. Django has hindered me every time I've tried to use it. By comparison, Cherrypy, storm-orm, SQLAlchemey, Mako, etc are all pretty straight forward. Django is out in left field for me.

1) I assume my time is essentially priceless. If I've ever had complex finances, for example, I hire an accountant because it's not worth me trying to decode some obscure tax law (which commonly changes year to year btw) for several hours just for the satisfaction of knowing I've DIY'ed the situation and maybe saved a couple of $ in the long run, while quite possibly also having had made mistakes.

2) Speaking of mistakes, the second reason is that often times hiring someone else comes with some kind of guarantee or warranty. Hire an accountant and if your taxes aren't right you're liable to make up the error, but you're not going to jail for tax fraud. Hire an electrician and (usually) they'll stand by their work and come fix errors within a given amount of time.

Not saying I disagree with your statement, just offering a perspective on why $/hour doesn't always evaluate so clearly as a meaningful metric.