For anything not on the client-side, I would look into C-bindings via V8 (and of course Node which is just V8 + a small library basically). I love JavaScript and will defend it vigorously but number/math-intensive code is not something it's strong at yet. That's in the works but even when it's introduced we still have to wait for old versions of IE to die off (which is fortunately happening at a faster rate than it used to). Otherwise JS is peformance enough to be competitive with any other multipurpose language IMO but I do love having the C/C++ option for operation-intensive performance + JS handling higher level archite

But don't kid yourself. Skilled client-side engineers care A LOT about performance. There is a lot of craft that goes into manipulating the DOM well and I'd say any JS engineer that had to deal with IE6/7 or below knows a lot more about the value of work avoidance than your typical Java or C# dev at the median level who tend to put out awful performance on the back-end in spite of all the perf advantages that are supposedly available to them.

People from outside of JS get way too obsessed with its lack of a type system, IMO. The values a dynamically typed language trains you to take seriously (things like DRY and the value of encapsulation to avoid having too many hands on the same sets of data) very much transfer in value to statically typed languages as well, but with IDEs and "type safety" programmers seem to lack the incentive to learn them well, at least judging from the vast majority of server-side code that I've observed and debugged.

But yeah, if you need computation-intensive number-oriented code, JS blows for anything non-trivial. I won't deny that.

How computers work hasn't actually changed that much. I'm a JavaScript programmer. I find it valuable to have a clue about assembly language. It gives me a better idea of what sorts of things are more likely to be heavily optimized when dropped into these modern JIT's for instance.

But on the flip-side of that, yes, there are higher level concepts that weren't born of nothing. OOP got popular for all the crap-tacular C that's been written by all the old hands out there. Sadly, that resulted in the same types of people writing crap-tacular OOP and adding getters/setters a super-class and interface to absolutely everything (*facepalm).

The fact of the matter is, it's very easy to make that soporophic 70 grand a year with only the slightest clue as to what you're doing with an IDE and one language. There will always be people who confuse programming with any other job where after college, you can get away with barely learning anything new over the course of an entire year. Truly actively self-teaching programmers are rare and will become more so the more the barrier to entry is lowered for people who don't want to learn and are making a mostly-doomed career choice for themselves because they like the years of college to starting salary ratio.

Yeah and we're constantly making gross over-generalizations about people too.

I like giving it in hex. If they can figure that out, odds are good they care more about talent than age, regardless.

That's why my children will wear potato sacks until the growth spurts stop.

The guy worked at Apple in the '80s. Why on Earth would you want to leave that out? That has to impress more people than would be turned off by him being 50.

There's lots of reasons other than the H1B thing, all of them stupid.

* Tech d'jour. A lot of startups are actually under pressure to list all the latest greatest often fad technologies just to impress investors. This has been my biggest problem lately. I've got years of dedicated study to a core language that I can just stomp the competition with most of the time but oops... I don't have 3 years experience in that framework that came out 2 years ago that takes a few days to pick up.

* Lousy hiring strategy - It's kind of like what I used to observe on dating sites where people would list these absurd shopping lists of must-have requirements. The limits they put on eligible partners, or in the case of hiring, qualified employee hiring pools is absurd. Sure you might find the guy that has all of the things on your list but how freaking long does it take to pick up a newer or older version of something you already know. It's a misplaced focus on overly precise requirements over general quality of the candidate. Some people would rather have the mediocre guy with their exact bullet list than somebody smart enough to pick up near-anything you want quickly. Sadly, I met my wife by getting into a fight with her on Craigslist but this hasn't helped me out with any jobs yet.

* Incompetent leads running the show. We've all met them. They don't want to learn anything after college that they don't have to. Why they stayed in tech, I have no idea but they're out there and sometimes it's just easier to scoot them up to management where they still feel like they have to have their own tech limitations lowering the bar so they can understand what you're doing. Even if it's not really their job to be nosing around in the specifics.

* Lazy HR. Some people will always see it as a resume pile culling process, even when the skills they're looking for are rare or hard to come by in certain combinations. The more reasons they can get to toss somebody in the 'nope' pile, the fewer people they ultimately have to talk to/deal with.

* Lazy teams not policing the HR ad copy. The HR people don't know anything about versions. If it's a clueless hiring manager that's to blame the blame should also fall on the tech people who didn't stop them and tell them that getting overly explicit wouldn't be necessary.

Don't be too sure that's always the hidden motivation. I'm a very strong core JavaScript dev with only 6 years of experience and plenty of the latest stuff but that happens to me all the time. I could write a decent book on JS and I've had tech interviews stop early and get moved to the next phase based on my expertise with it but I'll lose out because I didn't learn or don't have years of experience in the 1 out of 6 popular app architecture frameworks d'jour that they wanted. Just stupid stuff that takes a couple days to get competent with, a week or two to really master.

Sometimes you have to sit down and self-teach some of this fad-tech junk just to get past the people who think finding qualified candidates is like ordering on a menu and will ignore the fact that you're a monster on the core technologies because of some triviality that within a week or two of hire won't matter a tenth as much as how much depth somebody has in the actual language.

Also, you might be running into a common programmer prejudice. You only have C/C++ on your list. That bugs me less than just C# or Java or Python, (definitely just JavaScript - very little excuse there since we're exposed to so much via back-ends we work with) but a lot of devs are skeptical of people who have been at it for more than a couple years and only learned one language, or perhaps more accurately one language and the same language with a giant robot OOP arm bolted on to it.

It was on the outs. It's starting to pick up again, but not for everything.

I'm not even sure what's meant by "hardware" precisely, but how does one collaborate in regards to it via internet tools? If you're configuring, testing, dealing with physical stuff do they have to mail it to you or something? The only remote QA I've ever worked with was offshore... and it was really bad with no motivation for it to get better since these guys had no connection with the team whatsoever. I'm not saying remote QA can't be done right but the idea may have left a bad cultural taste in a lot of engineers' mouths.

At the end of the day, there's a lot of legit and/or stupid but culturally powerful reasons people won't do remote. You have to be reducing your options by at least 95% in any job to take a telecommute-only policy. I'm sure age discrimination exists but I wouldn't expect it to be so bad that you won't even get hired anymore. But you might need to let go of remote-only if that's something you can control.

If you want to save a few bucks, save a few bucks. But don't pretend it's because you're the victim. That's not very adult at all.

People don't like to write. You telecommuting requires more writing. And how are middle-managers supposed to feel important if they aren't filling those conference rooms to capacity at all times?

Maybe I've just never been on anything huge enough but I just don't see how cutting corners on security saves you a lot of time for the actual code-writing part of it. It might save you time on talent acquisition or vetting third party stuff, I suppose.

It's never quicker. It's just stupider. Success at buying congressmen to steamroll all opposition and obstacles for you doesn't equate to a smart product.

well... schools to put those computer science curricula in!