The Current State Of Pyston As An Open-Source, High Performance Python

[SystemCrasher]

So I take it that you don't like Rust and the Servo project?

I would rather tell that I dislike what Mozilla has became. Now they are no longer about technical excellence and vibrant opensource communities. Now they are all about "ecosystems" shit, vendor-locking (including total control over all extensions in browser), marketing BS, believing in silver bullets, inadequate/incompetent solutions like asm.js and pdf.js, and other fairly troublesome stuff. When there was Firefox 1.0 they were like an order of magnitude better in techs and were not craving for money like mad. Seems they fired most coders and hired plenty of managers and marketing people. And even their marketing is BS: they turned FF into underdeveloped fake of Chrome. Can someone give me idea, why I need browser "like Chrome, but worse"? I do not get it.

So, speaking for myself I'm just not going to rely on Mozilla as upstream in long term. Whatever, they shown their ugly faces with all these advertisements in new tabs, digital signatures in extensions I can't override and so on. These aren't opensource minded people and not what I've used to value anymore.

Rust on it's own... well, idea itself does not looks anyhow bad, or something. But again, I do not get who needs it. System devs & somesuch? Unlikely, C works for us, and it is nice when we can program everything from microcontroller to supercomputer, and being able to get most of particular system, if desired, and language does not gets on the way. Gamedevs? Uhm, seems they are fine with C++. It maybe not best, but it works for them. Those using newb/rapid approaches seems to like Go. Google did something between JS and C, for those who wants something lite & rapid and lacking cruft of C and disadvantages of JS. Scripters seems to be ok with python, ruby, JS and something. They do not give a fuck about speed anyway. Exotic stuff lovers have drastically different things, from Haskell to D, whatever they prefer. And who needs or wants Rust? And why? Does it offers some unique advantages others can't afford? Or, uhm, what?

Then, Servo. Whole idea using Yet Another Language to do some Better Things looks flawed to me. It never works in practice and if someone relies on language or runtime too much.... uhm, well, Mozilla recently did a really dumbass critical 0day using just JS in sandbox, dammit. Because they are nuts. First, they forgot about input validation. And so it has turned out PDF can actually be JS code. Then these perverts transform PDF to JS to render it. Uh, sure, it has demanded what followed. Rogue JS hits pdf.js, pretending to be PDF and getting executed, due to lack of validation. Dumb, but shouldn't be fatal on it's own. But Mozilla devs decided to "improve security" further, preparing code base for being muti-process. Somehow, they FUBARed it and rogue code was able to get elevated rights, pretending it is also part of PDF.js. How smart. Then, rogue code can do a lot of nasty things, practical examples usually scanned HDD and stealing everything valuable stuff they can, like SSH keys, passwords, etc. It took a really epic-scale pwnage until Mozilla devs noticed they've got EPIC FAIL. Does someone honestly thinks rewriting browser engine in different language would save THESE devs from something? IMHO, not a snowball chance in the hell. Doing critical 0day using JS, after extensive praising JS security is just EPIC. So I would think they can easily repeat EPIC FAIL with Rust. Or whatever language, as long as it allows to do anything meaningful.

[SystemCrasher]

As far as I understand it, it was heel-dragging on allowing websites to be compiled beyond what a javascript prettifier could make comprehensible.

Things like a139=14 can't be made "comprehensible", whatever you try. They have just as much meaning as things like "mov r12, #14" in hardcore assembly with the only difference it is variable used as "register" and IR takes several times more space and can't be easily parsed and submitted to CPU without shitload of extra steps.

When JS minimization is done, human-readable names are irreversibly lost. Readability of program goes down to a level of disassembled machine opcodes listing and hardly provides any advantage. Have you ever seen JS code produced by tools like emscripten? This is easily worst thing ever: both not anyhow meaningful as text, yet slow to parse and execute, several times larger than binary representation of the same thing. Taking worst from both worlds at once. So we have unreadable meaningless code which isn't much better than hexspeak and shitload of technical issues resulting from inefficient and troublesome IR. And asm.js is really halfassy solution which does not solves lack of adequate IR in first place. Js just nearly worst IR ever one can imagine. It never meant to be to act like this and so it works like a crap in this role. Just like car design would prove to be a really shitty thing if you really want airplane, not car.

Mozilla is now part of the collaborative effort to define WebAssembly.

Whatever, they already shown what they are with all these half-assy web.js, pdf.js and something. It works like a crap and so I would not consider Mozilla good in technical excellence. At the moment they do just a bunch of crappy products with unobvious targeting.

is poised to draw the best aspects of both Mozilla's asm.js and Google's PNaCL,

...and meanwhile, all gamedevs I know gone NaCl and ported their games here. Being utterly horrified by asm.js, emscripten and other Mozilla-inspired perversions.

the latter of which is derived from a subset of LLVM IR that's both portable and suited to being frozen into a standard that's stable into the indefinite future, unlike LLVM IR itself.)

So you mean they finally got at least some sanity? Okay, but speaking for myself, I'm just really got fed up with all idiocy coming from Mozilla. They even made their browser to look like a Chrome. And if I would want THIS, I can just go use Chromium TODAY. It would also support NaCl and so on. And so if Mozilla would follow the same road further, I wish them luck, but I'm afraid they can turn into Opera #2.

[ssokolow]

Things like a139=14 can't be made "comprehensible", whatever you try. They have just as much meaning as things like "mov r12, #14" in hardcore assembly with the only difference it is variable used as "register" and IR takes several times more space and can't be easily parsed and submitted to CPU without shitload of extra steps.

I never said it was a smart idea. Just that I'd heard that was their rationale. (Of course, I also heard that their rationale was heel-dragging on defining a portable bytecode because backwards-compatibility and that does make more sense.)

Whatever, they already shown what they are with all these half-assy web.js, pdf.js and something.

What's wrong with PDF.js? Getting everything within a single sandbox so there's less code to audit is a smart idea and it's not as if they had PNaCl or WebAssembly back when they started it. Chrome seems to have done something similar though I'm guessing they're probably using PNaCl for the heavy lifting.

Plus, it's embeddable, which is very nice for a groupware project I'm working on where inline preview is the rule of the day.

...and meanwhile, all gamedevs I know gone NaCl and ported their games here. Being utterly horrified by asm.js, emscripten and other Mozilla-inspired perversions.

Google recommends PNaCl over NaCl so apps will work on non-x86 devices like ARM-based Chromebooks, tablets, and phones. As for PNaCl vs. WebAssembly, the whole point of WebAssembly is to be a NaCl/PNaCl that can be implemented on all browsers rather than being ActiveX 2.0. (Why do you think Mozilla pulled out after Google invited them to collaborate on the Pepper plugin API? It requires Wine-like bodges to make it work with something not sharing Chrome's internal architecture and Google wasn't willing to change the design.)

Okay, but speaking for myself, I'm just really got fed up with all idiocy coming from Mozilla.

No argument. I have a laundry list of bad decisions I pull out whenever people in Mozilla try to speak about how good something is. (eg. Following Chrome's decision to hide "http://" which prompted Google to lock the thread where they were soliciting feedback because the only feedback they kept getting was "this introduces tons of copy-paste bugs and unexpected behaviour but you still haven't given an example of something it makes better".)

Given the limitations of Chrome's extension APIs Re: the extensions I use and Mozilla still being the least for-profit and privacy-friendly of the browser vendors, I see Firefox as the best of a bunch of really bad options.

[reepca]

I wonder what about PyPy the Dropbox folks decided was insufficient for their needs. That's just curiosity.

I think it's clear that scripting languages, even JIT ones, can't quite match the raw performance of a good compiled language. At least not yet. But the work being done with Javascript is impressive - asm.js gets within a 3x factor of C on most benchmarks, and for mobile devices that's probably sufficient. I'm curious if in ten or twenty years every popular dynamic language - Python, Ruby, PHP, Perl, Scheme - will have at least one open source runtime that gives performance on par with the best Javascript implementations today.

Common Lisp gives a sad wave from its lonely corner. Wishing it could be loved, wishing it could have friends. Wondering whether it made the best choice, doing what was right instead of what was easy.

[SystemCrasher]

I never said it was a smart idea. Just that I'd heard that was their rationale.

Somehow I'm not really fond of their competence. And failure of FF OS ... I've predicted it. Few years ago. Sure, it's better to try and fail, but on other hand, if failure looks obvious and imminent, it could be wise to just save some resources.

What's wrong with PDF.js?

In first place pdf.js got mindfucked design. As far as I've understood, Mozilla dullards got idea it is cool to grab whole PDF and translate it to JS. In one shot. Yikes, it keeps high score as most retarded and troublesome document representation I ever met.

Result?
1) Okay, it can take whopping 2 minutes to render PDF. Damn, when I evaluate electronic components, I have to look on 10 PDFs in 10 minutes, and waiting 2 minutes just to learn I do not need that garbage at all could be sad, right?

2) On large PDF resuling JS can grow so huge browser consumes gigabytes of RAM and ends up being shot by OOM killer when system runs out of RAM. Needless to say it can be annoying if browser is torn down just because I've opened some large PDF. After all, I could lack a priory knowledge how large this particular PDF happens to be.

3) Last but not least it also most bugged PDF viewer I ever met. Example: I've opened some schematic and got idea it looks invalid. After scratching my head, I've opened it in evince. Voila, it looked okay. It seems in some PDFs, mozilla viewer can easily forget to draw half of lines. Absoluetly fatal for schematics and similar "line art".

So it is fucking slow, causes memory outages, killing browser, fails to render some PDFs, and then ... mumblings about security proves to be utter BS, because pdf.js happens to contain awful 0-day vuln. Especially cool is the fact it were mozillians who fucked up JS permissions during creating their "electrolisys" thing to "improve" security. And as bonus they only noticed it when mass pwnage started and they got smashed by legions of pwned users. How I learned it? Ok, someone told their browser lagging. I've took a look. What I've seen has been horrifying: digital warfare tool doing treewalk across user's HDD, trying to find all interesting files it can imagine. Sure, it somewhat slowed browser down, because it has been trying something like 100kb list of "potentially interesting files" you can ever face on Linux, win, mac, bsds and probably something else.

I will have hard time to name worse PDF viewer. Just to give idea: evince viewer starts in below 1 second and renders PDF in an isntant. It never caused OOM condition, not even on huge PDFs, not even on my laptop, which isn't a what I call a powerhouse. If one can make PDF viewer worse than Mozilla, I'm yet to see it. So the only Mozilla "achievement" is: they forced me to waste my time on troubleshooting browser, learning how to get rid of this misfeature.

Getting everything within a single sandbox so there's less code to audit is a smart idea

...but Mozilla managed to fuck up even this idea. While pdf.js as viewer isn't what I call great program. For me it just a chunk of useless dead code which just does not fits my workflow and forces me to waste my time on figuring out how to get rid of this "improvement". And I've got idea mozilla recently got way too annoying with their "improvements" breaking browser and/or my workflows all the time. I'm not fond of fixing browser every month, it suxx.

and it's not as if they had PNaCl or WebAssembly back when they started it.

Still, I'm not fond of their technical competence, their program does not speaks for itself. Or to be exact, it does, but it only tells me mozilla devs are really incompetent and can't make good programs, and also inclined on locking everybody down with their signatures crap. At this point I think they've miserably failed their mission stated in about:mozilla. Mammon has won the battle over this instance of beast.

Chrome seems to have done something similar though I'm guessing they're probably using PNaCl for the heavy lifting.

Somehow, google can afford reasonable technical solutions and at least somewhat cares about performance, resources consumptions, power consumption, etc. Then, I can see, say, on Linux they have small fancy loader which does clone() and cuts off rest of chromium browser to real Linux container, where no other process and no other data exist. Needless to say it is light years ahead of what Mozilla can afford. Should attacker be able to pwn browser like it happened to pdf.js, attacker enters very boring system with only one visible process and no interesting files. While I wouldn't insist Linux containers are uncrackable, it raises bar for sure.

Plus, it's embeddable, which is very nice for a groupware project I'm working on where inline preview is the rule of the day.

Fortunately in no way I can be forced to use this stuff. So it not going to be my problem.

Google recommends PNaCl over NaCl so apps will work on non-x86 devices like ARM-based Chromebooks, tablets, and phones.

And that's a good idea overall.

As for PNaCl vs. WebAssembly, the whole point of WebAssembly is to be a NaCl/PNaCl that can be implemented on all browsers rather than being ActiveX 2.0.

Nothing prevents mozilla from implementing PNaCl, except the fact they are retards who prefer halfassy crap like asm.js. Sometimes it is time to acknowledge obviouis .

(Why do you think Mozilla pulled out after Google invited them to collaborate on the Pepper plugin API?

I'm not really sure there should be "plugin api" like this at all, and google seems to have similar idea. Flash just some deprecated tech, which haves no place in future and there're no other things using pepper api I can remember. And to avoid being activex it is really better to go for something like pnacl or so.

It requires Wine-like bodges to make it work with something not sharing Chrome's internal architecture and Google wasn't willing to change the design.)

I've got impression Google isn't really fond of this thing overall. I.e. it is last resort thing when you can't go for pnacl or something like this. It do not have to be easy or welcoming to avoid activex-like situations.

"http://" which prompted Google to lock the thread where they were soliciting feedback because the only feedback they kept getting was "this introduces tons of copy-paste bugs and unexpected behaviour but you still haven't given an example of something it makes better".)

...and at the end of day, Mozilla did the very same. And why the hell I need something which copies all idiocies of Chrome but also well below of it in many other technical aspects, be it pnacl or ability to use Linux containers? I do not need third rate version of chromium, and FF happens to be something like this these days. They made tabs appearance to match chrome. They've trashed native looking UI to mimic chrome further. They killed most of UI customizability. I do not get why I need this crap, it attempts to look like a Chrome but technically worse. And killed out what I've considered their advantages. Nice shot,

Given the limitations of Chrome's extension APIs Re: the extensions I use and Mozilla still being the least for-profit and privacy-friendly of the browser vendors, I see Firefox as the best of a bunch of really bad options.

Not after they introduced mandatory extensions signing without any reasonable means to override it. They've proven they are trying to be walled garden ecosystem which haves nothing to do with opensource values. Not to mention they break my workflows every month or so. Whatever, but I can't classify them neither as friendly, nor as technically competent and I'm really fed up with all Mozilla shit in latest versions. It has been a good ride, but I'm out. Let 'em use their shit themselves. It has been epic in FF 1.0 and MozSuite times but they abandoned their goals and changed priorities. FAIL.