Slashdot Mirror
Mozilla Binds Firefox's Fate To The Rust Language (infoworld.com)
An anonymous reader quotes InfoWorld:
After version 53, Firefox will require Rust to compile successfully, due to the presence of Firefox components built with the language. But this decision may restrict the number of platforms that Firefox can be ported to -- for now... Rust depends on LLVM, which has dependencies of its own -- and all of them would need to be supported on the target platform. A discussion on the Bugzilla tracker for Firefox raises many of these points...
What about proper support for Linux distributions with long-term support, where the tools available on the distro are often frozen, and where newer Rust features might not be available? What about support for Firefox on "non-tier-1" platforms, which make up a smaller share of Firefox users? Mozilla's stance is that in the long run, the pain of transition will be worth it. "The advantage of using Rust is too great," according to maintainer Ted Mielczarek. "We normally don't go out of our way to make life harder for people maintaining Firefox ports, but in this case we can't let lesser-used platforms restrict us from using Rust in Firefox."
InfoWorld points out most Firefox users won't be affected, adding that those who are should "marshal efforts to build out whatever platforms need Rust support." Since most users just want Mozilla to deliver a fast and feature-competitive browser, the article concludes that "The pressure's on not only to move to Rust, but to prove the move was worth it."
What about proper support for Linux distributions with long-term support, where the tools available on the distro are often frozen, and where newer Rust features might not be available? What about support for Firefox on "non-tier-1" platforms, which make up a smaller share of Firefox users? Mozilla's stance is that in the long run, the pain of transition will be worth it. "The advantage of using Rust is too great," according to maintainer Ted Mielczarek. "We normally don't go out of our way to make life harder for people maintaining Firefox ports, but in this case we can't let lesser-used platforms restrict us from using Rust in Firefox."
InfoWorld points out most Firefox users won't be affected, adding that those who are should "marshal efforts to build out whatever platforms need Rust support." Since most users just want Mozilla to deliver a fast and feature-competitive browser, the article concludes that "The pressure's on not only to move to Rust, but to prove the move was worth it."
What's with all these other languages lately?
Courage is not removing the headphone jack. Courage is switching to a new systems language because the existing one, while good, just doesn't allow them to reach th quality level they want.
SJW n. One who posts facts.
Best of all, if you have a problem with Swift, you can tailor swift to your needs and shake it off.
Yeah yeah. You guys have been saying that Rust will replace C and C++ for 7 years and yet it's still a toy that next to no one uses outside of Mozilla.
Yes
And why aren't they using Swift which is the de-facto best choice for next generation systems languages?
Rust a) has been around longer; b) was developed by Mozilla; c) focuses on security of web engines; and d) is strong enough for system programming.
Swift was a reaction to Rust, bringing some of the features and simplifying the Obj-C Syntax. It was designed with the Apple environment in mind and doesn't (officially) support windows. Swift as a choice makes zero sense as there is no real benefit as Mozilla is no longer trying to be hip.
Mozilla is taking a risk and betting on the future of hostile internet - and users actually giving a shit about security.
[Rent This Space]
A browser nobody uses written in a language nobody uses.
Quick, let Dropbox know no one uses Rust. I mean they went and re-wrote their entire back end in it. If only they thought like you such a crisis could have been averted.
Yeah yeah. You guys have been saying that Rust will replace C and C++ for 7 years and yet it's still a toy that next to no one uses outside of Mozilla.
Right? I mean we all know if it doesn't replace it overnight it's a worthless language. I mean Python was a total failure, people still use Perl for crying out loud!
Nobody uses Dropbox, though.
Yeah, if you go back a few weeks and read the interview with the designer of the swift language, you'll see he disagrees:
- While obviously praising swift, he says it's not quite there yet for systems level programming.
- He thinks Rust's safety features are great.
Some people use it.
https://www.rust-lang.org/en-U...
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.
No other modern language is capable of safety and is low level enough. I saw one comment here asking why no swift, well for starters it has no concurrency or parallelism primitives which are a necessity for a systems language. Certainly for whatever language you want to write a browser in...
That seems like a strange assertion to make given that C has, and C++ until recently had no concurrency or parallelism primitives, and are the de-facto systems programming languages at the moment.
It also seems like a strange assertion when Swift by default ships with Grand Central Dispatch, which gives it strong concurrency and parallelism support.
The issue with swift as a systems programming language is that its compiler output is too magical. Several of its features can cause weird and unexpected perf implications when used in subtly different ways. For example, it's generics implementation can end up compiling down to either fully dynamic dispatch, or just normal C function calls depending on whether the compiler analysis could figure out which types you were using, when, and how often.
There are several forks. I'm typing this in Palemoon, a fork that didn't go along in the chromification process.
is basically a wholly owned subsidiary of Mozilla. This whole thing smacks of eating your own dog food. As long as their support for the big 3 (Windows, OSX, Linux) isn't impacted I suppose it won't matter much. But if it even means waiting a bit for patches on Ubuntu or Red Hat then expect Chromium to eat what's left of their lunch.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Uh, nope.
From WIkipedia:
(emphasis added)
However, I'll grant that LLVM is written in C++.
-- Alastair
Reminds me of trying to get stuffit installed on an old Mac. Nobody ever supplied stuffit as an executable, it was always compressed.
Only the State obtains its revenue by coercion. - Murray Rothbard
Swift was a reaction to Rust
Also worth mentioning that three of the major contributors to Rust now contribute to Swift, Rust's founder Graydon Hoare included.
The language is better overall, as it doesn't include these many compatibility cludges, and many of the stability breaks of Swift over the recent time brought it closer to Rust, meaning that Rust did something right, but if Apple has more money and they really want to establish it as the new systems programming language, there is nothing stopping them.
Apple also has all the iOS developers behind them, a gigantic shepherd of developers who will use whatever tools apple commands them to use. They all are coding swift now. While Mozilla does have internal developers, and also offers interns to hack on Rust projects, they obviously don't reach the number of people that Apple commands.
Also, I think Rust has a steeper learning curve than Swift. This might make it harder for beginner programmers to get the language.
That being said, I think the steeper learning curve is justified and with Swift you have to pay back later on with harder to understand codebases, and harder to localize bugs. Still it will hurt Rust's growth at the start, and this might become an important factor.
I repeat, I think Rust is the better language. It is well thought through and puts the emphasis on safety, which matters everywhere I think. But you have less job postings with Rust than with Swift, and its short to mid term chances are dimmer than the chances for Swift are.
Let's see what the future brings us. I hope that Swift is a successful successor for objective C and flourishes inside the apple bubble. And for Rust I hope that it conquers everything outside of that bubble that isn't occupied by legacy C/C++ codebases and dynamic language use cases. Its an exciting time ahead for sure.
Given the quality of our comments recently, here is a good presentation with some actual information on their work currently and going forwards: Servo Architecture: Safety and Performance.
Well, I use Firefox. It's relatively stable these days, plus I don't have to keep checking my eye sockets to determine whether my eyeballs have been sold to the highest bidder -- which is more than I can say for most alternatives these days. Plus, with a small user base, it's become less of a target for malware authors too. Win-win if you ask me.
A browser nobody uses written in a language nobody uses.
I don't use rust. Never even bothered to look at it.
But your post was so trumpian I figured it was probably alt-facts.
So I spent 30 seconds checking with google.
Looks like lots of companies are using rust in production.
A browser nobody uses written in a language nobody uses.
Quick, let Dropbox know no one uses Rust. I mean they went and re-wrote their entire back end in it. If only they thought like you such a crisis could have been averted.
And Twitter was originally written in Ruby, and Orbitz was written in Common Lisp.
And time passes, and both are rewritten to C or Java or something, and neither Ruby nor Lisp is a very commonly used language.
Don't get me wrong, I'd love to see Rust succeed, but the QWERTY effect, or "popular for being popular", is a pretty tough nut to crack.
Why does the incompetent bozo CEO still have a job?
The company is swirling the drain and in a couple more years it will be flushed.
So many stupid things: 1) monthly releases, 2) loss of user customization, 3) "features" nobody wants (pocket, sync, extension signing, etc), and 4) spyware "telemetry"
One day they will use Mozilla as an example in business classes in college of how to run a company down the toilet.
" Not to mention that it has even taken much longer for big changes in C++ to be adopted than Rust has existed"
And the reason for that is TESTING. That's right, the people that made C++ actually bothered to test this shit themselves, instead of just releasing shit to people to test because they're too fucking lazy to do it themselves, like 95% of programming languages made and released today.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
don't create any Bad Blood
Someone who has truly mastered their craft may perfection 99% of the time. Or not - Tom Brady completes 64% of his passes.
Suppose the Firefox programmers were the most competent human beings to ever walk the earth, and got it right 99.99% of the time. With 14 million lines of code, they would have 14,000 flaws.
On the other hand, if the Rust string handling functions don't permit buffer overflows, they don't permit buffer overflows - ever. You can't write a buffer overflow in a language that doesn't use buffers. Not only will there not *be* such errors, but you can *prove* there are no such errors, you can trust it.
I don't have any opinion on Rust specifically, good or bad. I'm sure it has tradeoffs. The idea that you shouldn't use reliable tools because humans should just be perfect os silly.
What am I supposed to see about Go?
7 years is "overnight"?
Mozilla is tackling the security of the OS, like buffer overflows, while the attackers are tackling the security of the web, like tracking users, using csrf and similiar stuff.
Mozilla should start with tuning firefox for privacy. The typical problem with a buffer overflow is a crash. Even when they get user privileges, they won't find much interesting on most user's PCs. The interesting stuff happens in the Browser. The Webmail-Login is more valuable to the average user than the few files in his user profile. The Facebook Login worth more than the PC, which can be replaced by a tablet, when it becomes slow because of viruses.
Of course this isn't true for every user, but for the majority. And mozilla should not stop fixing bugs and programming for security, but actually inventing a new programming language to fix potential issues arising from wrong usage of C is just overkill. Of course you can do it, if you have too much time, but then i point at the bugtracker with seven figure Bug-IDs.
You've forgotten about the existence of iteration. Your assumption is they only have one chance ever to write a piece of code, and that it is never reviewed by another coder, or even the original coder after it's been written. You assume the code is never refactored, or passed through static check tools or other forms of analysis.
All those moments will be lost in time, like tears in rain.
I run Funtoo Linux, a source based distribution. I compile Firefox without issue. Actually, I've had more problems with compiling Chromium than Firefox.
The idea that you shouldn't use reliable tools because humans should just be perfect is silly.
I'm not advocating that at all, but Rust will have flaws (and limitations) too. It's a trade off, maybe a good one. But saying we need to Rust because "human's haven't got the brains to write secure code" (from the original post) is dumb. And, sure, Rust may "improve the situation by enforcing things that humans get wrong", but people can learn to get those things right too so it's not the only option. Good tools can be helpful, but they almost always come with a price. In this case, more limited distribution. If that's a price Mozilla is willing to pay (and it seems they are) so be it. Note: They seem willing to pay (give up) a bunch of stuff to pursue whatever their long-term goals are.
It must have been something you assimilated. . . .
But the tools are still too unstable. Language and library features change from one compiler version to the next.
The changes are backwards compatible. Freezing of certain APIs, addition of new features.
And compilation is slow as shit.
Compilation speeds have improved substantially. And the retort is to say that finding and fixing bugs in the field is way more time / money costly than stopping them from happening in the first place.
Try compiling a simple hello world with Rust or GCC. The difference is staggering. (at least it was about 6 months ago)
The difference in what? Speed? I was able to create, compile and run a hello world program in under 4 seconds.
cargo init --bin
Created binary (application) project
cargo run
Compiling hw v0.1.0 (file:///C:/Temp/hw)
Finished debug [unoptimized + debuginfo] target(s) in 1.40 secs
Running `target\debug\x.exe`
Hello, world!
Or are they going to use rust to compile only 1% of the code, in which case they are complicating their build for no reason.
Every time Mozilla crashes because of dangling pointer, data race or some other avoidable problem caused by using C++, that's a reason. Every time someone finds a way to exploit the browser by causing a buffer overrun, stack overflow or whatever, that's a reason. Every time the browser runs stuff sequentially instead of in parallel due to the complexity and risk of data races is a reason.
There are plenty of reasons to use Rust. And Mozilla's ambition is more than 1% of the code base. Look at the Servo project which aims to replace all of the browser engine with Rust.
Rust *may* be more secure, I haven't used it enough to be sure. It's certainly a lot bigger pain to use, and it only supports *some* mechanisms for secure concurrency. If I wanted to use an actor model I'd need to drop into C, which sort of makes an end-run around their claims of security. Even in there dining philosophers tutorial there's a comment about having to reverse one of the conditions to avoid deadlock. I guess that you can claim deadlock isn't a security problem, but...
OTOH, Swift is still tied heavily to Apple. I know it's been opened, so perhaps in a few years it will be a reasonable choice, but not yet.
You wouldn't believe the amount of effort I've put in trying to avoid using C++, but I've been forced back to it despite everything (including it's horrible travesty of "how to handle unicode").
I think we've pushed this "anyone can grow up to be president" thing too far.
I thought it went.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
That bizarre cathedral guy, Eric Raymond, is busy cleaning up NTP for security and recently evaluated Rust as a possible language for a complete re-write and found it deficient. His blog posts on that:
"Rust vs. Go"
Rust severely disappoints me
"Rust and the limits of swarm design"
Ceci n'est pas une signature.
I'm guessing, from your ID, that you have a copy of the dragon book. I know, from your comment, that you've never read it.
Open it up to page 24, and start reading. This is a long-solved problem.
R.I.P. Firefox. It was fun while it lasted.
Hey now, don't be glum!
The upside of this is that once Mozilla shakes those last "hanger on" users, they can turn out the lights and go home...
Carbon Footprint reduction via corporate self euthanasia!
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
It may be nothing new, but it's also a weakness (as well as a strength). I've run into multiple languages that went in for self-hosting and eventually became dependent on a binary version because someone lost the full build chain. The solution is to maintain a sub-language that is can be built from something simple, like C.
N.B.: Languages aren't all major languages. One of the languages I'm thinking of was, IIRC, BC-Algol, which was compiled to a reverse-polish intermediate code which was executed by the interpreter. It was never ported off the 7090-7094 DCS system because it wasn't worth rewriting some important part of it. (It *could* have been done, as the lost part was simple enough, but Algol was dying anyway at that time so it was never done.)
But the point is, you've got to maintain the sub-language that your "self-hosting compiler" is written in. If the language becomes popular this isn't a major problem, because you need to use it well with every iteration. If it isn't, though, you can just ignore it until it dies of bit-rot, or you lose the tool-chain, of your backups fail, or... Mozilla is probably a major enough user (now?) that this won't be a big problem, and will be primarily a source of strength, allowing easier porting to alternate systems...but it *is* also a weakness.
I think we've pushed this "anyone can grow up to be president" thing too far.
But there's also a language that the bootstrap C compiler is written in. C is simple enough that this is usually assembler, and the bootstrap C compiler isn't really C, but rather a subset of C.
I think we've pushed this "anyone can grow up to be president" thing too far.
C and C++ had until recently no standardized concurrency or parallelism primitives. Most systems had non-standardized libraries. Even yet there aren't any standardized methods for handling multiple processes, only multiple threads. But I'm not going to claim any other language is any better.
I think we've pushed this "anyone can grow up to be president" thing too far.
Why is this modded Troll? Admittedly my understanding of the amount of RAM required was out of date - 8GB is recommended and a 2GB absolute minimum is required. It requires 30GB(!) of disk space:
https://developer.mozilla.org/...
"When information is power, privacy is freedom" - Jah-Wren Ryel
"We normally don't go out of our way to make life harder for people maintaining Firefox ports--just plugins!"
The trouble with C/C++ is the requirement to not break old code. This prevents fixing basic problems. E.g., raw pointers should be eliminated, not just discouraged. Something should be done to allow generation of better error messages. The template system is horribly ugly. Etc.
So sticking with lineal descendants of C/C++ requires embedding lots of really bad decisions into the language. OTOH, people inventing a new language tend to make excessive changes. It always (nearly always) makes sense for some use case, but it lacks the generality. Even D, which I much prefer as a language, lacks the generality of C/C++, to the extent that I'm currently being forced to pick up C++ after staying clear of it for over 2 decades because of various defects. (And I'm really feeling the strain of trying to pick it up. I'd almost rather pick up Ada.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Last time I tried chromium it couldn't properly handle my bookmarks. So far FireFox can, though they keep trying to get rid of them.
I think we've pushed this "anyone can grow up to be president" thing too far.
The Accidental Tech Podcast had an interview with Chris Lattner where he discussed the future of Swift as a systems language and compared it to Rust. Rust has a very upfront memory ownership model that requires programmers to be explicit about memory management. This allows Rust to have great performance and allows the compiler to ensure memory is used safely that is not an option with C.
With Swift, either you pretty much don't think about memory (it uses Automatic Reference Counting so you only need to care about cycles), or you need to go down to C-style memory semantics with the various Unsafe constructions. There are cases where you could get much better performance because the programmer knows the lifecycle of the objects being used, but that can't currently be expressed in Swift. It can be expressed in Rust.
To be a good systems programming language, Chris said that Swift will need to create a memory ownership model (and mentioned Rust as having ideas that might apply). He would like that ownership model to be opt-in for specific pieces of your code that require it: most people could use ARC, while people that need performance in a specific piece could be more detailed about the memory management. It's on his list of things that Swift will acquire over the years so it can achieve world domination.
So there are really pretty good reasons that Mozilla put together Rust. The browser is probably the most widely exposed attack surface right now, and the history of buffer overloads means there needed to be a safer way to code.
So in order to build Rust, you must have... Rust. Chicken-and-egg omelet, anyone?
That's unheard of! I always bootstrap my C compiler by hand. This self-compilation thing is never going to work.
Ezekiel 23:20
Where did you get the impression that Orbitz is being rewritten in something else than Lisp? Aside from some front-ends being added or maintained, of course.
Ezekiel 23:20
Just make your engine render pages fast and correct, fix security bugs
So you want Servo. Great, but it's being written in Rust.
Ezekiel 23:20
No matter what Mozilla does or doesn't do they get criticized here, it might be different people criticizing different things but still...
This AC hates this Rust idea and wants a faster browser not new features. Well, Servo and the Rust projects is exactly about that: a faster, smoother, safer browsing experience, not new features.
And you imply that when code is revised, flaws are always removed and never added?
Chrome with 2 tabs (feedly and slashdot) is currently at 1.3 GB. Granted, I have a few extensions installed, but it's still ridiculous. Chrome was really lean a few years ago, but these days it eats memory like candy.
What about proper support for Linux distributions with long-term support, where the tools available on the distro are often frozen, and where newer Rust features might not be available?
For a really "L" TS distro like Debian it shouldn't be an issue because the vast majority of deployments are server instances, not desktops. For less "L" TS distros like Ubuntu, they are not so old (e.g. the current 16.04 LTS Ubuntu is much newer than Debian Jessie), and there is always the possibility to just add a custom archive to deal with it. In fact if you install Opera or Vivaldi from the official .deb's they distrubute, that's exactly what they do: They set up their own PPA.
Not sure, but I read a while back that the back end was being rewritten to C or C++.
Someone who has truly mastered their craft may perfection 99% of the time.
May what perfection?
systemd is Roko's Basilisk.
Sounds like its only used for COMPILING, not runtime.
So wtf, is the point of rust? I am sure perl would work equally as well.
Liberty freedom are no1, not dicks in suits.
> "human's haven't got the brains to write secure code" (from the original post) is dumb.
A posteriori, they don't. We tried that and in my database I have 90,000 examples of their failure to do so.
Yeah, so how many wankers use a 45meg library to read a 1kb XML config file, when you could have just made a simpler ascii format and wrote the code your self. Or your lazy coders who use sqllite for tiny configs, as you cant code for shit to store csv config files.
No wonder 2gb android with quadcores runs so shit compared to a 500mhz windowsXp box from year 2001.
Liberty freedom are no1, not dicks in suits.
Firefox is open source, are you volunteering to examine the 14 million lines, to find the 14,000+, so they can be iterated out?
Why use computers in first place? An abacus is good enough for calculations and doesn't need all that newfangled electricity.
"It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
First, 45MB library to parse XML is a stupid false (I really wanted to say "stupid fucking") argument. I personally hate XML but it's trivially easy to use at this point.
Second, who the fuck cares is it WAS 45MB (which it wasn't) on the server side if it solves a generic problem like parsing all XML.
Third, what's that "ASCII format"? You want to define your own format, then? And that's somehow more maintainable than XML?
And addendum - I don't think Sqlite is needed for most projects, but I have used it and if it is, it's a really small library that uses a tiny (and appropriate) amount of RAM and storage.
No android, no ios, no ppc, no arm, no mips, and no bsd. None of those are on the 'it won't break if you look at it funny' list of rust support.
When oh when will the Mo$illacrap dictators up in their high castles stop wasting so much time and resources on
1) Spending HOURS designing & mulling over new logos
2) writing HUNDREDS of lines of javascript for features nobody wants
3) Maintainting a slow, leaky, outdated old Nut$scrape codebase that is not based on fresh, new KDE Konqueror codebase from 1990s like everyone else
. and when oh when will they realise that what's really needed is a new, secure multi-threaded / multi-process browser.
Oh wait.
E.g., raw pointers should be eliminated, not just discouraged.
No thankyou, I'd rather you die in a fire than modify the C language. :)
Nothing personal, I just don't like your idea
I'm currently being forced to pick up C++ after staying clear of it for over 2 decades because of various defects.
I'm sorry, it's changed a lot.
"First they came for the slanderers and i said nothing."
betting on the future of hostile internet - and users actually giving a shit about security.
The first is certain, the second is doubtful.
Irresponsible disclosure is responsible
Concurrency/parallelism primitives was available through extensions (like posix threads, locks etc.). Those were available because, as native languages, C and C++ can make use of (inline) assembly and anything supported by ISA. Try that on interpreted/JIT-ed language.
Yes - the point I'm making is that these are all equally available in Swift. All C APIs are available without any modification in Swift.
Well, you're the second person to question this. I very clearly remember reading it and thinking it was a bit of a shame and an obvious example of the current state of the industry, with them preferring to use common commodity stuff that every code monkey can work with, but no, I don't have a source. This was some years ago.
I wouldn't trust Rust. It's written by those same error prone programmers who haven't got the brains to write secure code. How many lines of code is in the Rust compiler & library. How much of that must be flawed? That'll get passed on to every program that uses it. We need to stop using buggy software written by mentally deficient programmers to write security critical software. It's the only way to be sure.
I leave some shit on there as backups, like isos, or
docs.
But since its reached its limit, i rarely use it any more, now that google gives away 100gb+ if you buy some phone models.
Liberty freedom are no1, not dicks in suits.
No-one, apart from maybe Dan Bernstein, is good enough to reliably write bug-free code. The hubris that says "I am!" is the core reason why we have such enormous security problems.
> How many lines of code is in the Rust compiler & library. How much of that must be flawed? That'll get passed on to every program that uses it.
No, that's not how it works.
A bug in the compiler only matters if it was triggered during the build that produced your binary *and* the build succeeds *and* the results pass your test suite. Unless your code is quite unlike anyone else's code, you will hit this a lot less than bugs in your own code.
A bug in Rust's standard library can affect a lot of programs, but much of Rust's standard library is written in safe Rust so gets the same safety guarantees as regular Rust code. And of course the standard library gets a lot more testing and inspection than your own Rust program.
The bigger picture is that formal verification technology is advancing so that in time, we'll be able to verify that a build worked correctly (i.e. the generated code preserves the safety properties of the Rust code), and we'll be able to write proofs for most of the unsafe parts of the Rust standard library that they also preserve safety properties.
Swift lacks many of Rust's key features. In particular, it doesn't ensure data-race-freedom like Rust does. You're also stuck with using reference counting for all dynamic memory management, and atomic ops for your refcounts at that. Traversing a read-only dynamic structure? Enjoy atomic addref/release all the way along.
Swift can't guarantee data-race freedom. Rust does. So Rust has data-parallelism libraries like rayon that you can use that keep you out of trouble.
On the flip side, Swift requires thread-safe refcounting for all dynamic memory management, which is horrible for systems programming.
Since we have the word "regression" no, I am not implying that. I am stating that when reviewed there is a decent chance of errors being found and that code will tend towards less errors in the absence of new features. It's unreasonable to expect that code refactors will never add new bugs, but it is perfectly reasonable to assume that they will trend towards less bugs.
All those moments will be lost in time, like tears in rain.
Nope. You may be talking about svn (are they using svn?), but i am talking about bugzilla.mozilla.org
In that case, where exactly did you read that? Since others seem to make different claims...
Ezekiel 23:20
Rust isnt the only language with this feature, Perl has had it for much longer, along with tools like Tainting.
Why not Perl, Python or Ruby? These languages have had the same features and have been around even longer.
Oh shit, you called him DAN Bernstein! He's going to be so pissed if he sees that. You didn't call him DOCTOR DANIEL J Bernstein, PhD. Prepare for the wrath of his almighty ego if he sees that!
I've worked with DJB alot in IETF and I think I most IETF members agree the unusual things about DJB are his ego and his contrarianism. Always doing the opposite of well-established best practices doesn't make him smarter than everyone else, it just means he re-invents all the same mistakes that most of us learned to avoid 30 years ago.
Why not Perl, Python or Ruby? These languages have had the same features and have been around even longer.
Those languages have indeed been around longer, but they don't have the same features. For starters, neither meet conditions b, c, or d. Neither of those languages are capable of system programming or have a secure web engine focus. Perl, and increasingly Ruby and Python have a strong presence for web apps but to the best of my knowledge have never been used (for good reason) for a web browser or web layout engine.
Additionally, none allow concurrent computing. With modern internet connections, the bottleneck is often at rendering. Concurrent computing should speed this up by at least an order of magnitude.
Servo, a prototype, has been in testing for some time with very promising results. This project is also headed up by Mozilla.
[Rent This Space]
Swift can guarantee data-race freedom, in exactly the same way that C and C++ can - by using the normal threading and locking primitives you get from the OS's libraries. It even ships with a more user friendly library for doing this (GCD) than most OSes provide.
And swift absolutely does not require thread safe ref counting. Swift has both value types and reference types. Value types are passed by value (what a surprise), and include non-ref-counted pointer types. All you need do to avoid ref counting is to not use the word "class" in your program, and instead stick to "struct".
Neither of these are impediments to system programming.
Just need ... Seamonkey and Thunderbird ported to Palemoon, then a 6 month focused effort by the internet community sorting out the crapfest of C++ interfaces in gecko and plugging all the holes.
Thunderbird has already has been ported by the makers of Palemoon. It's called FossaMail
I've been using PaleMoon in both Windows and Linux, and Fossamail in just Linux, ever since Mozilla "chromed" Firefox. Although I had to choose a few different add-ons in PM, most of my chosen FF add-ons work fine in PM.
You are confused about the meaning of "guarantee" here. With Rust, if you don't write the keyword "unsafe" then code that triggers data races will not compile. With C++ and Swift, it will.
Safe Swift requires thread-safe ref-counting of heap-allocated objects. That is unacceptable.
Yep, that 's what I'm talking about.
"It is no measure of health to be well adjusted to a profoundly sick society." - Jiddu Krishnamurti
Firefox is kind of dying for a lot of reasons. Why not use it as a guinea pig?
This can be a great reality check for Rust. Find and fix the flaws in the language by trying to use it for something real and something big. There's a chance that a better language and a better browser will both emerge from this in parallel.
It was some years back, possibly a forum post or other less official source. I distinctly remember reading it and feeling annoyed and depressed about its implications for popular-for-being-popular momentum, but I can't vouch for nor recall the source. If they were wrong then they're wrong (and yay.)
That's all very well and good, and I credit Mr. Raymond for his accomplishments, but I'm afraid that he has a sufficiently bad reputation for making crazy statements that I am unwilling to take his opinion on any matter, That may not be fair to him as a technical expert, but he has earned distrust for his far-too-numerous non-technical opinions and general batshit craziness. It's not my job necessarily to issue proclamations for the groupthink here, but I am pretty sure that I'm not alone in feeling like this, and I suggest that you might want to put in some sort of explicit disclaimer or endorsement, to the effect that, "this is one of the times when ESR is actually worth listening to." It's a shame to have to say something like this. There are things he has written, however, that are crazy enough that I wish I could unread them. I am of course merely offering this suggestion on the basis that you might not be aware of his reputation.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
8GB is recommended and a 2GB absolute minimum is required.
8GB can be "jammed in" to virtually all desktops and laptops made in the last 5 years, 2GB can be "jammed in" to virtually all desktops and laptops made in the last 10 years.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register