Mozilla Will Ship Its First Rust Component In Firefox 48 (softpedia.com) 167
An anonymous reader quotes a report from Softpedia: Mozilla announced today plans to ship its first ever Rust code with the production releases of Firefox. The first ever Rust components will arrive in Firefox 48, scheduled for release on August 2, 2016. After teasing Rust features last year, the Mozilla Foundation announced today that Firefox 48 would contain a new media stack component that's entirely coded in Rust. The first Firefox component to feature Rust code was not chosen at random because media components often execute malicious code when parsing multimedia files. "This makes a memory-safe programming language like Rust a compelling addition to Mozilla's tool-chest for protecting against potentially malicious media content on the Web," says Dave Herman, Director of Strategy at Mozilla Research. During tests of this Rust-based media component in Firefox's unstable builds, Mozilla says that after one billion uses they have yet to see a crash or issue in the Rust media component. Last month, Mozilla released the first versions of Servo, a minimal browser created in Rust code alone. At around the same time, Microsoft open-sourced Checked C, an extension to the C programming language that brings new features to address a series of security-related issues.
Only as safe as the sandbox (Score:2, Interesting)
Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?
Re:Only as safe as the sandbox (Score:4, Informative)
Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?
Good question.
My guess is that running untrusted Java code in a trusted Java sandbox has a much larger attack surface than playing untrusted media in a (more or less) trusted Rust app.
The Rust code should still be an improvement, safety-wise, over the current C/C++ solution.
That does not mean the Rust solution will be perfect, and it *definitely* doesn't mean you should download and run untrusted Rust apps!
Re:Only as safe as the sandbox (Score:5, Informative)
That does not mean the Rust solution will be perfect, and it *definitely* doesn't mean you should download and run untrusted Rust apps!
Yes. Rust isn't a sandbox, it's a programming language with memory safety built into the type system. A rust program can do whatever it wants to your system if you don't sandbox it yourself. On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.
It says nothing about whether you should trust a particular rust program to not be malicious.
Re: (Score:2, Interesting)
On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.
That so only true if the compiler and run-time system do not have bugs. How well that assumption holds up in practice can be seen in other languages. And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.
My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it. Initially, it will of course seem to improve things, because attackers will not invest the time to find o
Re:Only as safe as the sandbox (Score:5, Insightful)
> That so only true if the compiler and run-time system do not have bugs.
We can be certain there are no bugs in Rusts run-time system because it doesn't have one.
It's true that the compiler needs to be correct but that's true of all compilers. Rust is a clean, modern design and the critical parts of the compiler are fairly small, so the Rust compiler's chances of generating correct code are pretty good, even compared with much more mature C compilers.
Re: (Score:2)
We can be certain there are no bugs in Rusts run-time system because it doesn't have one.
All languages these days have *some* kind of runtime system. Even if it's just a set of low-level trusted primitives. But the important thing is that it has to be small and not try to do everything.
Re: (Score:2)
Re: (Score:2)
For security and safety purposes, a runtime system is everything that was not directly coded by the programmer. Bootstrap code, function dispatch, libraries, etc. all are part of the runtime system.
But I am not surprised that the Rust-fanatics try to define the runtime system away: They actually have nothing to suggest that the Rust runtime is so massively better than others, so Rust must obviously not have a runtime.
Re: (Score:2)
And here we see the cluelessness of the Rust-proponents in all is glory: Unless you do bare-metal assembly, you do have a run-time system. This does not mean an interpreter or a the like, the standard libraries already form a runtime system. And yes, Rust does have one.
Re: (Score:3, Insightful)
Rust doesn't do anything magical to the security of programs written in it. Rust simply won't allow you to compile quite a lot of vulnerable programs that would be happily compiled by a C compiler, because the language is a lot stricter in terms of memory and thread safety.
Also, "safety" of Rust actually requires you to be rather more than less competent. There's a rather steep learning curve, less competent coders will struggle (and learn a lot in the process) just by trying to come up with a code that wil
Re: (Score:2)
Rust doesn't do anything magical to the security of programs written in it.
Isn't it the case that Rust allows for implementations with language-enforced isolation of code domains? Because if it is, I'd definitely say it's big for security of highly performant programs, because you should be able to run foreign code (mobile code, for example?) in the same memory space, including cross-module optimizations, with (a part of) the language spec serving as your security kernel.
Re: (Score:3)
That so only true if the compiler and run-time system do not have bugs
Well the Rust runtime is provably bug free. The proof is pretty trivial: it doesn't have a runtime.
How well that assumption holds up in practice can be seen in other languages.
How many other languages out there get the safety through the type system rather than other mechanisms like sandboxing? A sandbox for a complete and growing system is a much larger attack surface than the relatively small surface of the compiler.
For the language to
Re: (Score:2)
I know of one: Ada. And it has a well-deserved reputation for safety.
Re: (Score:2)
I know of one: Ada. And it has a well-deserved reputation for safety.
Indeed! Typesystem based safety is much better than unsafe + sandbox.
Re: (Score:3)
<citation needed>
Self-proclaimed expertise does not correlate well with actual expertise, and Ada seems to be doing quite well in its domains of highly-secure and embbeded software. In fact, it's having a bit of resurgence.
Those who do vocally hate on it seem to be the kind of cowboys that run after every new fad, the sort of programmers you wouldn't trust to code the right way to implement an automatic toilet seat.
(Side note: let's see who spots the reference in that last paragraph.)
Re: (Score:2)
Well the Rust runtime is provably bug free. The proof is pretty trivial: it doesn't have a runtime.
Judging from this [rust-lang.org], it actually *does* have a runtime, in two forms: partly in form of some routines (used by some programs), partly in form of compiler transforms/IR operations (used by *all* programs) that securely inline some sensitive tasks into the program in a way that a library can't. Just like, for example, some Lisp implementations inline low-level memory operations even into higher-level programs to speed them up without sacrificing safety. So the problem is effectively the same: a finite set of p
Re: (Score:2)
My guess is that all the other proofs showing Rusts superiority are of similar quality: Simple, elegant and wrong. Reality is messy, and ignoring that will not make the messiness go away.
Re: (Score:2)
Ah, the nobody can make things better argument, because if you improve things, someone will (should!) use up the extra slack they're given. You're basically arguing that software needs to have a certain amount of bugs, because if it has too few, the programmer market is being inefficient by not cranking out shittier code faster/cheaper.
I don't buy it. I think
Re: (Score:2)
You are missing one critical effect here that happens to basically all technologies: At some point they have realized their full practical potential and any more "evolution" makes them less beneficial. Examples: Flying cars, tablets as replacement for pen&paper, video-telephony, the hypeloop, electronic locks, etc. The list is really endless and the proponents of these things always display the same amount of fanaticism, faulty thinking and lack of insight into the problem being targeted.
But really, tha
Re: (Score:2)
Of course I've seen plenty of failures and stupid ideas! I don't see that (or your cherry-picked list) as important, though. In any human endeavor if you're around long enough, you'll see that happening. I'm sure in 4999 BC some numbnuts or con-artist had a really stupid idea about how to make farming work better. I don't care about him. Lots of people try thin
just because it can't happen doesn't mean it won't (Score:2, Informative)
I think the most valuable point to make is that by abstracting buffers in a meaningful way, when hackers eventually figure out how to get past the protection mechanisms... probably by stepping through the rust compiler to find loopholes, a single patch should fix all instances of the vulnerability.
Also, it should protect against code injection attacks, but it doesn't mean it's a silver bullet. It should still be possible to cause browser crashes due to I handled memory exceptions. Consider an H.264 decoder
Re: (Score:1)
The choice to use Rust for the media stack may indicate that the performance concerns you mention aren't a problem in practice, or at least that the cases where it's a problem can be nested inside an unsafe{} block without significant concern.
Most of rust's sanity checking happens at compile time, so the performance cost should be 0 in those cases. There's no runtime. It does bounds checking on arrays by default, but those are optimized out if you use iterators or if the compiler can prove that the index is
Re: (Score:1)
... "I'm using Rust, I don't have to think about memory anymore".
Rust is a low level language that forces you to think about memory. It's like a modern C. You can see for yourself how much of the Rust manual deals with memory management. In particular this page shows how the Rust stack and heap are the same as in C: https://doc.rust-lang.org/book... [rust-lang.org] . The thing Rust has over C is a type system that eliminates common classes of bug.
Re: (Score:2)
What worries me is the crazy thought process people will have about "I'm using Rust, I don't have to think about memory anymore".
I can't imagine anyone who's used rust actually saying that. If you don't think about memory hard enough, the Rust compiler will whine horribly and won't compile your program. That's one of the biggest complaints about it AFAICT!
Re: (Score:2)
Re: (Score:2)
On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.
That's not true because of the unsafe [rust-lang.org] escape hatch and raw pointers [rust-lang.org]. It's an improvement over C/C++ by having a safe default, but you can still shoot yourself in the foot.
Re: (Score:2)
Re: (Score:2)
The raw pointer stuff seems kind of more worrisome. I find its very presence peculiar.
Raw pointers can only be used in code labeled "unsafe".
Re: (Score:2)
The real lesson in Star Wars is not the attack surface, it's the fact that when you know about a weak spot you don't have your squadrons of fighters and bombers start at the other end of the ennemy base to make their way under heavy fire and defense and have them mowed down as they approach the target.
Re: (Score:2)
Also when you spend $100 trillion on building some huge moving military base made with a billion tons of steel etc., you'd better defend it with 1000+ Tie fighters not 20 or so.
Re: (Score:2)
Re:Only as safe as the sandbox (Score:5, Informative)
Rust does not derive its safety from a runtime sandbox, but from static guarantees enforced by its type system. This prevents memory errors that often lead to arbitrary code execution vulnerabilities, but it does not attempt to enforce higher-level semantic security properties, e.g. if you blindly use an untrusted string as a filename, you can still be tricked into opening /etc/passwd. Rust does not inherently protect you there, nor is it advertised as doing such.
Re:Only as safe as the sandbox (Score:5, Informative)
Rust isn't run in a sandbox. It's like C++. It simply has some assurances that the code it compiles should be free of some classical problems that plague software development in systems languages, without it also sacrificing the close-to-bare-metal aspects of languages like C++, and with much more of the costs involved being pushed to the compilation phase than the runtime phase. That's much more than the likes of Java have tried to offer, and it's also why so many people love to bash on it: it's hard to buy into the assurances without enough time passing, and it's made by a relatively small company that's popular to bash on right now.
Re: (Score:3)
I wish I had mod points to recommend this. Thank you for writing so succinctly about how the "safety" of Rust is not based on a runtime sandbox but rather on compile-time analysis that determines which operations are inherently unsafe and which are safe. While Rust advocates compare their safety constructs with those that Java attempts to provide, they are achieved completely differently. Thanks again for pointing this out.
Re: (Score:2)
Re:Only as safe as the sandbox (Score:4, Interesting)
Re: (Score:2)
Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?
Maybe because Graydon Hoare designed it, the same guy who did Monotone, the ancestor of Git. Something about the Sun/Gosling attitude to systems design, seems like a lot of lather and little substance.
Re: (Score:2)
I don't know, man. I googled a picture like I always do when I come across the name of someone who's supposed to be big, and that guy looks like a dentist that had a psychotic break and turned into a serial killer. Based on that I don't trust him, or rust.
Re: (Score:2)
You come across as a bit on the psycho stalker side yourself.
Re: (Score:2)
You come across as a bit on the psycho stalker side yourself.
Totally uncalled for. I haven't received a single restraining order in July so far, there was just this tiny incident with the 7-11 guy and the cops said it wasn't really stalking.
Re: (Score:1)
There is no reason to assume that Rust would be any better. But the egos of the Rust-people are much bigger, so they make bolder claims.
Re: (Score:1)
Rust does not aim to provide you a sandbox to run untrusted code. Its goal is to provide type safety. It means that code written in Rust is as safe as written in Python or in another high-level language, but it runs as fast as if it were written C++.
Obviously, it could be bugs in the Rust compiler or an unsafe library that you use, but the attack surface is much smaller in this way. Take a look at programs written in high-level languages, you do not hear about buffer overflow and other low-level attacks ag
Re: (Score:1)
Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?
This isn't even wrong. The media component needs to be free of bugs/vulnerabilities, not execute untrusted code.
The better comparison is with C because if the media component wasn't written in Rust, it would be written in C. Memory safety is the safety-critical attribute that Rust and Java have that C lacks. This is not the same as a sandbox. Sandboxes are indeed important in browsers - Chrome and Edge/IE have them and Firefox's sandbox (Electrolysis) is under active development. Rust is a low level languag
Re: (Score:2)
Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?
You don't know what you are talking about. Rust is built to make avoid memory leaks and buffer overflows. It does a good job at that.
Java doesn't have a problem with memory overflows, either, but you got confused between the plugin and the language. The Java language was fine, the plugin (with its sandbox) had problems.
rust community (Score:1, Offtopic)
Too bad the Rust community is so toxic. Can't call a process a slave, it has to be a "follower".
Re: rust community (Score:1)
People at my work went through the same discussions. Wtf. We aren't talking about humans here, these are machines. Should we rename the kill command too?
Re: (Score:1)
Re: rust community (Score:1)
Re: (Score:2)
Re: (Score:2)
You could go the whole hog and just the British version [github.com] of the language. It is far more refined.
Re: (Score:2)
Ever heard of INTERCAL?
Re: (Score:1)
Got me thinking of the IDE days of master and slave drives. Oddly enough never once thought of slavery in the process of using that terminology, just automatically associated it with the technological meaning.
Re: (Score:1, Funny)
Re: (Score:1)
Rust has multicore capabilities now? I thought that proper multi threading didn't fit into their "safety" models and requires ugly hacks.
Re:rust community (Score:5, Interesting)
Nope, in fact its the opposite. Thanks to its ownership model, Rust eliminates most of the ugly access bugs that you might run into if you do multithreading. It puts the information whether something needs to be locked before being accessed, or whether its totally threadsafe into the type system, so that the compiler can verify everything is working as you intended it.
Of course, its not perfect, but rust is one of the languages you might want to start your multithreaded program in. It doesn't save you from thinking about the problems, but if you got it wrong, it won't compile. There are still bugs, but none that fall into the category C++ would describe as "undefined behaviour" (and those are many times the reasons for the most evil security bugs AND the hardest to debug).
Re: (Score:1)
If we define what untrusted code to mean random binary/library from internet that your program downloads at runtime and then executes.
Rust/C++ have no support for limiting what harm that random binary code does. It can do anything and any Rust/C++ compile time protections are moot because the downloaded binary/library is not compiled or checked against the expectations.
Java sandbox (mostly used by applets) is an attempt to allow downloading binary (compiled java classes) from external source and limiting wh
Re: (Score:2)
Java (and other languages running in virtual machines or interpreters) provides the most protections
Yes, java provides lots of protections, but those protections come with a cost, that's paid by java at runtime. Rust provides the same level of protection, but it offers it at native speed (well, not 100% the same as C++, e.g. array access is always checked, so you should use iterators, they do O(1) many checks).
Generally only cases where safe code is calling to existing buggy C library for the data processing (for example image handling) can it untrusted input become a problem.
Same goes for Rust. The difference is though that you can actually write performant image decoders in Rust, while you have a hard time with Java (its entirely possible to write them, they just wont
Re: (Score:2)
From what I understand the latest benchmarks show that Rust and Java are quite even when it comes to performance. You can't just spend CPU cycles on checks and bounds without sacrificing speed.
Re: (Score:2)
The programming language shootout [debian.org] seems to show that Rust is a cut above Java's performance.
Re:rust community (Score:4, Insightful)
You're kidding me, right?
Please tell me that you're joking.
If this is true, I really have zero desire to learn the language. Anything swamped by the disaster of political correctness is, quite frankly, just not worth the trouble. If I'm going to use standard computer science terminology and get whined at because the same word means something not-warm-and-fuzzy in a totally different context, then I'm out.
Re: (Score:1, Flamebait)
Indeed. A tech-community that allows SJWs to dictate terminology to them is weak and not worth being part of in the first place. At least they signal to anybody with a clue that they are broken in the head early on.
Re: (Score:2)
Well said.
In my experience, a better language can help competent people produce good code more easily, but it can never make incompetent people produce reasonable code in the first place. And for competent people, "better" here typically means "stands in my way less often".
Their "safe space" approach reminds me of a thing most religions do: They give you a more-or-less arbitrary set of rules, and if you just follow them to the letter, you suddenly become a "good" person. (In actual reality, that does not wo
Re: (Score:2, Insightful)
It is a special class of idiots that focus on irrelevant side-issues while solving a hard technological problem. A "follower" and a "slave" are also different concepts, so they are mangling technological terminology with their Newspeak. Better stay away from these people, they are not engineers at heart.
Re: (Score:2)
If it's the latter then Rust should be boycotted in an attempt to prevent stupidity from spreading.
Fight fire with fire. Join the Rust community and complain that nearly every command is "triggering". It'll have to go through so many changes to the point of making the entire language unusable.
Terrible!! (Score:1)
I really hate seeing Mozilla getting "rusty"!!!
Re: (Score:2)
Except for the part where Rust itself is the "new and shiny."
Re: (Score:1)
The problem is Mozilla has become as money hungry as all the master's that they serve. When was the last time you saw an argument for keeping firefox FOSS?
Re: (Score:2)
Last I heard there are also some people who still believe that Pale Moon is worth using.
It is. Are you just another person who doesn't undestand how forks work and therefore dislike them, or do you have an actual reason?
and haven't lost our ability to configure the browser so that it doesn't offend our fragile, melodramatic minds.
Except for the things that have actually been removed from even about:config. Mozilla, how far you've fallen.
Re: (Score:2)
It's just a fork for a few people stubbornly clinging to the past, desperately trying to paint that past as "better"
Well what do you expect, when you make it nearly impossible for them to keep their comfortable browsing experience? (I assume you're involved with Mozilla somehow.)
Maybe Pale Moon will be a serious contender if they ever get truly serious about testing, security vetting, and they pull in some more talent.
This just comes off as sour grapes. "Those bastards stole our code, but at least they'll never be successful."
Man, this is the first time I've seen something that's so clearly FUD that the term actually popped into my head unbidden.
Who but Mozilla? (Score:1, Troll)
Who but Mozilla can we trust to protect our privacy? Everyone else seems to want to profit in one way or another.
Re: (Score:2, Informative)
Mozilla is no longer what it used to be - one that placed users first. All they've been doing is dicking around with the UI, and getting rid of all the customizability that attracted people to it in the first place(XUL and XPCOM support is going away - so many popular extensions that modify the interface and add features are going to go away), to make it a pale copy of Chrome. The only browser today that follows the charter of the original Mozilla is Pale Moon [palemoon.org], which was forked off Firefox 24 and will conti
Re: (Score:2, Insightful)
More bullshit.
Always the trolling on Mozilla posts. IT is so old and frankly untrue.
Re: (Score:2)
What bullshit? Care to provide and cite counter examples?
Re:Who but Mozilla? (Score:5, Informative)
Pale Moon is only worth it if you want to keep using obsolete tech. It's otherwise no better than Firefox, and has not improved significantly since its inception. It has already broken compatibility with more addons than Firefox did. It will either break compatibility with the obsolete tech you list in your post, or it will continue its slow downward spiral into irrelevance. It simply doesn't have the development community to be its own browser, and once Mozilla (rightly) stops supporting those outdated legacy things, you'll be SOL. Unless of course Pale Moon's community starts to actually pitch in beyond silly PR campaigns that overrate Pale Moon and poo-poo Firefox for "leaving them behind".
Re: (Score:2, Interesting)
It's otherwise no better than Firefox, and has not improved significantly since its inception.
Don't fix what ain't broke. Pale Moon has unfucked the Firefox interface, which is a big improvement in my book.
It has already broken compatibility with more addons than Firefox did.
A) They've got a whole library of fixed extension for ones that are broken.
B) Firefox is jettisoning their entire extension system anyway in the near future so it's not like they'll be any better.
or it will continue its slow downward spiral into irrelevance
Are we talking about PM or FF? Have you looked at your user figures recently?
and once Mozilla (rightly) stops supporting those outdated legacy things
You mean the things you're ripping PM for not supporting in this very same post?
It's rather interesting that all these posts ar
Re: (Score:2)
Just because it still kinda works doesn't mean it ain't broke. Not wanting to accept that changes nothing. Pale Moon keeping the old UI around hasn't made it any less broken.
For somebody who's whining about my "deflector shields", you're making similar assumptions, just in the opposite direction from my opinion. Just because you like Firefox's interface doesn't mean everybody else does. Again, look at the user figures for how many people are still on Firefox.
Keeping XUL/XPCOM around all this time in Firefox did little to improve it or fix its problems, it just made it more difficult for Firefox devs to actually fix the rest of the browser.
Lumping together mangling the UI and replacing the extension system muddies the argument. You could have replaced the extension system without turning the UI into Chrome.
And how are Pale Moon's figures doing lately? If that's your supposed to be an argument for Pale Moon
I'm not the one trying to upsell PM
Nope, not even what I'm saying.
You're admitting that
Re: (Score:2)
For somebody who's whining about my "deflector shields", you're making similar assumptions, just in the opposite direction from my opinion. Just because you like Firefox's interface doesn't mean everybody else does. Again, look at the user figures for how many people are still on Firefox.
What would be the absolute number of desktop web browser users who use Firefox?
I don't know what such numbers are (total number of desktop web users, year by year) but for the sake of the argument, 30% of 500 million desktops or 14% of one billion desktops is about the same fuck ton of users.
Or take that figure of 7% market share and apply it to 1.2+ billion users.
Re: (Score:2)
On the other hand, Mozilla has lost more users that most web browsers will ever have.
Re: (Score:3)
For anyone interested in numbers, I threw together a rough timeline:
47.9% July 2009 3.5 - peak Firefox usage
46.4% July 2010 4
42.0% July 2011 9
FF12 - final release to support Windows 2000 and Windows XP RTM & SP1
FF15 - automatic silent updates
33.7% July 2012 17
FF19 - built-in PDF viewer
FF20 - replacement download manager
FF21 - Social API "multiple providers"
Re: (Score:2)
I'm sure all the shenanigans the Mozilla team has gotten up to over the last several years had nothing to do with their user numbers. Nope. Not at all. Couldn't be.
your post is effectively useless and very misleading.
Hey, at least I tried giving any numbers at all.
Re: (Score:2)
What's wrong with having Pale Moon and Firefox installed side-by-side? Yes, it's a pain, but it's what I deal with to prevent the likes of Google and friends from reading over my shoulder in ways they refuse to disclose.
I use Pale Moon as my main browser, and Firefox for development. The only extensions I need for my main browser are my ad blocker and script blocker, and I'm pretty sure those will work well with Pale Moon for many years to come. Since I don't have to restart Pale Moon every 10 minutes du
Re: (Score:2)
For somebody trying to argue that Pale Moon is worse than Firefox, you're doing a terrible job of it.
Re: (Score:1)
Pale Moon is obsolete. Already it struggles with Javascript-heavy sites like Google Maps and it has hacks to get around sites that (correctly) detect it as out of date. It's only a matter of time until it becomes unusable on the modern Web.
Re: (Score:1)
As Microsoft and Ubuntu have yours?
Re: (Score:2, Insightful)
Re: (Score:2)
While I agree that JavaScript is a horrible abomination, so much "enterprise" code these days depends on it that it will take a very long time to go away.
Rust? (Score:3)
Re: (Score:2)
Ummm ... here's better info about why the name was chosen:
https://www.reddit.com/r/rust/... [reddit.com]
So is this one (Score:2)
version of FF that we should skip?
I would be excited about this but, (Score:2)
Firefox routinely crashes on my OSx so much so I have abandoned it.
Rust (Score:2)
The only language whose name admits that it's out of date the day it's released.
leaks (Score:2)
I think part of Mozilla's motivation to use rust is that it prevents leaks and they know they have many.
Re: (Score:1)
Not me, I want a pony.
Re: (Score:2)
Not me, I want a pony.
Here you go [ponylang.org]. I'd also prefer it to Rust.
Re:Oh, that's just jolly (Score:5, Funny)
Re:Oh, that's just jolly (Score:4, Informative)
Re: (Score:2)
In fact there is already a debian package of rust: https://packages.debian.org/st... [debian.org]
And debian means ubuntu and lots of other distros.
Re: (Score:2)
41? It died for me at version 3.6.
Re: (Score:2)
Re: (Score:2)
If you had such special needs and hated the version churn why not use the medium-term support version? (ESR 31.x, 38.x, 45.x)