Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's the issue with this -- if this is actually a problem for Python, then it's a problem for EVERY programming language.

Let's first see what satisfies these problem areas:

Mobile = [ObjectiveC, Java, C (native client)] (and maybe Javascript+HTML if you look at the "compile down"/"webview" solutions)

Browsers = [Javascript] (and _maybe_ C if you say Emscripten is actually a sane solution to problems but I'd argue it fits only a minority of cases)

Games = [ObjectiveC (iPhone games), Java, Lua (scripting/plugins), Flash/ActionScript, C, C++]

No single language fits across all of these (dare I call them) niches. Every single language other than Javascript fails the "Browser" test.

I'd argue that focusing on many of these niches is the wrong way to go. Trying to fight for a spot on the mobile front will be a losing battle as Python will always be a second class citizen or flat out denied. The game development front seems like a confusing goal -- how many devs picked up Lua from the plugin system? Additionally, Python isn't fast enough to be the base nor faster than Lua for the plugin system.

The metric that he says he's optimising for is "adoption". I just feel like he's working backwards and optimising for tiny use cases instead of the general case. Many Java classes at university are being replaced with Python for example, and I'd say that's more important for adoption than any of these areas (other than web).



Don't forget C# from Unity under games.

The take away here is that since client side web programming can only be javascript, it pigeonholes a large chunk of development effort into a forced language. I can't wait for the day web browsers can leverage multiple DOM aware scripting languages. The fact the JS JIT is already tightly coupled with an html / css parser is already bad enough.


Fat chance. It's already hellish to properly secure one JIT, a multiple-JIT browser would quickly look like Swiss cheese.

Face it: unless something miraculous happens (like Microsoft, Mozilla, Google and Opera all agreeing on a brand new language), javascript will likely remain the only choice for "in-browser" UI development. Unless the browser gets replaced wholesale, we're screwed like that.


Once Chrome gains enough users, they can choose to include Dartium (their Dart VM) in Chrome and choose to support that.

As a language Dart is not exciting. It doesn't tout fancy monads or functional data structures and so on, but it looks basic, simple and average. Kind of like what Java would be if it was made for the web.

So there is at least on contender out there to replace JS.

Mozilla is working on Rust. A very exciting language that actually has many fancy features, some borrowed from Erlang. Not sure if that will ever make into an in-browser language, but who knows.


Although I agree in spirit, I took a different design route in Ginger which supports multiple syntaxes and front-ends. By designing a generic syntax tree and defining its mapping into (a tight subset of) XML, I got away from the details of the back-end virtual machine. In fact Ginger has three very different back-ends, ported easily to another system (Poplog), and would be a days work to get it running in Java (badly - maybe a couple of weeks work to get it running well!)


We ought to move from browser languages to browser bytecode VMs. Everybody gets to use their favorite language and we have a single target to secure.


> No single language fits across all of these (dare I call them) niches. Every single language other than Javascript fails the "Browser" test.

there are the compile-the-browser-component-to-javascript options like haxe and opa. haxe is even planning on compiling to mobile platforms.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: