Pacabel

They aren't "weird" design choices. Most of them are just plain bad design choices.

Desktop apps won't have a "comeback" for a lot of us. There have always been questions about the viability of these sorts of online services. So we did the smart thing, and never put our data and apps at risk to begin with. We have nothing to come back to, since we never left in the first place.

Ubiquity should not be an excuse for the promotion of what is, by all objective measures, a rather poor programming language.

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.

I don't see why codereflection needs to spell it out. The problems with npm, and JavaScript in general, are quite apparent to anyone who has used them. And if you haven't used them, a quick search engine search will turn up this information many times over.

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.

What benefit does this approach bring?

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.

I'd say it's even less capable. Shared hosting providers typically allow the use of Perl, Python, PHP, Tcl, Lua and sometimes other languages for CGI scripts. From what I can tell, this service limits you to Lua only.

Python 3 was never "in limbo".

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.

But it also doesn't offer many of the benefits and much of the functionality that Scala offers. A familiar C-like syntax, static typing, and so on are very important for a lot of Scala's users.

It's really absurd when people call Python 3 a "disaster". There was nothing disastrous about it. In fact, hindsight shows us that it was actually a very good path to take.

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.

Emotion is totally irrelevant here. I don't "hate" Firefox OS, nor do I "like" Firefox OS.

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.

The reality is that customers just don't want to use Firefox OS. Even with Amazon's support, it would still be very inferior in many ways to Android and iOS, and even to some of the other less-popular mobile OSes that are already out there.

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.

These sorts of arguments or claims aren't very convincing, or don't appear to hold true in practice.

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.

A large or well-known company merely using a programming language, and maybe even contributing back to it and its community, isn't the same as the company truly supporting or championing it.

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.

Is Rust CI really the best evidence to use in this case?

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.