nupark2

> True, but the JS VMs we have today have been refined over 15+ years and switching to another risks breaking the web in profound ways. Even Google would be against dropping V8 for JS use.

And yet, Google, Apple, AND Mozilla have all successfully introduced entirely new or significantly refactored VMs in the past few years.

This is solvable; it HAS been solved.

> JavaScript still has a lot of room for improvement. Putting resources in an alternative (whatever shape that might take) distracts from improving JavaScript.

This doesn't seem contrary to what I've stated above; it's an argument in favor of JavaScript over investing in a generic VM that would open up the ability to develop new browser languages to everyone.

In that regard, failing to allow others to implement custom/experimental languages seems counterproductive to the ultimate goals you seem to be stating here.

> For those who have a general syntax/style problem, there are numerous alternatives that compile to JS

In terms of performance, debugging, profiling, and simple functionality, compiling to JS is simply a work-around, not a solution.

I'll break this down:

- Android: Java, NDK (C++, C), ObjC (via Apportable), MonoTouch (C#/F#), Lua, JS

- iOS: C, C++, ObjC, JS, Lua, MonoTouch

... actually, that's as far as I want to go. Point is, you can pick your implementation language, and people do.

We're also likely to see additional language explorations on these platforms as they stabilize and mature.

> JS running on a general VM would be slower. That's against the interests of the user.

What do you base this on? It's sounds like an unsupported assumption regarding the complex technical constraints involved in implementing a general purpose VM and JIT.

Putting the technical specifics aside, intuitively, why would the general VM be slower, especially since the requirement to support JavaScript would be obvious to everyone involved from day 1?

> JavaScript is locked in. It's too entrenched, it's never going away. Let's just accept that.

JavaScript doesn't have to go anywhere, it can run on a shared VM like any other language.

> That means that adding additional languages creates a burden. You're now supporting, at minimum 2 VMs. If you're going to support a second VM you better get it positively right. That doesn't proclude doing it, it just means it's not coming tomorrow.

There is literally zero investment in moving such an idea forward on the part of Mozilla and WebKit (sans Google). In fact, there's active resistance, while at the same time strongly favoring JavaScript as the one option.

The position more seems to be "we might chip in if someone else comes up with the perfect answer" rather than "yes, this is a problem that needs to be solved to improve developer productivity, application quality, and help the web compete with other platforms".

If the browsers were to implement a general purpose VM, the choice of actual high-level languages would be distinct from the browser maker, and open to experimentation and competition.

The top comment states that any other options are impossible: "At this point we must concentrate on improving the language."

I can't stand this willfully defeatist attitude. It's also not restricted to stack-overflow participants -- this position is pervasive at Mozilla.

Why can't we have a standardized generic bytecode and VMs to run it? Why should the web be locked to a single language forever? Can you imagine if we had locked desktops and mobile only a single implementation language?

Google seems to be the only company actively looking for a solution via NaCL. Most of the web community, on the other hand, regularly opposes efforts to move away from JavaScript as the one true language.

Thanks for the correction; I meant asymmetrical.

> It's also in my experience a massive memory hog

It's not that Java is memory hog per se, but rather that the total VM memory allocation must be specified at launch, and the VM will not (rarely?) give that memory back to the OS.

This is largely an artifact of Sun's generational GC design+implementation, and has some interesting performance wins; namely, object allocation and deallocation are incredibly cheap, because in the fast case, all allocation requires is updating a single pointer.

The last time I profiled java object allocation, creating short-live objects turned out to be insanely cheap compared to other allocators/runtimes.

> Makes deploying your web application a pain (restarts anyone?)

This largely depends on how you structure your web application.

> If your Facebook and you're trying to get more bang-for-your-buck from your existing hardware, do you think its a good choice to migrate everything to the JVM (including a full rewrite to Java/JRuby/Scala etc.)?

That depends largely on how much they're spending on hardware and JIT/language engineers, versus how much a rewrite would cost, amortized over the reasonable lifetime of their code base.

You have to factor in the fact that they've built an entire organization around PHP, and it's not just a technological migration problem; they might also have to retrain or outright replace a large number of existing engineers.

I'm inclined to say that it was a mistake to choose PHP, and moreover, to continue to use PHP as they scale. However, funding the implementation of better PHP runtime implementation may be the most fiscally conservative decision left available to them.

> What happens if you cannot find a bank that gives you a loan without insisting that you give them access to your accounts?

This is what I find so frightening about the Facebook-login-only web services.

It's the first step towards the widespread requirement of a massively asynchronous information+value exchange between customers and businesses.

The JVM is one of the most advanced production-quality JITs available.

As for who is using it, everyone from Google to Twitter to Apple, as well a huge number of high-transaction business systems. The JVM is something that tends to get used quietly and widely.

I believe this is a fallacious argument; performance inefficient introduces significant costs at lower scales, too.

I'm referring to the quality of the implementation, its performance profile, the soundness of the type system and syntax, and -- like the original post -- measuring relative to the state of the art in JITs, including the JVM.

I find it interesting that the economics of inertia work out in favor of Facebook expending so much effort in improving the performance of a historically technologically poor language like PHP.

Jason Evans is the author of jemalloc (and more). Given all the things he would be capable of applying himself to, it's surprising to see him working on PHP runtime performance (though, the problems are interesting).

> Yes, I wanted to respond to your post and the subthread that you started with 'he is selling ads'. I think that gives your position away.

Well, the fact that he plans to financially benefit from displaying advertisements (or allowing them to be displayed) is key to understanding the alignment of his incentives: money for ads, insofar as his userbase will put up with it.

> Mobile apps w/ ads: Angry Birds on Android?

Haven't played it; I'd assumed it was a paid game. It's 99 cents on iOS. Unclear why it's free on Android.

I'm not actually sure if you intended to respond to my post, or another one in the thread. I've only addressed incentives involved, and the inexorable conclusion of misaligned incentives.

Whether that results in Adblock plus plus or not isn't something I tried to address, though the eventuality seems likely.

> Are you, by chance, using applications on the mobile OS of your choice that displays ad to gain revenue?

No. Few apps of any quality push ads, as they're incredibly detrimental to the UX on such a small screen device.

I think you misunderstand incentives. If Wladmir accepts money from advertisers, there's an innate incentive to accept more money from more advertisers, and to lower his standards for what makes an acceptable advertisement. He might want to support non-obtrusive ads, but the major incentive (money) is entirely contrary to that goal and your own preferences.

That aside, I wish to address the "free content" dichotomy (either we accept ads, or we lose free content ).

First of all, the content is not free; there are both tangible and intangible costs to you; advertising is funded through higher prices on the products we buy, and there are the intangible costs to being inundated with ads.

Second, advertising is surely not the only viable model. If adblocking were to actually succeed in undermining the web advertising industry, it would also provide impetus for the development of low-resistance web payment mechanisms, similar to the app stores and in-app purchasing that have revolutionized content purchasing on mobile devices.

In other words: 100% blocking of advertisements would not lead to the loss of "free" (but not really free) content, it would merely lead to the establishment of a more direct and efficient mechanism for funding that content.

So ... why not integrate a micropayment solution into the adblocker extensions. Bootstrapping problem solved!

I've "read the fucking article", and my take-away is that Wladmir is, in effect, selling ads.

In return for some sort of consideration and a pledge to only provide "acceptable" advertising, Wladmir will unblock your ads by default in AdBlock Plus:

> We have agreements with some websites and advertisers that only advertising matching our criteria will be used, their ads will be unblocked then. We hope to grow our list significantly over time.

Given that selling advertisements runs entirely contrary to the purpose of "Adblock", and that Wladimir's incentives are now inversely aligned with the user's incentives, I imagine we're going to see the same descent into increasingly obtrusive advertising that you almost always see once an organization heads down this path.

I only have experience with Apple. I wouldn't be surprised if the number was similar for Google, given that internships are seen as a low-cost, low-risk trawling mechanism.

> You seem to have some kind of chip on your shoulder, because you are reading a bunch of things into what I said that were not intended and are way out there.

I wouldn't read my response as a line-by-line rebuttal of your post. It wasn't.

> In short, the company you describe does have technical culture.

By that measure, all companies have a technical culture.

However, big company culture (outside of Google and Apple) is usually not appealing to junior engineers, but is to senior engineers -- which is the opposite of your original point, and what I intended to address.

On the contrary, experienced engineers are the ones most likely to be comfortable with a non-exciting big company that provides solid benefits, a reasonable working schedule, and mature, well-considered engineering practices.

Our own company isn't large, but we're rather traditional. We're not hackers, we believe in technical correctness, test-driven development and choosing the best tool for the problem at hand. This means that we generally write mobile software in the target platform language, server software in JVM languages, and on the occasions where we get to work on hardware and OS development, C and assembly.

The work approach is not laden with technical culture and "fun", unless you find solid engineering to be fun (personally, I do).

However, we've had great success in hiring genuinely senior engineers with at least a decade of experience each. We experimented early on with hiring junior engineers, but found that the overhead of dealing with untrained engineers was exceptionally high -- something that models my experience elsewhere, at larger companies.

With the caveat that these are generalizations, I've found that the cost to hiring junior engineers is expressed in obvious and (perhaps) non-obvious ways. There are the obvious costs of the training and mentoring required, along-side lower productivity, and a lesser ability to estimate complexity and time to completion. There are also more abstract costs, such as technical and design debt that junior engineers are much more likely to incur simply due to a lack of experience. There are also cultural costs -- if you hire too many junior engineers, you'll create a technical culture and working experience that drives senior candidates away, amplifying the costs I've listed above.

Of course, I readily admit that someone must hire untrained junior engineers, and I realize the implicit unfairness of hiring standards that would exclude myself were it 15 years ago. However, there are companies other than our own that are willing to bear these costs in exchange for being able to recruit at the scale they require -- we're just not one of them, and I think our reasoning is sound.

That said, there are some things a junior engineer can do to make themselves less junior, (possibly before even entering the labor market):

- Get experience (class projects don't count). A great way to do this is by contributing to OSS, especially projects that demand high-technical competence (eg, contribute to the ruby interpreter or MacRuby, not just high-level Ruby on Rails). Senior engineers have past experience to draw on when implementing software projects; this allows them to design not just for the immediate requirements, but with an understanding of how the requirements, maintenance costs, and performance will evolve over time.

- Study practical implementation topics (... and then get experience implementing them). A lot of the value of a senior engineer is in their broad understanding of the practical topics of the field. Coming out of a CS program, you should hopefully have a firm grasp of the fundamentals of CS, but what many candidates are missing is a firm understanding of applied programming. Some off the cuff general book suggestions: UNIX Network Programming, Application Programming in a UNIX Environment, Mac OS X Internals, Applied Cryptography, The Design and Implementation of The FreeBSD Operating System, Database in Depth. This list is probably incomplete :)

- Don't settle for just an internship. Internships at big companies (Apple, Google, Microsoft) serve as a relatively cheap first-pass filter on college candidates for hiring. Of a given pool of software interns at a company like Apple, it's unlikely that more than a 10% of them will be hirable material, and of those 10, maybe 2-3 will actually get jobs. Other companies may hire a larger percentage (I don't have any experience there). If you want to work for Apple, Microsoft, or Google (or think you might), then don't sit on your laurels if you get an internship there. Pick a real, practical problem that, and work on it, hard, leveraging your access to senior engineers for advice and guidance as much as possible. If you just coast through the internship, you probably won't receive an offer. I think some students look at internships at the big companies as prestigious. However, they may be viewed as the opposite -- an internship at one (or more) of those companies without being hired is a red flag for me, since I'm wondering why you didn't get an offer.

In which case the failure to communicate is mutual; In OP, I said:

... this position drives me bonkers ("not HTTP, too hard")!

As professional engineers, it's my hope that opening up a persistent TCP socket and sending a small, stateless binary message should be easier, faster to implement, and better performing than marshaling everything into HTTP (for no other reason than HTTP is more familiar to you!).

If that's not the case, then I would strongly recommend that any engineers that are uncomfortable with this simple task should review UNIX Network Programming Vol 1, and Network Security with OpenSSL, rather than complain that an HTTP interface isn't available.

At the very least, such a study would provide a necessary understanding of what HTTP is doing. With that in place, opening up a connection to APNS should be a walk in the park.

> For a hobby developer or small business where time is precious, using built-in HTTP libraries is far easier and faster ... Sorry, but you're not going to convince me that rolling your own implementation of Apple's APNS is better than an HTTP-based APNS would have been.

Something is rotten in the state of Denmark; if this can be done in 20 lines of Python (see comment above), then why do so many ostensibly capable engineers find it so difficult?

> But what is the actual advantage?

Efficient high throughput performance. That's why Apple went with the protocol they did in the first place.

> What makes it worth having to spend a day or two on a custom solution?

It's not "custom", it's just a TCP connection.

I quoted a day or two as a maximum estimate, assuming someone totally unfamiliar with the space, and possible integration issues with their existing infrastructure. I'd be surprised if Urban Airship was fully integrated any faster, since most of the heavy lifting will be in managing state and creating an internal push API, not in speaking TCP+SSL to Apple.

[edit] Here's an implementation in about 20 lines of Python: http://blog.nuclearbunny.org/2009/05/11/connecting-to-apple-...

> Microsoft's Push Notification Service (WNS) is a HTTP-based, which is awesome. Apple introduce a TCP-based approach to push notifications that basically requires you to write a dedicated sever (again, somehow, Apple didn't specify how to do) to send your push notifications through their APNS. No one rolls their own APNS server because it's too hard and there's Urban Airship.

This is ostensibly a professional engineer, and this position drives me bonkers ("not HTTP, too hard")!

Apple provided protocol documentation and a very, very simple TCP+SSL protocol. Rolling your own client should be a matter of a day or two of work, at the absolute maximum.

Apple even provides sample code: http://developer.apple.com/library/mac/#documentation/Networ...

The fact that people are frightened of TCP and a simple binary protocol is a mind-boggling indictment of the ineptitude and inexperience of the engineers that have been placed in a position of responsibility.

I dealt with a server team recently that refused to consider a push-based feature because it would "cost too much to send that many pushes through Urban Airship". Implementing their own local client for the protocol never occurred to them, and our doing so for them dismissed out of hand ("too complicated").

I was referring to the IT choice to standardize on Windows as a deployment platform for your organization.

As for Reddis, the cost of supporting another operating system -- especially one as different as Windows -- is quite high. If you don't use Windows, there's little cost justification for doing so.

Standardizing on Windows as a deployment platform has known costs and benefits. One of the costs is in largely losing out on the traditional UNIX software ecosystem.

There are some OSS projects that maintain first-class Windows support, but nobody should be surprised that when they find out that Windows is poorly supported by an OSS ecosystem that is predominately focused on producing software for UNIX descendent systems.

Which circles back around to the point above; until you have a few examples, trying to make something reusable will probably cause you more pain in the long run. That's not justification for bad code, just an argument against premature factorization.

Like recommendations against premature optimization, it's just a good rule of thumb.

This seems like a risky compliance hack to be relying on. While it might conform to the letter of the law[1], it absolutely does not comply with the spirit of PCI compliance in regards to securing cardholder data.

There's literally no security difference between processing the card transaction through your own servers, and processing it client-side via HTML/JS that your servers are providing (and can modify).

[1] I wouldn't have thought this would meet compliance requirements, but I'm not a PCI expert -- I've only had to work on compliance on the user side, and deal with the auditing requirements.

If you're not going to re-use something, then why are you writing it to be re-usable?