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?
R.I.P. Firefox. It was fun while it lasted.
so many bad decisions. RIP.
A browser nobody uses written in a language nobody uses.
Firefox will require Rust to compile successfully
Rust depends on LLVM
Ok, so we can't compile Firefox on lesser-end androids targeting a megacluser of PICs. But apart from that, what's the fuss?
Without knowing anything about it, I'd guess 99,999% of the times Firefox is compiled, it is compiled on x86-64. And a dependency on LLVM won't bump that to 100%.
Should I have read TFA in order to understand TFS?
Thank you for dragging your feet on the LLVM thing and complaining about it instead, you stalwart defenders of the OSS world, you. After all, your niche architecture is only worth that much, not doing the actual leg-work to drag it into the future.
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.
The essential feature Rust brings is security, Swift has nothing fundamentally new.
I said it before, Mozilla needs to be a basic browser that is written in standardized C++ and not use any Brogrammer languages like Rust. Keep to the basics and keep supporting Windows XP and old Linux distros as that is where most of your dedicated users come from. Slashdot users need to get together and force Mozilla to stop Chromifying everything.
Oh yeah, C and C++.
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]
People said this crap about Go, too. And Go didn't even have any ambition as a language. Look at Go now. Not to mention that it has even taken much longer for big changes in C++ to be adopted than Rust has existed. So I have to ask: what's your point? If you're happy with the status quo, live in it. Someone has to try harder to improve our craft, and you're sure as hell not doing it. All you're doing is trolling on Slashdot.
It's too early. Rust isn't ready.
I've played around with it, and it has some interesting properties and ideas that I like.
But the tools are still too unstable. Language and library features change from one compiler version to the next.
And compilation is slow as shit.
Try compiling a simple hello world with Rust or GCC. The difference is staggering. (at least it was about 6 months ago)
This might now matter for a hello world, but a codebase the size of firefox?
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.
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!
I use Go language, thank you very much.
Rust sucks.
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.
lololol hahaha
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.
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/
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.
I doubt it. The language that replaces C/C++ will be the next C/C++ standard. Rust is a nice language, but it needs to be a lot better than C++ to replace it, not just a bit better. There's also a lot of C/C++ code around, that in itself gives C/C++ a huge advantage over Rust for many applications.
rust in peace
mother fuckers
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.
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
What the fuck is swift?
Never heard of it.
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"?
Go and Rust came onto the scene around the same time. Fast-forward to today and Go has become much more popular compared to Rust.[1] I believe the main reason for this is ease of use. Most people out there are code monkeys and Go is the easier language to pick up.
I don't see Rust making a big dent in the market, for the same reasons Haskell or Erlang haven't, the learning curve is too steep.
[1] Looking at some of the big projects/companies now using Go. https://en.wikipedia.org/wiki/...
Then you are irrelevant. Let me guess, you are also a Linux user and a democrat.
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.
"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?"
Actually, I would say that this is up to the distros. If the distro wants to ship a new Firefox then it obviously isn't completely frozen, so the distro would have to first package Rust and then use it to build the next Firefox update.
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.
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. . . .
Rust reeks of security through obscurity. Once companies big enough to pay worthwhile bug bounties start using it or organizations that interest the Russians, Israelis and Chinese, you'll see a ton of vulnerabilities getting exposed. If you've been around long enough, you realize "it's designed for security" or "using it is security best practices" means nothing. Look at the vulnerabilities in SSH. Oh yes, SSH is secure, so we're secure. Sure.
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.
True, it wouldn't make sense to target a language supported only on OSX out of their other platforms. On the other hand, they can package LLVM for platforms like Windows XP. Remains to be seen how it will work on, for example, RHEL/CentOS 6 or even 7.
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.
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.
"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.
What in the holy hell is this madness? Not supporting linux because it requires a bunch if programming dependencies? Fucking what?
~ $ eix -Ic dev-lang/ | wc -l
16
I have 16 programming languages installed right now, Rust would make it 17. Whoopdedingdongdoo.
I have powered through using Netscape/Firefox for a long time now and use it as my main browser. But if they make linux a second class citizen, well, I'm out. And before you say "muh privacy" I'll be moving to https://github.com/Eloston/ungoogled-chromium/releases
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.
Extension signing is actually necessary to improve security, just like binary signing on every consumer system these days. Telemetry can be a very useful resource for devs, and being open source means that people can know exactly what is being sent to Mozilla ; also, it's possible to disable it completely.
Agreed with the rest.
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.
At this point, Firefox is on a downward spiral down to 11% of the market. The only reason it is still around is because it was the browser that replaced IE which isn't really saying much. Also, it is the browser used for Tor. The only way Firefox will make a comeback is if Google Chrome pisses everybody off which it may.
Why would anyone name a programming language "Rust"?
Someone who has truly mastered their craft may perfection 99% of the time.
May what perfection?
systemd is Roko's Basilisk.
Look, if you don't have any idea what's going on with new languages, then stop acting like you do. Unfounded opinions are at best useless, and that's before you start calling people out for nothing at all. Next you'll be calling people "pinheads" or something for using Rust.
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?
Which retard modded the parent as a troll?!
Clearly someone who doesn't know the failings of C++ in enterprise environments and the massive benefits of Rust!
Yes, that perfection indeed.
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.
Meh, coding a basic XML parser isn't that hard. I've done it, and it was fast, though in hindsight I should have just somehow got my company to approve a stock one, though it might have taken weeks to months, so it may have been a toss up. I was still using a schema verifier which came with another package, just not its xml parser which was crap. FWIW, you can probably load XML these days at 100MB/s or faster if you really want to go crazy and play the optimization game. I might have to go back and do that with an upcoming project, but probably not. C#s parser is pretty good.
Would I possibly include a library to read a 1kb XML file these days? Probably. It is usually better to code expecting growth, and it is just less code to debug. The main thing is not the number of DLLs you have floating around, but rather how hard is it for the end user to get going, and to get new versions going. (You're presumably not spending much time debugging stable versions of libraries.)
Another variation that seems more and more worthwhile these days is just using an sqlite database. This is particularly true if your end user has no need to edit any data. Of course that would be kinda ridiculous for a 1kb file, but I'd still argue that XML is not overkill, since it allows for growth and structure, and from what I've seen just the benefits of having decent schema checking alone make it worth it...
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.
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.
I think you meant SSL. But otherwise correct.
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
By "basic" you probably mean "works for the few xml features we actually use". But free and reliable parsers are available , why would you waste your time writing your own?
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.
Every single line of code is a potential flaw? What type of work do you do exactly? I know it's not programming.
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.
5) rewriting existing codebase with some kitchen sink programming language nobody outside of their own company uses.
Are they doing these stupidities just to keep their employers busy? Or are they really trying to drive away their users and now also the open source developers, as Rust is equally popular language as Basic v2.0.
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.
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.
That's a very naive way of thinking. The language may not support buffers, but the implementation sure as hell will.
This is like those (JavaScript, Flash, Google NaCl, etc) security sandboxes that are supposedly "proven" to contain any VM instructions running inside, but in practice the sandbox implementation turns out to have implementation flaws that are exploitable from within the sandbox.
Yes, it may improve code quality, and reduce the number of exploits. But blindly trusting that the language will keep you safe security-wise, is a sure way to get pwned.
but then i point at the bugtracker with seven figure Bug-IDs.
They require a bug ID for every commit.
So basically the amount of commits is what the 'seven figures of bug IDs' is counting.
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
This presumes something that they shouldn't. You can't get RUST to be perfect, even if you make it "enforce the rules"- it's a fallacy and a folly to be brutally blunt. It's another abject fail in a space they've been trying to find "answers" and failing over and over again for DECADES now.
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.
Yeeeeah, buffer overloads are bad I guess.
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.
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
This is a massive and dangerous disease within open source circles - deep layers of dependecies. One package depends on three others, each of which has a dozen dependencies, each of which has a bunch of dependencies, each if which has more depedencies, etc.
If you did not write your code, then you do not understand your code and your code is not trustworthy nor maintainable.
Sticking together a hundred other bits of code written by people you do not know and applying the coding equivalent of chewing gum, bailing wire, and duct tape is not programming at all - it's on-par with being a script kiddie, and when some prject your "program" is dependent upon goes away you may be left unable to fix/maintain the thing you have pretended was your program.
This sort of garbage programming did not generally exist before the internet. Now lazy people think nothing of using enormous piles of code they know nothing about but were able to find with a quick googling and insert into critical applications - and we have all sorts of buggy code and code with huge security problems.
Embrace, extend, extinguish.
Now that they have a large market share they can afford to add more features to enhance their own services.
Who doesn't like a good tool on traint
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.
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.