Mozilla’s Rust is one of the many programming languages that is available for development professionals in today’s modern technological environment. First bursting onto the digital scene in 2012, Rust is heavily influenced by languages like Napier, C++, Common Lisp, Erlang and more. Rust is the brainchild of a Mozilla employee by the name of Graydon Hoare. In the years since it has been described as one of the most safe and practical programming languages currently available. The question of whether Rust is right for your next project, however, remains to be seen.

There are a few important factors regarding Mozilla’s Rust programming language that you’ll definitely want to consider before making a decision regarding your next big project.

Design and Core Functionality

Since its original inception, the goal of the Rust programming language has been to expedite the creation of both server programs and large client programs that run over the Internet. As a result, the design and core functionality of Rust emphasize both safety and control above all else. The Rust programming language is also designed to be memory safe, which means that by design it aims to completely eliminate the types of bugs that traditional lead to security vulnerabilities where RAM is concerned. Buffer overflows, dangling pointers and other issues that regularly plague other programming languages are under careful supervision with regards to Rust.

Syntax

One of the major considerations of any programming language has to do with the syntax being used. Syntax is a term that refers to the way that words, symbols and other characters must be arranged to create the sentences that make up the backbone of the language itself. By its very design, the syntax of Rust is incredibly similar to that of both C++ and C, meaning that anyone proficient in those languages should have no trouble adapting to the syntax of Rust. More specifically, blocks of code are delimited through the use of braces. Keywords like “if,” “while” and “for” also make appearances in Rust. Not all keywords that you might be familiar with from C++ are accounted for, however, like the “match” command.

The Type System

One of the biggest attributes of Rust is its type system, which it refers to as “traits.” The Rust developers have made no secret of the fact that these traits were directly inspired by the Haskell programming language. Variables that are used with Rust don’t necessarily have to be assigned a value to determine their type, though a compile-time error will occur if code fails to assign a value to the variable in question when it is in use.

Update Frequency and Type

Because Rust is still a relatively new programming language, it is still readily supported by its original developers. If you’re planning on using Rust for your next big project, however, you’ll soon find out that this means both “good news” and “bad news.” The good news is that new versions of Rust have been released several times a year since 2012. 2014 alone saw the release of versions 0.10, 0.11 and 0.12 in April, July and October, respectively. The “bad news” as some will no doubt interpret it is that Rust is still evolving in a pretty dramatic way, which can mean significant changes every time a new version rolls around.

The style of the object system that Rust uses changed significantly between versions 0.2 to 0.4, for example. Classes were first introduced in version 0.2, though by the time 0.4 was released traits were now added to provide inheritance and classes were removed completely.

Mozilla Firefox is turning ten years old and to mark the occasion the company has designed a special present for the people who essentially run the Internet on a daily basis: developers. Originally released in 2004, Mozilla Firefox quickly rose to prominence as a reliable, secure and lightweight alternative to Microsoft’s Internet Explorer. Though its user base was initially small in comparison to Internet Explorer (thanks largely to the fact that Microsoft bundles its browser with every copy of the Windows operating system), its support has grown astronomically in only a decade. Mozilla has recently released the Firefox Developer Edition, which has a wide variety of different benefits that can’t be ignored.

For Developers, By Developers

Mozilla is touting the Developer Edition as the world’s first web browser that was designed specifically with other developers in mind. It’s graphical user interface has been created from the ground up to support the types of activities and the workflow processes that these individuals go through on a daily basis. It’s a browser that allows developers to build sites and apps, test their work, scale to specific requirements and complete other types of activities all from the same application. Though these components were possible before the release of the Firefox Developer Edition, it usually required a great deal of multitasking and moving back and forth from separate programs.

Debugging

One of the major benefits of the Firefox Developer Edition has to do with the wide range of different options it provides to developers with regards to debugging. Many of these features are possible thanks to a single built-in extension called Valance. Valance allows developers to both inspect and debug an app or site across any type of browser or device that a user may be viewing it on. When a user views an app on the iOS operating system (which is found on all Apple devices), for example, it should naturally respond differently than if the user were viewing the same app on Android. Valance natively has support for these types of systems and more, allowing developers to complete all work from a single point of access.

Another major benefit of Valance is that it includes compatibility for all of the major operating systems in use by users today. Support is extended for Chrome for Android, for example, as well as the mobile version of the Apple Safari browser that is currently installed on every iOS device in existence.

Coding

Another major benefit of the Firefox Developer Edition is the great deal of different options that it provides users with regards to coding. The Developer Edition is capable of allowing everything from simple Javascript to Responsive Web Design and more thanks to a built-in Style Editor. Also commonly referred to as RWD, Responsive Web Design is the concept that the needs of users will change based on the device they are using an app on, which means that the app itself needs to automatically adapt to provide for the best possible experience.

If a user is browsing a site on a desktop computer, for example, they are both using a mouse for navigation and using a large format browser on a large screen monitor. The layout of the page should automatically change when the same content is viewed on a touch screen device like an iPhone or iPad. The built-in Style Editor allows developers to automatically account for these types of changes. Additionally, they can experience the way their content will look and feel in different environments automatically to make sure that they’re always putting their best foot forward.

Earlier this year, Mozilla announced plans to create a web-based OS that would help developers create mobile apps that function across multiple operating systems. The company plans to begin testing this quarter and have more advanced functionality completed next year. Check out the details on TechWorld:

Mozilla developers to test Boot to Gecko mobile OS

Mozilla developers hope to start testing phones running its new mobile operating system this quarter, with product demos slated for the first quarter next year and production set for before June 2012, according to a road map on the project’s website.

Mozilla announced the project, called Boot to Gecko (B2G), in July, describing it as an operating system for mobile devices that would run applications primarily on the web.

Developers hope B2G will help solve a problem that has long plagued the mobile industry: Developers must rewrite apps for each operating system. The goal of B2G is to create a framework that would let applications run from the web on any operating system, provided the OS supports B2G’s technology.

By the end of this year, the developers hope to have basic functions built and integrated including the accelerometer, camera, messaging, telephony and power management, according to the road map recently posted on the site.

uTest: In many ways, mobile is still playing catch up to the web. Is there one area in particular where you see the most room for improvement? If so, where?

ME: Well, there are some obvious platform deficiencies around inconsistent UI and whether Flash is going to be fully supported across mobile devices or not. But this is a testing blog, so let’s talk about that. As I mention elsewhere in this interview, mobile is just a really tough testing challenge. The big problem is that there is very little support for cross-platform mobile device test automation. I suspect most of mobile device and application testing is done 100% manually. If any environment needed more test automation, it is mobile. At Palm, we rolled our own test harness that ran on the Pre. This became extremely important for endurance testing and finding memory leaks in the Pre applications.

Mobile software companies have an uphill battle since developing automated system tests for every platform is very costly, both in time and resources. However, reliance on mostly manual testing has lots of quality risks. If the quality of mobile devices and software is to rise about what it is now, we need automated test tool support that works well across all device platforms.

The uTest Blog has just published Part I of a two-part interview with Matt Evans, QA Director at Mozilla. Prior to his role at Mozilla, Evans was a key player at Palm, where he managed the quality program for the WebOS Applications and Services of the Palm Pre smartphone. You should read the entire interview, but here are two questions he answered specific to mobile app testing. Enjoy!

uTest: You were the QA Director for Palm when they launched the Palm Pre Smartphone, as well as the WebOS apps and services. What’s been the biggest difference (if any) between launching a mobile product and a web product?

ME: The biggest difference between a web product and mobile device is the amount of testing and certification that must precede the launch of a mobile product. A smartphone such as the Pre is an incredibly complex and highly integrated piece of technology–much more so than a typical web application. First off, a smartphone contains a fully-functional OS, usually based on some variant of Linux running on very constrained hardware. It must perform all of its concurrent services utilizing limited memory and limited CPU horsepower. The smartphone must also respond correctly to the multitude of many current events, from those generated from the environment–like switching from wifi to a WAN internet connection–to handling data input from the user, as well as handling events from the onboard applications.

Launching a mobile product requires exhaustive certification of individual hardware components such as the CPU, modems, codecs, and displays. Even then, the finished product is really launched by the carrier and must go through their exhaustive certification tests as well. Testing an onboard mobile application is also a much harder testing task. There are so many conditions and constraints that are involved in testing a mobile application.

A typical mobile application is nearly functionally equivalent to any counterpart desktop client-side web application. Take, for example, a mobile email application. It must behave and interact with the server-side application in nearly the same way as a desktop web client. The established protocols were designed for a stable communications environment, but this is just not the case in a mobile environment. The internet connection may be lost and reconnected very rapidly. The connection may even be lost for long periods of time. The application may, at any moment, be swapped out of memory. The system may be shut down abruptly. Lots of system conditions happen in a smartphone that would rarely or never happen in the context of a desktop web client application. However, a mobile application must perform its main functional operations of retrieving and sending messages flawlessly with no loss of data and full operational integrity. Testing mobile applications under these environmental scenarios is a huge challenge. In short, testing a web application is no easy task, but mobile applications and products represent a much tougher and larger testing challenge.

Not too long ago, we blogged about the developments surrounding Fennec – Mozilla’s “Firefox for Android.” Here’s a rather harsh update of their progress (or lack thereof) from blogger Sean Michael Kerner:

So here we are more than two years after Mozilla kickstarted its mobile efforts, and they’ve announce the first beta for Firefox 4 Mobile on Android and Maemo. So forgive me for not being too excited about the this new beta, I’ve heard this song before.

Sure, there are differences this time around. Firefox 4 is a superior browser to the base that Mozilla developers first started with for Fennec and yes Android is likely the best target they’ve ever had for a mobile platform with vastly more users than Maemo (isn’t that supposed to be MeeGo now?!)

The ability to sync desktop and mobile is a great idea and that’s likely the ideal use case scenario under which Firefox 4 Mobile will thrive on Android devices. For iPhone users, there is no Firefox Mobile, but they can benefit from the Firefox Home application instead.

Choice is always a great thing, though in my experience the Android web browser is already a fast and very capable technology. It’s not like Windows users with IE that really need another option, Android users aren’t exactly suffering. Blackberry users, now that’s another story — I haven’t seen any effort from Mozilla to target that platform (and likely won’t either).

MobileCrunch picked up the news that Firefox Home – what they call the “almost-a-browser” – is now awaiting App Store approval. That’s great, you’re thinking, but what the heck is an “almost-a-browser”? Here’s Simon Chester with an explanation:

Well, rather than just being a Safari replacement, Firefox Home acts as a bridge between your desktop version of Firefox and your iPhone. This is crucial, as apps that duplicate functionality of native iOS apps without adding anything new are a no-no in the App Store approval process.

It uses the Firefox Sync extension to sync your (desktop) Firefox bookmarks and history with your iPhone, and – more interestingly – will allow you to slide tabs open in Firefox over to your iPhone, much like Google’s Chrome-to-Phone functionality in Android 2.2.

You can search for and view any of the pages in your desktop bookmarks or history, as well as view the tabs open on your desktop copy of Firefox, right on your iPhone. Once you’ve found the page you’re after, you can view it either in Safari (an Apple-friendly move), or from within Firefox Home (which may upset Apple). You can also send the links via email.

Make sense? If not, and you’re one of those “visual” learners, here’s a video demonstration:

Exciting news from the mobile front yesterday, as developer Vladimir Vukićević announced that a more usable “pre-alpha” build of Firefox for Android (aka Fennec) is now available to a “broader set of people.” As you would expect from a project in such an early stage, there a number of bugs and other issues that still need to be resolved. Vladimir acknowledges as much in the post, offering a number of specific examples. Here are few of them (verbatim):

It will likely not eat your phone, but bugs might cause your phone to stop responding, requiring a reboot.

Memory usage of this build isn’t great — in many ways it’s a debug build, and we haven’t really done a lot of optimization yet. This could cause some problems with large pages, especially on low memory devices like the Droid.

You’ll see the app exit and relaunch on first start, as well as on add-on installs; this is a quirk of our install process, and we’re working to get rid of it.

You can’t open links from other apps using Fennec; we should have this for the next build.

Here’s the second part of Jigar Patel’s post on mobile web app testing.

Safari and Mozilla Firefox support some great extensions that can make testing your mobile sites on desktop browser much easier. You can get more details here.

Testing mobile applications on the desktop browser, as mentioned, does provide several major advantages. Let me illustrate: From the browser metrics of the application, prepare a list of user agent strings for each browser in your metrics. User agent strings can be easily found through a Google search. From there, setup the Firefox browser to test with mobile application as mentioned in this article. Then, set the user agent sting in Firefox for each device, one by one, and navigate to the sign-in page of the application. See if the site renders the mobile version of the application or the PC version if available. If it does, then we are on the right path, and there is a good chance that real handset seating on the end user hand will redirect to the correct mobile version of the site.

If it renders the PC version of the site, this could be a bug in your application. If so, there are less chances for handsets being supported by your application, provided that it doesn’t render the mobile version of your site. Be sure to document each browser on which this behavior occurs and ask dev to fix it. If it can’t be fixed, then there is less of a chance that the real handset will support it. At this point, we can make the decision to cut down the devices/browser from the metrics which doesn’t redirect to the mobile version of the site. Now you can understand the advantage of testing on a desktop browser, that we can kick out the devices from this analysis before purchasing it to test and hence it will help to reduce the cost!