Next month's Firefox 48 is looking Rusty – and that's a very good thing Mozilla says it will next month ship the first official Firefox build that sports code written in its more-secure-than-C Rust programming language. The Firefox 48 build – due out August 2 – will include components developed using Rust, Moz's C/C++-like systems language that focuses on safety, speed and concurrency. It's hoped …
"No matter how good the replacement language is there will be legacy code around for decades written in the old language."
I know of no good replacements for COBOL. I often wonder if the poor performance of financial IT these days is down to those Banks feeling the need to move to the likes of Java.
Having just yesterday come across a bug report 15 years old, I have to ask: how far do their intentions go? Security... or relevancy?
The defining comment (Hixie(!) from 2002) in that bug was that, umm, paraphrasing, "all this was designed with the relevant C++ code so deep as to make the needed flexibility impossible." In other words, we can't fix the problem (can't respond to changes in CSS) "because C++".
So how far do their ambitions go? Will they use their new sparkly language facility to rewrite all the rotten guts that have caused bugs to be stuck on "this sucks, but we can't do anything about it" for years?
As it is, desertions proceed as people keep coming up against "can't fix", "won't fix", and "who gives a shit?" situations. Firefox has become the "sick man of browsers".
But... if they would use their new Rust as a catalyst, a spark to initiate change and rework/replace the underlying grunge, they could actually get people interested in helping them, new people! After all, everyone likes pyrotechnics, and with Rust they're halfway to some serious fireworks!
I'm not really sure if your comment has a point or is just a rant.
Yes, Firefox has had some horrible bugs around for ages. Yes, pretty much the whole development team has been replaced at least twice in this time. Yes, they've had lots of pet projects, UI fuckery and focus shifts. As have all the other browser makers. And your point is?
Rust is one of the more interesting projects to come out of Firefox and it will be interesting to see whether in the hostile environment of the internet it can fulfil its promise.
Some people seem to have no sense of proportion; any large codebase that 's been around for a while will have bugs that are a) minor and b) disproportionately hard to fix. And some of the ciomments are classic (paraphrasing slightly).
"What if the user doesn't want people messing with the UI".
"We are web designers, we don't care what the user wants."
When the revolution comes, these people will be first against the wall. Shooting them would be too good - I'll just paint it lime green with purple spots.
That is misrepresenting the bug and comment thread.
The bug is about having coloured scrollbars which use native widgets on the platforms, e.g. on OSX it uses the C based Carbon API.
The comment says coloured scrollbars require changes across the rendering layer, stuff all to do with C++.
It is different as in "has been done".
I am not sure how to define "prevent compilation of unsafe code", and even if that's theoretical possible. I am not a big fan of "let's create yet another language", but rolling one up with security in mind (and more, like concurrency) for this very purpose seems to be a fine idea to me.
The statement that the speed matches that the C++ code is IMO also good news.
It isn't cool. Today you need always a new language with a silly name, just it needs to be some variant of C/C++ anyway, or developers will be scared off if they don't see curly braces.
But it is true that C++ is often designed to meet more the convoluted theories of academics than to cover dire needs of developers - and that often leads to unsafe code and broad use of "tricks" to overcome design issues.
C++ loved by the pros, hated by the fakers.
There are blemishes like any language, but the arm chair, language researchers never mention anything even vaguely credible.
How about e.g. the generated assembly from a C++ program is a little harder to read than one written in C, and that is purely down to the heavily optimized STL implementations, applications that don't use the STL and do purely C style operations, will of course not have this issue.
I think your chief complaint, with C++ is that it's harder to pretend you know the language.
I learned C++ with Borland Turbo C++, that is, no C++95, no STL!!! It's a perfectly functional language (no pun intended).
I do hate that the response to "it's so hard to do this right" is always "get someone smarter to make a better language/compiler, so I don't have to improve my own skill set in any way!"
Software Development is truly lowering itself to the lowest common denominator more and more every year.
@hellwig there was no "C++95", the earliest standardization was ANSI in 1997, this was later ratified by ISO to become ISO/IEC standard 14882:1998 (hence called C++98). Bjarne's Annotated Reference Manual on the other hand is dated 1990, so you are not referring to that either. And C++ only very recently acquired functional capabilities (e.g. compile-time immutable data and functions, lambda expressions or std::function wrapper). Finally I do not know what you are referring to with "lowering to the lowest common denominator", as the new languages such as Swift or Rust are rather more refined than old ones, since they build on the experience on those who created these older languages. There is no "lowering the the common denominator" here, I think last such effort on creating a new language was PHP which is nowhere close to the topic at hand.
So, as you can see I am truly confused by your post above, care to explain?
@Bronek Kozicki
Yes, I meant C++98, I work with Ada too much (Ada 83, Ada 95, Ada 2005, Ada 2012, yay!). I was simply referring to the fact that Borland Turbo C++ (3.X and certain 4.X varieties) was absent the C++98 STLs. Rather than (as a high schooler learning to program) rely on "magical" (hidden) implementations of Lists, Sorts, etc..., we implemented our own directly in C++. As the whole point was to learn, not be overly efficient.
People are lacking that understanding, because modern languages and infrastructures are abstracting safety and security away from the developers. Therefore, when those same people revert to a more capable but less secure/safe language, you get C/C++ modules for FireFox written by people who don't have a proper respect for safe programming methods.
I'll restate this: It seems silly to me that the answer to "we're getting a lot of crappy code" is to have someone smarter make a smarter/safer language, instead of training people how to do it the right way in the first place.
Think of it this way: You have an assembly line assembling cars. One of the folks on your line forgets to tighten the lugnuts on one of the wheels every time. Do you a) train this person better, b) replace them with someone more competent, or c) design the car to drive on 3 wheels because "let's face it, wheels are gonna fall off".
Computer Programming is going the route of C) above, and that, to me, is lowering the standard.
And my "no pun intended" literally meant I was not trying to imply C++ was a truly functional language. I meant it functioned fine as a language.
I chose option d) design the car to make it more difficult to forget to tighten the lungs, which is not on the list. That's what new language design is about - to enable more robust software design, i.e. one where bugs stand out more, and correct programs easier to write than incorrect ones. This could be based on statistical observations (e.g. multithreaded programs usually work better if data passed between threads are immutable), or other collective experience of language designers.
Define "unsafe"? It's sort of difficult to do this without coming up with some kind of language specification which a compiler then implements. While it might be able to use the compiler for C, it looks like they have taken the opportunity to change the syntax and semantics as well, which like much of the Mozilla stuff, is heavily influenced by Python. Presumably the idea behind this is to encourage a particular programming style which reduces the number of errors that the compiler has to pick up.
The Rust docs contain further information: https://doc.rust-lang.org/book/bibliography.html
How is this different to having an improved compiler for C
Short answer: very different. Yes in theory it is possible to add all kinds of checks to C compiler, but the result of this would be that any sane C programmer will call the resulting limitations unreasonable, and for good reason. It would be very difficult to write any program in C with checks as restrictive as the ones built into Rust.
In case anyone wanted to ask "so how is it possible to write any program in Rust" the answer is simple : it is a different language, so it can provide syntax for safe alternatives, without having to worry about syntax compatibility with C compilers. The need to maintain this compatibility is what really hamstrung the evolution of C++ language (in 21st century i.e. C++11 and after), but Rust has no such limitations.
On esr, had to rollback to 38.8 after the 45.2 replacement disabled all my add-ons (possibly not CTR), without any chance to abort.
Looking for a good replacement, with devs who care about the user, not Chrome, Otter, or Qupzilla.
Realistic suggestions for 64-bit Linux please.
... and why would anyone do it? The whole point of using specific language is to match the desired design (sometimes architecture) with tools available. The language informs design of the project, because it is created to support certain design constructs. By converting between languages you are losing the benefits of this design match and gain nothing, with the only exception when using lower level language as object file format. But Rust is high level language, so the conversion to Rust will not buy you that.
Unless of course the answer is "for fun" in which case, sure why not.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
