This is especially true when it's an environment where there are numerous other languages available, and they're all so much better than JavaScript. Lua, Python, Perl, Ruby and even Tcl would all be better choices.

It's mildly excusable when it comes to web browsers, because JavaScript really is the only viable option. But that just isn't the case with a full-featured environment like OS X.

It'd make sense to ask for such clarification if the information truly wasn't available elsewhere, and accessible with a quick search. But that's obviously not the case.

It's pointless to rehash this obvious stuff over and over and over and over again.

It reminds me of Chrome OS and Firefox OS. These all are based upon the Linux kernel, so they could potentially offer a very rich user experience like so many more traditional Linux distributions do. Yet they intentionally cripple themselves into being limited, JavaScript-only platforms.

This would be understandable if, say, storage space was expensive, like it was in the 1980s, and the software had to be kept lean and limited. But that's clearly not the case today, even when it comes to low-end smartphones.

The same goes for runtime performance. It'd be one thing if software written in JavaScript was consistently and significantly faster than software written in C, C++, and other commonly used languages. But that just isn't the case. Unless we're looking at highly tuned and highly unrealistic benchmarks that even the JavaScript VM authors have focused on making run fast, JavaScript's performance is quite bad.

It would be understandable if perhaps the user experience could be improved in some way by them providing superior alternatives to the traditional userland software offered by Linux distributions. Yet this isn't the case, either, because some of the biggest complaints with Chrome OS and Firefox OS are that the bundled software is awful, and users have no real recourse due to the very limited environment that both offer.

As far as I can tell, users just can't win with a system like this. The kernel is powerful, but this power is isolated and kept inaccessible. The userland experience is much worse than what one would get if just using a traditional Linux distro, and running the JavaScript software on top of that. The benefit to the user just isn't apparent.

From the very start its goals were clear. Yes, it took some time to implement them, but this was done rather efficiently and quickly.

Unless you were using one of a handful of libraries that didn't put forth the effort to be compatible with Python 3, it was very easily to adopt Python 3 early on, and to use it effectively.

I worked with a group that adopted Python 3 relatively soon after its official release. This would've been around early 2009. We developed a number of large systems using Python 3, without any major problems. Sure, we ran into bugs now and then, but we reported them and they were fixed soon enough. We helped port some libraries to Python 3.

We didn't regret the decision to go with Python 3 then, and the last I talked to people still involved with those projects, they don't regret the choice now. They're glad that their millions of lines of code are targeting Python 3, which is without doubt the future of the Python language at this point.

I don't know why people such as yourself continue to portray Python 3 as a "disaster", when all of the evidence and much of the experience with it shows the complete opposite to be true.

It was a smooth transition for Python 2 users who didn't want to or need to upgrade. It was a smooth transition for Python 3 early adopters. It's a rather smooth transition now for Python 2 users who want to use Python 3. "Disaster" just isn't the sort of term to describe a transition that goes well for all involved.

Python 3 didn't negatively affect Python 2 or earlier users. Their code still runs fine, and is well supported by a huge number of libraries. They weren't forced into upgrading against their will at any point.

Python 3 allowed the Python developers to make some breaking changes to the language and libraries. These have, without a doubt, improved the language.

Much Python 2 code, especially well-written code, can be automatically converted to Python 3 code with little to no effort. Anyone with any sensibility who has been writing new Python 2 code within the past few years has been keeping an upgrade to Python 3 in mind. Their transition should be quite painless.

Over time, more and more existing Python libraries have supported Python 3, or been replaced with significantly better replacements, as the need arose.

The fact that we see so many libraries simultaneously supporting both Python 2 and Python 3 goes to show that the community is not "divided" or anything like that.

The only downside is that it took a few years longer than people may have initially been expecting for certain libraries or frameworks to support Python 3. But at this point in time, Python 3 is a clean, usable language with very good third-party library support. Existing users weren't forced into using the new version, yet those developing the new version weren't constrained by compatibility concerns. The end result is an improved and usable language, achieved with minimal disruption.

Perl 6 is an example of a real disaster, on the other hand. It still doesn't have a truly good implementation, even after 10+ years. Not only is Perl 6 pretty much unusable in practice today, but the uncertainty it caused stunted the growth and development of Perl 5 for quite a while. It is only recently that we've seen people finally realize that Perl 6 is a lost cause, and get back to using and evolving Perl 5. Compared to Perl 6, the Python 3 development process was perfection.

It's just a tool, so I give it an objective, unemotional analysis. That analysis shows that it lacks the features and functionality that are needed for it to be a useful tool for the vast, vast majority of users.

Most people use a phone for practical reasons, not ideological ones. They don't care how "open" it may be if it doesn't run the apps they need or want to use. Firefox OS will have no chance of succeeding in the long run as long as it continues to provide a sub-par user experience.

Given that Firefox OS apps written in HTML5, CSS and JavaScript should run just as well on Android and iOS, anyone actually wanting to use such apps is better off just getting an Android or an iOS device. That way they can run the Firefox OS apps, as well as all of the other apps that Android or iOS support.

The claim that the development of Firefox OS is somehow more "open" is very suspect. Even if the source code is publicly available, and outside contributions may be accepted, Mozilla is still going to act as a gatekeeper, which inherently limits which contributions will or will not make it into Firefox OS. That doesn't strike me as being any more "open" than the development of Android or iOS is. A contribution to Firefox OS is a suggestion at best, but one that can be unilaterally disregarded by Mozilla without any sort of consequence to Mozilla. That's no different than making a suggestion to Google about Android, or to Apple about iOS.

The recent tendency of Mozilla to force totally unwanted changes (like Australis) upon Firefox users, even after very vocal objections to such changes, further makes me skeptical about how much openness there truly is when it comes to their products. Any objections, suggestions, feedback or contributions that aren't compatible with the direction that Mozilla has already decided to take appear to be ignored. "Openness" means that non-Mozilla parties can actively influence the development and future of Firefox OS. Merely being able to provide non-binding feedback or suggestions, even if in the form of code, is not really openness.

Likewise, the claim that Firefox OS "doesn't limit your freedom" is suspect, too. How can that claim be made when developers are pretty much forced into using HTML5, CSS and JavaScript to build apps? I don't consider myself to have "freedom" if, as as developer, I'm forced into using JavaScript or some half-baked "transpiler" that attempts (usually poorly) to target JavaScript.

It's also odd to claim that these apps will somehow be portable to other platforms, especially if they're using APIs that only Firefox OS currently supports. Even if there have been efforts to standardize these APIs, the fact that they aren't widely implemented by other browsers or platforms renders them as proprietary to Firefox OS, in practice, at least for some time. A standard that exists but isn't widely implemented probably shouldn't be considered a standard.

And the "HTML5 is a first-class citizen" distinction seems quite irrelevant in practice, as well. If the same apps will supposedly work on other platforms, either natively or with the help of something like Cordova, then they're just as "first-class" there as they are on Firefox OS.

So as you can see, the arguments you gave are theoretical at best, and some of them don't even appear to hold true in reality.

What you describe is very different from, say, how Sun pushed Java, or Microsoft pushed C#, or how Apple will likely push Swift, or how a huge portion of the entire software industry pushed C and C++.

Facebook's Hack language is probably a much better example than D is of a language that they're actively supporting. It's a creation of theirs, rather than just a creation of somebody else's that they find useful in some limited cases.

When I last looked at it, probably 40% to 50% of the projects listed had builds that were in the "failing" or "error" statuses.

That indicates that one or more of at least a few things are happening:

1. The Rust language and its standard libraries are changing at a pace that results in previously-compiling code needing to be modified before it will compile again with a newer version of the language/implementation, perhaps a very short time after the code was initially written.

2. The Rust compiler or other tooling is crashing or failing in some way while compiling these projects.

3. The projects themselves aren't being maintained on an ongoing basis.

4. The projects themselves were never building properly in the first place.

5. The projects' developers are targeting different versions of Rust (which probably means there will be interoperability problems for anyone trying to use them in a larger projects, especially when it comes to libraries).

And while there may be a lot of these projects, I've never found the quality to be very good. Many of them are extremely limited or incomplete. Many of them are little more than casual experimentation. Many of them are only developed by a single person, who often has appeared to have lost interest.

Those factors are disconcerting, especially for somebody who wants to use Rust for serious product development. It does no good if there are hundreds of libraries available for use, but half of them don't even build, and the ones that do are very incomplete.

Maybe Rust will offer such stability in the future. But that's of no use to people and organizations who need to develop software today, and who need to be able to trust that the code they write now will compile and work tomorrow, a month from now, a year from now, and perhaps even decades from now.

C++ does offer stable, standardized, well-supported versions of the language. C++ does offer stable, standardized, well-supported standard libraries. There are numerous high-quality free and commercial C++ implementations available, for just about every platform imaginable. It provides a robust and predictable platform that serious and massive software systems can be built upon.

The theoretical benefits that Rust may bring are pretty much irrelevant as long as it isn't a production-ready language in the way that C++ is.

I've seen and heard a lot of reports from many different Firefox users about Firefox using an unreasonably large amount of memory, even when using fresh installations of the most recent version, and when engaging in very reasonable browsing patterns.

As a software developer faced with a large and frequent volume of reports of such a nature, the only responsible thing to do is to assume that there is truly a problem. This should be assumed even if the developers themselves may be having trouble reproducing the problem. Denying that the problem exists is usually the most counterproductive thing that can be done, because the problem likely does actually exist, and it doesn't get fixed.

By the way, I don't believe that there ever was a Firefox 2.5 release. Perhaps you mean Firefox 3.5?

If you're going to make such accusations, or even just hint at them, please provide us with at least some real evidence to show that rdxm is being directly compensated by one or more of the industry incumbents for posting that comment. Since I doubt very much that you can provide that evidence, I think it would be appropriate for you to apologize to rdxm and to the rest of the community here.

I don't think the hatred is as universal as it is for, say, Australis, but it's close enough that it should be discomforting.

What is your response to this? Do you think it's right to continue work on a project that the majority of people dislike for a variety of very legitimate reasons?

As somebody who lived through the events you mentioned as an adult working in industry, I can assure you that the sentiment you believe was felt was actually not felt.

Mouse wheels were seen as a very good thing when they first came on the scene. They gave the power of the three-buttoned mouse, but also made scrolling much simpler.

The same goes for tabbed browsing. It was one of the best features of Opera for a long time. Everyone I showed it to at the time thought it was very useful. And it was one of the best features of Firefox, too, when it was still Phoenix.

And the same goes for fonts, and CSS (although to a lesser extent). Their benefits were obvious from the beginning, and I don't remember them facing really any resistance.

Contrary to popular belief today, JavaScript was not seen as good when it was first released, and it should not be considered good today. In the mid-1990s it was generally seen as a rather bad and limited language. That's why it didn't see much use until the mid-2000s. The first generation of developers who experienced it found it inferior to existing technologies and generally refused to use it. Even today, it's still a very flawed language (the problems with it are well know; I'm not going to regurgitate them here).

The problem with Firefox lately isn't that there has been chance. Of course change can be good. In the case of Firefox, though, the change has been utterly horrible, and caused far more problems than it brings in benefits, for a huge number of people. This is reflected very well in Firefox's ever-dropping market share.