Because when you need to get the page built and back to the user in 10ms, you control path through the program must be explicit and direct, both for the normal control flow, and the error path

And because the alternative to single-threading is multi-threading, and that sounds like a great abstraction until you realize how much time is lost acquiring and releasing locks, and performing context switches. And you see your code complexity balloon because you have to deal with all the cross-thread synchronization. And it's hard to test.

The alternative to single-threading is a system which can interrupt the current page build with the _next_ page build (multithreading!) and that almost always makes things worse.

Node.js responds to server overload by rejecting page requests because it's busy - something the outer load balancer can deal with in milliseconds. (You have a load balancer, right?) Multithreaded programs respond to overloads by slowing down, running out of stack space and crashing. If you're running a real-world web app with thousands of users, one of those is worse.

As pointed out, Promises are the primary solution to Node's "callback hell". People like to hate on the explicit value/error return separation, but that's merely a convention used by the top-level HTTP components, not actually baked into the language. It makes something explicit that is usually implicit.

The thing is, if you language has Exceptions and try/catch then you already have an implicit equivalent of the success/fail control split, and anyone trying to properly handle exceptions caused by their exceptions finds themselves merely in the circle of hell next door.

I've coded in node.js for a couple of years now, written some semi-big pieces of software to do real-time message passing/transaction processing stuff. It was fine. It's better than PHP, which I moved from. It's better than writing cgi-bin programs in C++, which is how I started. On of the big reasons to use node.js is it nicely integrates alternative protocols like WebSockets, RTC, AMPQ, so you can roll up a "web server plus other protocol" system that gets a lot of jobs done you just can't accomplish with PHP/Apache.

People love to hate on Javascript because they don't like admitting the language wars are over, and Javascript won. When you can walk into a room and ask "How many people have a compiler on them _right now_." and people answer "I've got at least two!" Try that with any other language. Compilers shipped, lines written, active users... JS wins on all metrics. It's not the "best" language, but then, what is?

A last note... node.js works especially well in 'cluster' situations, because to be honest, your average node.js process isn't terribly reliable. Individual node.js programs will crash on a weekly basis, thanks to funny net errors. In a cluster that doesn't matter, and in fact you WANT your 'nodes' to fail-fast rather than hang waiting for a deadlock. 'forever' restarts the errant script in seconds, but in those seconds your load-balancer should be handing the task off to another node. It's a paradox that to get a reliable cluster, you want your individual parts to be quite twitchy and explody., which node.js is.

Yeah, I'm weird like that.

(Or are you challenging me to a game? If so, hand me my chicken gun!)

When I read the description, I thought "Ah, someone's trying to re-invent G-code". Then I read the article and realized, "No, someone's just _discovered_ g-code".

Well done. Only took them about 20 years. Not sure why the achievement merits an article. ("News Flash: BASIC exists!")

Doubly not sure why the article even rated a mention in /.

There's an old saying, "In theory, there's no difference between theory and practice. In practice, however, there is."

You can get really far with pure simulation, further if you write the simulation yourself (no better way to learn all the important variables than to implement them) but at some point you need to experience the messy reality, where stuff like tensile strength and friction live. Where you need oils and lubricants and vibration damping.

I build a lot of robots. I can see two from where I'm sitting, three if you count the laser galvo system. Some of my best are complete Borg creations.. mismatched pieces, wires hanging off, random scrounged parts... and they hurl themselves into the air with astonishing fury, because (with power to weight ratios being what they are) what you leave off is just as important as what you put on.

Now, I realize I'm in a privileged position, and I've been collecting robot pieces for a long time now (in a society which throws away useful components all the time) but I started small, by collecting broken things, taking them apart, and seeing if they could be repaired, or scrounged for parts. I have a "parts bin" of old broken radios and computers that saves me immense time and cost when I just need a 10uF cap, or a 100K resistor, or a bit of wire.

And remember, robots don't _have_ to be made from electric motors. How about hydraulics driven by boiling water with toaster wire? A miniature steam-engine doom tank? Moving fluid drops around with electric fields? I've seen remote-controlled planes powered by rubber bands.

Use what you have, because the engineering challenge is the same. Time and interest are your greatest resources.

After a while, you realize "The Robot" is an idea in your mind, and the physical version is just a shadow of that. Bits break and fall off the "real" one all the time, but like the Japanese Temple, you can replace or upgrade every part and yet still it's the "same robot" so long as you remain committed.

Incidentally, one of the best "robot simulation" systems I've seen is the game "RoboCraft". You build driving/flying/shooting vehicles from minecraft-like parts, and battle! The physics simulation is good enough to properly represent driving a half-exploded tank on it's remaining wheels, and teach you why redundancies are good.

I do "cloud development" all the time. I spin up servers with ansible so they have GIT, latest source, and my login keys, and I use Eclipse/SSH with the Remote System Explorer (RSE) extension to develop, and more ansible/GIT to save the changes back to the repo and deploy to the rest of the cloud.

I've tried docker and various other deploy systems, but most of the time what you want is a carefully versioned Debian stack install with you source slapped on top, and there's nothing hard about that once you've got your workflow sorted.

Oh, you mean, is there a way of developing totally in a browser without local software installs to a professional standard and level of tooling?

Um, no. Not yet. Which is a shame. There are a few specific tools, (I've written a few) but not a whole "IDE".

(Unless as one wag suggested you count the cPanel text editor, which you really shouldn't. It tops out after about 1000 lines, for a start :-)

I've actually attempted such a thing a few times, and the main problem is that putting a full GNU compiler on the internet is a great way to have your box burned to the ground through makefile exploits. Compilers don't like being put in sandboxes either.

I'll bet I can sum up the "Three Possibilities" without even reading the article.

1. Ion Thrusters - work nicely, in widespread use. Lovely tech. And if they have twin engines, you can technically call them TIE fighters.

2. EmDrive (or the "Microwave Thruster") breaks a few of our preconceptions, but seems to work. Will probably get installed all over satellites to keep them on station, and advanced ones might slowly push probes around the system, once the arguments about how they work are over with.

3. Alcubierre Drive (the famous "warp drive") which assumes that since spacetime is bendable, then one day we might get the tech to shrink it in front of us, while expanding behind, and we'll 'ride the wave' at >C. Current lab experiments use big capacitor arrays to move lots of energy around quickly and see if perhaps the metric tensor goes wibbly more easily than we expected. So far, No.

Sadly, this omits a couple of novel and really quite achievable techs, like VASMIR, solar sails, and 'magnetobubble' drives.

Howd' I do?

Under the laws as stated, gluing a paper plane to your iPhone and throwing it out the window would technically make you a criminal. It says "radio controlled device over 250g", it doesn't say it has to be aerodynamic, have rotors or working control surfaces. If you make it vibrate while plummeting to it's doom, it's technically a bad glider.

That's the problem, the laws are so vaguely worded they might apply to all kinds of products, toys, or things you make, and they're federal laws backed by federal police. That's not a situation you want.

"There is little to complain about" my ass. At least when the Internet was being demonized, playing in my local park was still allowed. I thought getting out into the fresh air was supposed to be healthy!

Sadly, this is the wisest thing I've read so far today.

I would say "I don't want to live on this planet anymore", except that a David Windestadl - style helium-assisted "drone" launch was probably my best chance to make orbit, and I doubt I'll be able to get that shit registered now.

"On your licence application, you wrote you intend to 'slip the surly bonds of earth and punch the face of god'. I'm afraid we don't have a category for that."

You're right. There has never been a manned/RC aircraft accident. Not in the 50 years of the hobby. When planes fall out of the sky, it's either because the pilot screws up and flies into a hill, or air traffic control messes up and crashes them into each other.

There have been a few reported "near misses" with things that might have been a "drone", or possibly a bird, or another plane, or perhaps Superman.

No-one is entirely sure, possibly because trying to reliably spot even the biggest feature-film-grade octocopter out the window at a relative speed of around 400km/h is a dicey proposition.

"Understandable" yes, but alas we're looking for "reasonable".

A five pound turkey is NOT "soft compared to the materials of which a drone is made", unless you think bone and muscle is softer than styrofoam and epoxy. Yes, there are small motor components made from aluminium and ceramics, similar to how birds have skulls made from hard bone, but you can cut the largest RC component (the lithium battery) with a butter knife, and carbon fibre tends to shatter.

The energy of a collision is proportional to mv^2. The 'softness' of the mass doesn't really matter, in fact it can aid in energy transfer. A five pound turkey packs a lot more energy than your average quadcopter, and yet you pilots seems happy to recklessly risk your life and limb based on the movements of migratory birds.

At least with RC pilots, you have an ability to agree on transponder frequencies and such, so we can stay out of your way. If you cared to.

You can keep making us walk out front of our vehicles waving a red flag, but if you keep pushing the "we can't possibly share the sky with _those_ people!" line, then we might believe you, and you might just find yourself in the same position as the horseriders who lost access to the roads once cars were too useful to ignore.

OK, so this isn't just an excuse to post "Beowulf Cluster!" on /. one last time, but it probably sounds like it... :-)

What you really want to do is start using cloud services like DigitalOcean or (if you must) AWS. In this day and age you can pull more computing power out of the damn _air_ than currently exists in your building. This isn't "going OSS", this is a space where open source tools like Linux, GIT, Ansible, cassandra and other are simple necessities because nothing else can do the job. Licences are impossible to keep track of in cluster environments, so the only choice is to go GNU.

But cluster computers are just 'virtualizations' of real hardware, and one of the fastest ways to understand something is to build one. A little one. So, you want a little pile of dozens of identical linux machines, cheap enough to write off on the stationary budget as "training manuals", and that can be repurposed as fast as sticking a cartridge in a nintendo. You want a Raspberry Pi, Banana Pi, pick your flavor. Everybody gets one (thanks, spidey!) and that creates common ground. If you're lucky, three months in, everyone will be swapping their favorite games on SD cards. That's how you know you've won.

You show how lots of little computers can function as one large computer using modern tools, and you show how half of it can be sitting on your desk, and the rest can be on another desk, or in the cloud. Hardware is disposable.. it's the software that's immortal.

Once people have some familiarity with a new tool, and been given an opportunity to use it stupidly in private, then the inevitable next stage is that people will want to use their new hammer to hit every nail-like thing in the vicinity, and that's when you need a little careful enthusiasm management. Everything that breaks down or goes dodgy will get replaced with the tools that everyone knows best, the one they've been most recently learning.

You're in the UK. Learn the history of the Acorn BBC Microcomputer... and how it educated a generation... you may have taken it for granted, but it's a great example of what you're trying to do.

Autonomy, mastery, and purpose. That's what people want. Provide those, and the tools to get the job done, and mostly it's a matter of keeping out of their way.

crap.. typo. "Truck" drivers, not "Trick" drivers.

eg: In my own city (Brisbane) the clear winner for things killing cyclists is trick drivers 'side swiping' or lane-changing on top of them along major roads or intersections, in the CBD, not the suburbs. By a margin measured in ratios close to 3:1. Not cars. Not buses. Not other cyclists.

Basically, if you're cycling along a main road in plain view and full daylight, and a big-ass truck rolls up beside you in the next lane... Danger! Danger Will Robinson!

I'm sure the anecdotes are fascinating, but hard data is always more useful. Slightly over a year ago I did a quick analysis of the accident patterns regarding bikes in my own state, Queensland Australia, using the data that the Transport dept. released.

http://www.unorthodox.com.au/map/what_hits_bikes/

The data shows that there are particular 'hotspots' where bike accidents occur, usually were flows of heavy vehicles and multiple (complex) lanes meet. That suggests that we don't need bike lanes everywhere, but we do need clear bikeways through heavy traffic spots. Incidents are _not_ correlated with population density, but with heavy traffic density. There are also odd hotspots around places like public parks, though they seem to be of the more low-level parking-style incidents.

The original data included all road accidents, but was winnowed to just the bike events. The incident reports don't reveal individual details like which vehicle's driver was injured, but in the fatality incidents between, eg: a pushbike and a road-train, I'm pretty sure it wasn't the three-ton truck driver who came off worse for wear.