Pacabel

The reasoning in your first paragraph never really seems very sensible or realistic.

So people with very limited financial resources to begin with will be able to buy ultra-low-end phones that offer poor performance and a poor user experience. Then they'll only be able to choose among a very small selection of apps, none of which end up being particularly useful. And although they have basically no money to spend at this point, somehow their mere presence online will somehow induce companies, who need to make or take money from these users somehow, to create more apps?

It just doesn't follow. It makes even less sense when you consider that it's possible to get used Android phones in these target markets for the same amount of money, if not less. And these Android phones often end up being more capable than a new, low-end phone running Firefox OS. Plus they offer all of the numerous benefits (like better performance and far more apps) that even old versions of Android offer over Firefox OS.

Are there any screenshots showing side-by-side comparisons between the same app implemented using this technology running on the different platforms it supports?

I looked quickly through the article and the NativeScript web site, but couldn't find any. All I saw was rather useless marketing imagery.

It's clear that Rust isn't stable yet, and won't be for a long time. It's impossible for me or anyone else to be incorrect when we point out that very real fact.

If you feel the need to vote down perfectly legitimate comments merely expressing a truth that you dislike, so be it. I can't stop you, and the others you've chosen to target can't stop you, either. However, reality will be reality, regardless of the voting. Rust will still remain unstable no matter how many down arrows you click.

Firefox OS is yet another example of Mozilla apparently thinking that ideological purity alone will somehow entice users into adopting an otherwise average-to-bad software offering.

That isn't how reality works, though, obviously. Out of necessity, most users must place software usability and capability above ideology. Software like Firefox OS and Persona will never see serious adoption when they can't compete with long-established and more functional offerings at the most basic levels, even if these competitors may not be as "open".

It's an approach that doesn't work for Mozilla's offerings that are already well-established, either. Firefox has been hemorrhaging users ever since its developers stopped focusing on truly improving the user experience, and instead focused solely on copying the worst aspects of Chrome (the UI, for example), while neglecting to address the performance and resource usage problems that have long plagued Firefox.

Users need software that works. If that means using software that's "less open" or "closed", they'll do it without a second thought. Mozilla just happens to often be on the losing side of this reality these days. While "openness" can be beneficial, it needs to be in conjunction with software that's at least comparably good to its "closed" competitors. Firefox OS, Persona and Firefox are good examples of where this isn't the case, and how they're either seeing limited to no adoption, or how they're losing existing users.

I wouldn't say that it necessarily is. But Android does offer the NDK and the upcoming ART runtime, which get far closer to native code than what we're seeing from HTML5/JavaScript/CSS.

How do you figure there are "fewer layers"?

Both are built upon Linux. So we can say that they're pretty much equivalent at that level.

Then there is a runtime and libraries providing common functionality above that. Again, we have pretty much the same in both cases.

Then we have the apps running on top of that, making use of the functionality of the two lower layers. Once again, it's a similar situation in both cases.

I really don't see the differences that you claim are there.

The reviews I've read about the existing Firefox OS phones, which have reportedly cost well over $25, have not been very encouraging. Pretty much all of them have pointed out that the hardware is quite poor, and this results in a rather bad user experience. Even considering how rapidly the cost of mobile hardware has been decreasing, what will prevent a similarly negative user experience on these cheaper Firefox OS devices?

While the ideological benefits of HTML5/JavaScript/CSS "apps" are often touted, we've yet to see anything truly remarkable done using such technologies. At best, we've only really seen clones of existing Android and iOS apps, but these generally feel less responsive and less capable than their native counterparts. If Firefox OS only supports these kind of non-native apps, how is it supposed to truly compete with Android, iOS and the other mobile platforms that support these HTML5/JavaScript/CSS "apps" just fine, but also offer far more choice and capabilities to developers in the form of real native apps?

And one other thing that I rarely see considered by the advocates of Firefox OS is how we're seeing more and more used iOS and Android mobile devices ending up in developing nations. They tend to be quite affordable and usable, even if they are somewhat outdated. Why would people in developing nations pay for a new Firefox OS phone, when they can get a used Android or iOS phone that may very well perform better than the Firefox OS phone, while offering a wider selection of apps, while also costing roughly the same?

Can you address these concerns?

The Rust mis-votings are quite absurd.

In no way can Rust be considered "stable". The most recent version is 0.10 (that is, it's still very pre-1.0), it's undergoing significant breaking changes on an ongoing basis, and even its home page warns that "Rust is a work-in-progress and may do anything it likes up to and including eating your laundry."

Anyone who points out that Rust is just not stable yet is absolutely correct. Anyone who points out that it's looking unlikely that it will be stable before the promised end-of-2014 deadline for 1.0 is also correct.

It doesn't matter who points out these facts, or how many times they do so. The facts are still facts, and whoever expresses them is totally correct.

My suspicion is that the inappropriate downvoting is just immaturity on the part of the Rust developers. I realize that it can hurt to face valid criticism of one's work, but an important part of being a professional adult is to consider such criticism rationally, and to learn how to improve based upon it. Engaging in censorship of facts, however, completely contradicts with self-improvement.

It renders the voting system useless when it's incorrectly used to censor others, due to a lack of emotional control on the part of the person misusing the system.

It's one thing to downvote blatant commercial spam that has no inherent value. It's harmful to downvote perfectly legitimate commentary that you may just happen to disagree with, however.

Don't worry about the downvotes. Things have gotten pretty bad around here lately, especially after the whole "downvote if you disagree" policy was encouraged.

A lot of totally correct and perfectly valid commentary ends up getting downvoted these days, often with no attempt made to explain why. It's particularly likely to happen when members of the Mozilla, JavaScript or Rust communities are involved. They're particularly sensitive to anything that might contradict their beliefs, and apparently they're particularly eager to downvote, for whatever reason.

These days, many of us have started to read all of the downvoted comments. Aside from occasional spam, they're often among the most insightful comments in any given thread.

That's obviously not what I wrote, and you would know this had you bothered to read my comment.

I'm saying that such features alone do not actually guarantee safety, if the language's implementation happens to have flaws.

There hasn't been sufficient time and opportunity to see what Swift is like in practice. It's premature to say anything conclusive about it at this point, aside from stating that we don't yet have enough information about it.

Right, that is an option, but it unfortunately involves some effort from the user. This is effort that wasn't needed before. In my opinion, having to expend this extra effort even just once ends up harming the user experience relative to what it was before.

Why is that comment getting voted down? Everything it states is true.

Rust isn't stable. It really hasn't seen any serious use.

Even the Rust home page itself currently states, "Rust is a work-in-progress and may do anything it likes up to and including eating your laundry."

I'd prefer to see how it fares in the real world before jumping to such conclusions like you seem to be so willing to do.

You may not have been around to experience it first-hand, but we heard a lot of claims made back in the 1990s about how Java and the JVM would increase security and safety.

The arguments made then even overlap with some of those being made in this case! The lack of direct pointer access and manipulation, automated memory management and better bounds checking are some examples of the arguments used then and now.

Yet if you work with computers at all, I'm sure you'd know that many of those claims did not materialize. Flaws have been found in the various implementations of Java and its VM, and these have affected its security and safety in very serious and significant ways, many times over.

Perhaps things are different in the case of Swift. But we won't be able to say for sure until later on, once it has undergone some significant real-world use.

Having been in industry for a long time, I think that something like Rust would be hugely beneficial. It very well could solve some very real problems.

I bring this up again and again because I'd rather not see Rust fail. I'd much rather see a slightly flawed Rust that's actually usable in the short term, rather than a continually changing Rust that nobody will seriously adopt.

Rust has been in development for years now. That's a very long time in the software industry. A few years of development time without a stable release is understandable. But it's getting beyond that now.

Rust isn't quite there yet, but each day it edges closer to a Perl 6 type of disaster. Perl 6 offered some intriguing ideas, but it just isn't usable, and that's a shame. Meanwhile, other competitors have arisen and blown past it, rendering it far less useful were it ever properly implemented.

Given the increasingly stiff competition that Rust is facing, I suspect we'll see it end up like Haskell or D. Something usable is eventually produced, but it never sees the truly widespread adoption that it could have seen, had it been usable earlier on. It's not as bad as Perl 6's situation, but it is still unfortunate.

I think it has.

Visually, the contrast is worse now than it was before. While this may be "trendy", it does harm usability.

The default coloring of the old results page was much easier to look at, as well. It made it easier to differentiate between the different types of content.

The fixed red bar at the top is distracting and pointless.

The auto-suggest is also wasteful and unnecessary. I find it contrary to the simplicity that DDG used to offer.

Yes, they're relatively minor changes, but they add up to result in an experience that just isn't as good as the previous experience. These types of minor, but harmful, changes can build upon one another over time, amplifying their negative effect.

I, and many others, do use something else. That's the big problem facing Rust, whether or not its creators wish to admit this fact.

There are numerous alternatives to Rust that offer many of its benefits, but they're usable today. We can rely on them today, tomorrow, and likely for some time to come.

And by this fall, we'll likely have Swift as yet another option to add to our growing list.

I think Rust has a lot of potential. But each month that goes by squanders that potential. It has less and less of a chance of making a real impact the longer it isn't usable, especially while its competitors keep evolving.

Well, we aren't actually seeing stabilization when it comes to Rust.

Assuming this stabilization actually does happen, whether it happens in public or private is irrelevant.

What matters is that we've seen C++ stabilize. We've seen Go stabilize. We've seen Scala stabilize. And now we'll likely see Swift stabilize, well before Rust does. They are all serious competitors to Rust.

As these other languages continue to evolve, but at the same time remaining usable, the relevance of Rust will continually decrease. It may still have drawing power today. A few years from now, it will have less appeal.

Resort to name-calling if you really must. None of that will change reality.

Rust is not stable, as you yourself have readily admitted. What I've unfortunately had to be pointing out for such a long time now is absolutely correct.

We've been told that we can expect Rust 1.0 by the end of the year. As each month passes, it becomes less and less likely that we will actually see this. We are still seeing significant change, even as recently as the past month.

I think Rust could potentially be very useful. But that requires stability, and that in turn is something that appears more and more elusive each day.

It's easy to say that Swift isn't a competitor to Rust, but the reality is that it is. And unlike Rust, it will very, very likely be usable for serious apps within a few months. It will see the adoption that Rust could have had, had it been usable, further reducing Rust's future changes.

Are you honestly suggesting that Rust is stable at this point?

I think that the recent, and very disruptive, ~ and box changes should completely dispel that notion.

I'm merely pointing out the reality of the current situation, which some in the Rust community do not wish to acknowledge, for whatever reason. The situation has yet to change, so what I'm saying is still valid, and will remain so until some actual improvement does take place.

Now that we see yet another serious competitor in the form of Swift, what I've had to unfortunately be saying for some time now becomes more and more relevant. If Rust is to become relevant, it will need to be usable, and that will need to happen very quickly.

I think you may be aiming for a level of safety, or perhaps a notion of "perfection", that isn't practically obtainable.

The recent, and rather disruptive, box changes are a good example of this. We see change, and those of us with existing Rust code sure do feel the change, but very little convergence seems to be happening.

Based on past trends, I would not be at all surprised if problems are found with the new approach as it becomes more widely used, and some other approach is then attempted.

Wheel-spinning is something that can quite easily happen with ambitious software projects. It's not a new phenomenon. But when facing ever-increasing competition, and other real-world constraints, it's often better to aim slightly lower and at least be mostly usable in practice.

A memory-safe programming language that can't actually be used is pretty much irrelevant. It's better to accept some slight amount of imperfection if that means it can actually be used.

One thing that worries me about DDG is their recent UI redesign.

It felt, and still feels, to me very much like the failed UI redesigns we've seen from Google as of late.

Even after giving it some time, I still don't think I'm better off with DDG's redesigned site than I was with its old design back at the beginning of May.

It may not be a complete UI disaster like the Google Maps redesign, for example, but it's still unfortunately a step in that direction. I sincerely hope this isn't a continuing trend with DDG.

My apologies, I didn't realize that expecting a programming language to have a stable syntax, stable semantics, a stable standard library and at least one stable and robust implementation before using it seriously in industry was merely a "game".

Perhaps this is news to you, but those of us who work on and are responsible for large-scale software systems tend to take such factors very seriously.

This may sound harsh, but it really doesn't matter what features and benefits Rust could potentially bring to the table if the lack of stability makes it unusable in practice today. A programming language that can't be seriously used might as well not even exist.

I don't doubt that Apple will have Swift available in a seriously usable form by this fall, and it's very likely that it will see rapid adoption soon after. I'm afraid I can't say the same about Rust and its supposed by-the-end-of-2014 1.0 release, given its current lack of stability and the rapidly-approaching end of the year.

I think you're putting words into his mouth, and perhaps intentionally misrepresenting what he wrote.

Swift was announced just a few hours ago. While we can make assumptions about its safety based on its feature set, or we can assume that the very vague performance details Apple provided are valid in a real-world setting, none of this has really been tested or verified independently yet.

What cratermoon wrote is perfectly legitimate. Let's try Swift out in the real world, perhaps for a year or two. Let's get some real data. Then let's analyze that actual data, rather than engaging in unsubstantiated speculation, or trusting some vague performance graphs shown in a conference presentation.

Yes, I do agree that the situation is improving across the board.

But as an industry, we need practical solutions that are available now, even if somewhat flawed. We need languages we can use today, and know that the code we write today will still compile fine next week and next year, if not a decade or more from now.

Modern C++ is getting pretty good at offering this, while offering far a greater degree of safety. Go isn't bad, either. Scala has its drawbacks, but it's often a reasonable option, too. The key thing to remember is that all of these languages have offered developers a stable target, and they are seriously usable in the present.

Given the announcement of Swift, and given that Apple will very likely deliver on it by the fall, we very well could see it becoming a major player during 2015.

The safety benefits that Rust could theoretically or potentially offer are virtually useless to huge swaths of the industry as long as the predictability of a stable release just isn't there. The longer this wait goes on, the better the competition becomes, and the less relevant Rust will unfortunately become in the long term.

What you're saying is perhaps ideal. The unfortunate reality, however, is that we really aren't seeing the "once Rust is mature" part actually happening.

There is still a large amount of change happening to the language and to the standard libraries. Some of this change has been of a here-and-there nature, where it's like they're trying to find an optimal or perfect solution that most likely does not exist.

C++11 (and C++14) may not offer the level of safety that Rust potentially could, but unlike Rust it's usable today, and using modern techniques does a reasonable job of avoiding dangerous situations.

It's been claimed that Rust will have stabilized and 1.0 will be released before the end of the year. Given that we're already into June, this becomes more and more doubtful each day. Now Rust is facing even more competition with this announcement of Swift. The longer we're forced to wait for a stable, seriously-usable release of Rust, the less viable Rust will become.

So what other language can we use today on basically any imaginable platform, while still retaining the extreme degree of control, the excellent interoperability, and the near-optimal runtime performance of C?

Some will say Rust, but we're years away from that being realistic. C++, using modern techniques, is perhaps the only feasible response.

While there may be some validity to your claim about "billions of human beings wasting hours" due to vulnerabilities in C code, we can't forget that the alternatives would also suffer from significant forms of waste.

If using a language with slower runtime performance, for example, people will need to wait longer for their computations to complete. More powerful, or even just more, hardware will be needed to alleviate these delays. Slower runtime performance also often results in much higher energy consumption. The costs just keep adding up and up.

Forcing billions of people to use far less efficient software, while requiring far more powerful hardware, on a continual and ongoing basis, for decade upon decade, could very well generate waste that far, far exceeds that of dealing with an occasional flaw in widely-used C code. I just can't seriously buy your "All the performance benefits ever derived from writing everything in C has been more than erased, by orders of magnitude, by the damage caused from even simple innocent mistakes." argument.

C won't be going anywhere until somebody provides a practical alternative that offers benefits without any downsides. It's as simple as that.

The similarity to Rust should scare the hell out of Rust's creators and proponents.

Swift could very well render Rust almost totally irrelevant within the OS X and iOS sphere of software development. If we end up eventually seeing Swift implemented for other platforms, then the chances of Rust's long-term success diminish even more.

Things might have been different had a stable, even if somewhat imperfect, initial version of Rust had been released by now, thus allowing it to gain some adoption and traction.

I hope that the "But Rust isn't targeting those developers!" argument isn't used to try to justify this mistake, as well. Rust is already facing stiff competition from languages like Go, C++11, C++14, Scala and even Java 8.

With the announcement of Swift, Rust's niche and audience are getting smaller, further preventing the widespread adoption that's necessary for a programming language to become truly successful.

Do you still have your original comment? If you do, you should seriously consider posting it.

It's difficult to discuss this topic with you if you intentionally avoid posting anything of substance, and instead throw out accusations of "ignorance".

If it was "forced", then she would have had absolutely no choice in the matter. It probably wasn't physical, as we've already determined. It likely didn't involve any sort of risk to her job outside of her control, as the original commenter clearly says, "She quit in her 3rd week."

It probably was the typical, purely-verbal, friendly coaxing that oft persistent Americans can engage in. That's what I'd consider "pressure". Aside from a brief and harmless verbal interaction, nobody is coerced into doing anything.

You may have to say "No" a few times, since they'll try to convince you to reconsider in a friendly manner. But they'll respect your decision soon enough.

It's really no different than going to a market in a developing nation, and having to fend off street vendors. They can be persistent, for sure, but there's absolutely no obligation to buy from them, and any interaction with them is almost always totally harmless.

I think this is "incident" is probably being misconstrued and totally blown out of proportion. Had she better understood American culture, and had she merely said, "No, thanks!" a few times, it would've been settled without any hard feelings.

I very much doubt it was a "requirement" in any sense. My guess is that the co-worker from India totally misconstrued the situation, due to not having a good understanding of American culture.

I could easily see the dialog being quite friendly, and going something like:

American: "Hey, that was one hell of a deployment, but it's done now. Let's have a round of drinks, to celebrate!"

Indian: "No, I don't want to."

American: "Awww, why not?"

Indian: "I've never had alcohol before. I don't want to."

American: "Come on, try it, it's fun! We do this after every big deployment."

Indian: "No, thanks."

American: "Okay."

The American thought he was being friendly and inclusive, by encouraging the Indian to participate in a pretty common American celebratory custom. The American was somewhat more assertive than the Indian was expecting, like many friendly and outgoing Americans can be. The Indian misinterpreted this as "pressure". She tells her Indian friend. He lacks a good understanding of American culture, too, and misinterprets the American's behavior. He posts here, and we have this discussion.