Mozilla Binds Firefox's Fate To The Rust Language (infoworld.com) 236
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."
Assembly language is good enough for anyone... (Score:2, Insightful)
Re:Assembly language is good enough for anyone... (Score:5, Informative)
What's with all these other languages lately?
In the case of Rust, it addresses security problems that are the domain of internet facing software. When writing complex internet facing software, human's haven't got the brains to write secure code. Rust improves the situation by enforcing things that humans get wrong.
For this reason, security people love it. They understand how they can write software with deterministic behavior in Rust where they know they cannot in C or many other compiled languages.
Other people want different problems solved and look at Rust and think "Well that looks a bit inconvenient" and dismiss it, and continue to write browsers and servers and daemons and MTAs and other internet facing things full of security exploits.
Re: (Score:2, Insightful)
Funny how the OpenBSD team doesn't have that problem.
Re: (Score:2)
Funny how the OpenBSD team isn't very big, and hasn't really grown.
Re: (Score:2)
The OpenBSD team hasn't written anything nearly as complex as a browser.
Re: (Score:3)
Re: (Score:2)
What's with all these other languages lately?
In the case of Rust, it addresses security problems that are the domain of internet facing software.
Well it is basically a compact syntax for doing modern safe C++ but based on a hybridf of ML and C instead of just C, and proper ML-style enums and pattern matching thrown in to spice it up a bit.
Nothing you can't do in C++ and people already are doing.
Re: (Score:2)
It's nothing you can't do in assembly either. What's your point? That this stuff should be harder than it needs to be? That makes no sense.
Re: (Score:2)
It's nothing you can't do in assembly either. What's your point? That this stuff should be harder than it needs to be? That makes no sense.
Nope. I think Rust is nice, though I have seen better "C++-killers". There have just been a lot of languages like it. They tend to fail or remain niche if they don't provide something they do significantly better than what they are replacing.
Also if you are concerned about these security aspect you should switch to safe techniques first, you can worry about a language that make such techniques more concise later, first you need to learn them.
Re: (Score:2)
Rust can do many things modern C++ can't do.
For example, in Rust you can give away a reference to a field of an object *safely*:
struct X { foo: Y }
impl X {
fn foo(&self) -> &Y { &self.foo }
}
No way to do that safely in C++. Sure, you can give away a pointer or a reference to a field, but the compiler can't ensure you haven't introduced a use-after-free bug. Rust can.
require Rust to compile successfully, (Score:3)
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.
Re: (Score:2)
In the case of Rust, it addresses security problems that are the domain of internet facing software
I don't think there are any common security problems that can't be fixed by using a good string and buffer library. Switching languages to get that advantage is a little overkill.
Using Rust will get rid of a lot of memory leaks though (not all of them), so that is a benefit. Judicious use of techniques like memory pools, stack allocation, and reference counting will get you similar benefits in C, requires more discipline (which Firefox developers definitely don't all have), but eliminates more bugs.
The
Re: (Score:2)
Judicious use of techniques like memory pools, stack allocation, and reference counting will get you similar benefits in C, requires more discipline
Does it? Look at Apache memory management through APR: you do not need special discipline, just use it and get rid of memory leaks.
Re: (Score:2)
Re: (Score:2)
String and vector libraries can't protect you from use-after-free bugs. To prevent those, before Rust, you needed some kind of GC, which imposes performance tradeoffs (some combination of increased memory usage, throughput overhead, and pauses). (Swift's ARC is really a form of reference-counting-based GC.) Rust offers a new approach where you can have manual memory management but the compiler can verify you don't have use-after-free bugs.
Re: (Score:2)
For this reason, security people love it. They understand how they can write software with deterministic behavior in Rust where they know they cannot in C or many other compiled languages.
I am a security person and I do not love Rust. In fact, I think it will make matters worse, because it will make people think that they can write security-critical software with even less understanding of what is going on. Rust will make some types of attacks harder to do, but by the dumbing-down effect it will add other problems. My expectation is that in total, what we will see is a decrease of security due to less competent architecture, design and implementation.
There is no silver bullet, and those that
Re: (Score:2)
Are you saying that instead we should make people smarter? Or that we should write less software?
Re: (Score:2)
Nice one, I laughed loud and hard! That future has been predicted for now something like 40 years, and exactly _nothing_ of it has materialized.
The state of things has been and likely will be for a long time (potentially forever) that anything the coder does not understand will not be understood and hence very likely faulty. Tools help somewhat with errors that are oversights. They do not help at all when the coder does not understand what is wrong or even that there is something wrong. The key reason for t
Re: (Score:2)
Other people want different problems solved and look at Rust and think "Well that looks a bit inconvenient" and dismiss it, and continue to write browsers and servers and daemons and MTAs and other internet facing things full of security exploits.
Right, because if you use Rust your code will magically become secure, and bug-free, and crash-proof, and all your problems will go away, and Adriana Lima will fall in love with you and have your babies. I've heard similar stuff from other True Believers about their pet languages, e.g. the academic who said that everything should be written in Haskell because it's impossible to write bad code in it (this actually happened!).
You need to balance a lot of things when deciding which language you want to use.
99.9% perfection X 14 million lines = 14,000 flaws (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:3)
And you imply that when code is revised, flaws are always removed and never added?
Re: (Score:2)
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.
You volunteering to find the 14,000 flaws? (Score:2)
Firefox is open source, are you volunteering to examine the 14 million lines, to find the 14,000+, so they can be iterated out?
Re: (Score:2)
I am volunteering to find the ones in the code I have written and open sourced. Is that good enough for you?
Re: (Score:3)
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 distri
90,000 examples say they don't (Score:2)
> "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.
Re: (Score:2)
Someone who has truly mastered their craft may perfection 99% of the time.
May what perfection?
Re: (Score:2)
Re: (Score:2)
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 t
Re: (Score:2)
Rust isnt the only language with this feature, Perl has had it for much longer, along with tools like Tainting.
Re: (Score:2)
Just because a programmer is skilled does not mean they will write code that is good or acceptable.
Also doesn't mean they can't.
Re: (Score:3)
That's what I've been saying about nosql for a long time now.
Re: LTS distros (Score:2)
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.
Re:Assembly language is good enough for anyone... (Score:5, Insightful)
Great. Here's some sand. Bake me an intel-compatible x86 chip. The specs are all out there, and it's unencumbered by patents.
What's that? You need a wafer oven and a lithography machine? pffft. no kiddin'.
You sometimes have to make a tool to make a tool to make a tool that will make the tool you need to do the job. Human hands don't have the dexterity to cut a silicon wafer, nor do human eyes have the ability to see to do it... nor do human minds have the capacity to construct and memorize a proper layout -- we use computers to do that for us. An amazing amount of chip design is automated with most of the details worked out by complicated algorithms.
Same is true of software. We build frameworks and modules and libraries and use compilers for various languages because no one on the planet can create the binary for a massive modern program using only their head and a pen and pad and hand-feed it into the machine with punch cards.
If you don't understand this concept, you are truly lost.
You can optimize, which you young ones are shit at (Score:2, Offtopic)
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.
Re: You can optimize, which you young ones are shi (Score:2)
Why use computers in first place? An abacus is good enough for calculations and doesn't need all that newfangled electricity.
Re: (Score:2)
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 a
Re: (Score:3, Insightful)
Re: (Score:2, Interesting)
Mozilla have repeatedly shown that they won't tolerate opposing opinions and will fire you if your opinions are not in line with theirs. They chased out Brendan Eich because his opinions and they promised to hunt down and fire a Mozilla employee who posted his opinions online:
http://www.dailydot.com/debug/mozilla-reddit-hate-speech-firing/
So, not only do we have two clear cases of them chasing programmers out, they've probably deterred a great many other programmers from wanting to join. I would therefore
Re: (Score:2)
Re: (Score:2)
sudo get him/her/it
Re: (Score:2)
Irony died on January 20th.
Courage. (Score:5, Insightful)
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.
Re: (Score:2)
Re:Courage. (Score:5, Interesting)
It is very hard to do those things in Rust and that what makes it an excellent systems programming language. It has equivalent performance to C or C++ - almost all checks are at compile time and compile away to nothing in the generated code, and yet the quality of the code is higher because there are less ways it can fail when it passes those checks. That's an extremely compelling argument for code that is expected to run for months or years without failure.
Aside from the language itself, the std library is way better than for C++ and cross platform. And building software or pulling in external libraries is incredibly easy thanks to the package manager / build tool. It still has some rough edges, but nothing I would consider a blocker.
Re: (Score:3)
In C or C++ it's far too easy to allocate memory and forget to free it
Leaks are memory safe though and the borrow checker doesn't help there. With Rust as with modern C++ though, you have to go pretty far out of your way to leak. Everything else though, Rust does help with.
Re: (Score:2)
Real world software is also not perfect. Maybe you use smart pointers all over the place. But you'll have to link with some libr
Re: (Score:2)
Re: (Score:2)
I think he meant exactly what he said... Nothing less, nothing more.
So... yes. At least, that's how it read to me.
At the very least, you don't get to just arbitrarily change or remove some of the words that somebody was using to determine that is what they must have originally meant. Maybe you are right, but his argument did not read to me like that at all. I was just calling someone out for trying to put different words in someone's mouth than what was actually said.
Re: (Score:2)
Who has time for spelling when there are statist infants who have not yet been processed into a useful industrial slurry?
The Wiki page makes it sound like Rust (Score:2)
Servo (Score:5, Informative)
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 [youtube.com].
ESR vs Rust (Score:5, Informative)
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" [ntpsec.org]
Rust severely disappoints me [ibiblio.org]
"Rust and the limits of swarm design" [ibiblio.org]
Re: (Score:2)
ESR of all people should know "Patches welcome"
Re: (Score:2)
"This gives me hope that the Rust of five years from now may become the mature and effective replacement for C that it is not yet."
Rust is still a work in progress, don't expect it to be perfect for every use case.
Re: (Score:2)
Dude Erlang man
It's the real Rockstar language for you hipsters [youtu.be]
Re: What the hell is "rust"? (Score:5, Funny)
Best of all, if you have a problem with Swift, you can tailor swift to your needs and shake it off.
Re:What the hell is "rust"? (Score:5, Informative)
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.
Re: (Score:3, Insightful)
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 profil
Re: (Score:2)
Nope. You may be talking about svn (are they using svn?), but i am talking about bugzilla.mozilla.org
Re: (Score:2)
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 ti
Re: (Score:2)
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.
Re: (Score:2)
Why not Perl, Python or Ruby? These languages have had the same features and have been around even longer.
Re:What the hell is "rust"? (Score:4, Insightful)
The Accidental Tech Podcast [atp.fm] 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.
Re: (Score:2, Insightful)
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.
Re: (Score:2)
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!
Re: (Score:3)
" 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.
Re: (Score:3)
I thought it went.
Re: (Score:2)
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 im
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Tell us, Einstein, what is Rust written in? (Score:4, Insightful)
Uh, nope.
From WIkipedia:
(emphasis added)
However, I'll grant that LLVM is written in C++.
Re: (Score:2)
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 som
Re: (Score:2)
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.
Re:the future of Mozilla (Score:5, Interesting)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
now that i cant get more free gb its dead (Score:2)
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.
Re: (Score:2)
Some people use it.
https://www.rust-lang.org/en-U... [rust-lang.org]
Re: (Score:2)
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.
Re: (Score:2)
Just make your engine render pages fast and correct, fix security bugs
So you want Servo. Great, but it's being written in Rust.
Re: (Score:2)
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 [youtube.com], not new features.
Re:Stick a fork in Mozilla! They're done! (Score:5, Insightful)
There are several forks. I'm typing this in Palemoon, a fork that didn't go along in the chromification process.
Re: (Score:2)
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!
Re: (Score:2)
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.
Re: (Score:2)
Reminds me of trying to get stuffit installed on an old Mac. Nobody ever supplied stuffit as an executable, it was always compressed.
Re: (Score:2)
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.
Re: (Score:2)
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 th
Re: (Score:2)
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.
Re: (Score:2)
I run Funtoo Linux, a source based distribution. I compile Firefox without issue. Actually, I've had more problems with compiling Chromium than Firefox.
Re: (Score:3)
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/... [mozilla.org]
Re: (Score:2)
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:/Tem
Re: (Score:2)
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.
Re: (Score:2)