Ryan Dahl steps down
groups.google.com
groups.google.com
Node.js is in great hands with Isaac. Unlike many other web/network platforms node doesn't go around gobbling up everything into core. The community behind node is stronger and contributes more than I've seen before. Focusing on that third party module system experience is a good move to further grow the community, one that Isaac has been heading for a while.
While many people will see the BDFL stepping down from a project as a bad sign, I think its the opposite. It has a dedicated and invested company behind it (Joyent), it's core doesn't try to do too much, it has legs of its own strong enough and it's community fault tolerant enough to grow quickly without him.
Ryan spawned a project that grew a community that in the long run isn't reliant on him, a rare achievement of platform/language creators.
And what's the core missing, would you say? Personally, I thought the cluster stuff was already getting heavy.
Yes. And you're right, but then it's not often that much better than other languages. Personally I'd rather they get the core language finished first (though their concept of "finished" and mine seem to differ).
> And what's the core missing, would you say? Personally, I thought the cluster stuff was already getting heavy.
There's no way to lock a file (making file writes completely fragile). There's no way to seek() in a file. There's no way to open a file with O_EXCL set (meaning lockless file writing is impossible). There's no temp file functionality in core, and without O_EXCL the solutions available for this on npm are utterly broken. There's still major bugs in the Crypto routines (they take Strings instead of Buffers in various places)... Honestly I could go on.
Most of the rest of what you describe is APIs that need to be polished and refined a bit. The boundaries are well defined at this point, though. We probably won't add another builtin module at this point, or dramatically expand what any of them can do. (I don't consider seek() dramatic, it's just tricky to get right given JavaScript's annoying Number problems.)
That's great to know. Obviously I'm just following the docs.
> Most of the rest of what you describe is APIs that need to be polished and refined a bit
My concern is merely that there have been a number of statements put out saying "we won't be adding anything more to the API", and that we are basically almost at 1.0, at which point there won't ever be anything added to the core API. Lack of flock() is huge (you can't write to an existing file safely without it - and Node developers are doing that all the time, including your own NPM). Lack of an ability to create temporary files safely seems a fundamental weakness - especially when so many Node apps are dealing with file uploads - that's a disaster waiting to happen. We are going to be dealing with Node.js security bugs because of these issues for a VERY long time.
flock() is not trivial to do in a portable way. For a unix-only flock(), check out the fs-ext addon. Same for mktemp.
I wouldn't be opposed to either being in core if it could be done in a clean way, but this is just adding another knob that can be done with an addon easily enough. If you care more about having flock() than about writing portable programs, then that's what the fs-ext addon is for.
> We are going to be dealing with Node.js security bugs because of these issues for a VERY long time.
Of course we'll be "dealing with Node.js security bugs for a VERY long time", because we'll be using Node.js for a very long time. Software is buggy, and many bugs are security hazards. We'll be dealing with "Unix security bugs" and "C security bugs" and "Java security bugs" forever as well.
Please do not make vague suggestions about security issues. Either you've found an issue, and should be submitting it, or you haven't, and are just spreading fud.
Perl, Python and Ruby manage it.
> For a unix-only flock(), check out the fs-ext addon
Which I wrote.
> Of course we'll be "dealing with Node.js security bugs for a VERY long time", because we'll be using Node.js for a very long time.
That's not quite what I meant - I mean that people right now are writing temp files in LOTS of Node.js applications in an insecure way. It's good that O_EXCL is available, I'll try and submit a patch to node-temp, but really temp file creation should be in core (amongst other things).
This isn't a vague suggestion. There are COUNTLESS security bugs created every day by insecure temp file creation. Let's see, from npm these packages have security bugs because they rely on the insecure node-temp: ShipItJS assetgraph-builder confy filerepl gracie joose js-loader muffin nerve redisfs.
smf(5) can get you part of the way there, but not if you're (say) writing some system bits that you need to deploy on platforms in addition to SunOS. Plus, if you can avoid depending on any not-just-pure-JS modules then you can deploy one tree onto all of your platforms without additional build steps, C++ compile/ABI issues, etc.
The fact that they're shifting focus isn't a big concern. I'd at least wait until Isaac comes out and says what the future roadmap is before criticizing it.
What "finished" means in this context is that we've established which problems we're going to solve, and the solutions to those are well-understood. There aren't new problems that node-core is setting out to address by making changes to the binary itself.
The new hard things to tackle are above the core layer - CI, userland module documentation and discoverability, binary deployments, etc. There's quite a bit of polish and refinement to be done at the lower level, but the paths are clear at this point, as far as that goes.
EDIT: edited a bit in the form to make my thought more clear.
I recently had the pleasure of checking out the NodeUp podcasts. A large portion of the first episode is dedicated to enforcing the notion that Node is a new language, and that it will take decades to catch up to the maturity that Python and Perl provide as platforms.
Opening up a subprocess, or having an `os` module which works in Windows, for example, all seemed like daunting tasks that took other languages decades to perfect.
While I'm sure Node can catch up quickly, partly because Javascript is fast to write, and partly because of the trailblazing that other languages have already done (among other reasons, I'm sure), I can't help but think that the loss of the original author's momentum behind the project will cause Node to suffer.
Python has had Guido as the BDFL for over 20 years. Larry Wall is firmly entrenched in the church of Perl. Having one voice shepherding the direction of the language has had tremendous influence on both languages. I can't help but think that node.js is in a similar situation.
Ryan will be a part of node forever. He's not gone. He just somehow talked me into doing a lot more work :)
Not really. Node.js isn't a language that needs direction; ECMAScript is a separate standard with its own drivers. Node isn't even an implementation of a language, and V8 has its own community directing it.
Node is a small core with pretty simple principles. The rest (the most important part, I'd argue) is a thriving third-party community, and that's something the loss of any single developer won't change.
I'd take require('child_process') over python's subprocess any day.
At his introduction to the company at Kno, all he said was: "My name is Isaac. I do javascript."
positive: Without the originator in place perhaps a more formal product infrastructure can be put in place by Joyent. I'm thinking in particular about a structure for the documentation of primary third party modules like Connect and Express. At present the readme's and examples on Git, Sencha, and ExpressJs are all done by the original module developers. They're good but like most documentation done by the original developers make too many assumptions about what readers know. I don't mean to be too critical but if users are going to Stackoverflow for answers then there is a problem.
I dunno, a lot of big players are using node in production, and the back-compat's getting reasonable. Why does the number when you type -v matter?
> Without the originator in place perhaps a more formal product infrastructure can be put in place by Joyent. I'm thinking in particular about a structure for the documentation of primary third party modules...
I think that's the opposite of what Node needs. All of these third party modules came about precisely because there's no blockers or infrastructure to getting started with extending Node. The documentation for some of these modules could definitely be better, but I don't think having a central authority imposing upon the community is a good solution.
> I don't mean to be too critical but if users are going to Stackoverflow for answers then there is a problem.
The reason SO is so huge is precisely because users of pretty much anything will always have problems. Node is not, and never will be, an exception.
I don't get this. Why would a core team be responsible for the documentation of 3rd party modules.
Node has some serious documentation issues but I'm not sure how Ryan or Joyent is responsible for anything outside of anything under nodejs.org/docs
Best of luck to him, he's sure gonna need it!
This is a google groups quirk.
If you are logged into a google account it will prompt you. If you sign out of your google accounts then you can read it without being logged in.
If this situation were anything like DHH stepping down there would be a lot more swearing involved.
I didn't say it should be closed-source. Paid doesn't preclude open source.
Edit: I don't know of too many prominent JavaScript programmers who prefer not to use semicolons. http://dailyjs.com/2012/01/12/style/
Note: I actually rather like Matador. I just find this particular style--high density, no semicolons--much harder on my eyes. I'm sure many others can read it better than I can, however.
Personally, I find using comma-first and omitting semicolons except where required for ASI reduces the amount of noise down the right-hand side of the code and the amount of scanning I have to do there (for variable definition, object literals and nested calls in particular).
Commas first cause more noise on the left side; they distract me because I'm used to reading English and I'm used to reading code that's written in English based programming languages where people generally agree that punctuation belongs on the right side.
Honestly though, I care more about comments than coding style, something that the Joyent guys don't seem too fond of despite the complexity of the Node.js code. I just don't get it.
IMO, the whitespace isn't so much an issue as the chained calls. Once you exceed about 5-8 lines of method chaining where your eyes now have some difficulty lining up the indentation (although Sublime really helps in this regard), the lack of visible line terminators can be somewhat obnoxious to someone who comes from a background of C/C-inspired languages.
I agree with Isaac's assertions that it's important to understand line terminating, and I also agree with his other statements regarding pants. I prefer to wear pants unless I'm hanging out in my Python room. It's just easier on my eyes.
Congrats all around