SoylentNews is people
SoylentNews
An anonymous coward writes:
"Mozilla is using work on it's next generation layout engine, Servo, to fine tune a new language used for writing that layout engine. The new language, called Rust, started as a personal project of Greydon Hoare and has since grown to be sponsored by Mozilla and Samsung. From the article:
The Rust language will power Mozilla's new browser, Servo, and its big selling point is efficiency. Because C++ crashes when it runs into memory allocation issues, it weakens any browser that uses the language. Mozilla designed Rust to be superior to C++ this way, more easily isolating tasks and promote a process known as "work stealing," which is when tasks from an overloaded processor are shifted over to another one.
Rust is a general purpose, multi-paradigm, compiled programming language developed by Mozilla Research. It is designed to be a "safe, concurrent, practical language", supporting pure-functional, concurrent-actor, imperative-procedural, and object-oriented styles."
(Score: 5, Interesting) by GungnirSniper on Saturday March 15 2014, @10:23PM
So it's going to take Mozilla a whole new language just to fix the memory problems in Firefox, like not freeing memory from closed tabs, and memory leaks? Adding new features and designing new languages is more fun than fixing these foundational problems.
Tips for better submissions to help our site grow. [soylentnews.org]
(Score: 2) by tibman on Saturday March 15 2014, @10:37PM
Yes.
SN won't survive on lurkers alone. Write comments.
(Score: 1) by Angry Jesus on Saturday March 15 2014, @11:21PM
> the memory problems in Firefox, like not freeing memory from closed tabs, and memory leaks
Are these really problems anymore? I haven't run into mozilla (versus plugin) memory leaks for years.
I think the summary has vastly over-simplified the goals for rust.
(Score: 4, Interesting) by Reziac on Sunday March 16 2014, @03:14AM
I don't know if it qualifies technically as a leak, but Mozilla's cache management is, in my observation, the direct cause of its galloping memory usage. There's no excuse for taking half a gig to display 30k of text... and never giving it back. :(
And there is no Alkibiades to come back and save us from ourselves.
(Score: 2) by Angry Jesus on Monday March 17 2014, @03:09AM
> There's no excuse for taking half a gig to display 30k of text... and never giving it back.
But ridiculous hyperbole, that's totally excusable!
(Score: 2) by Reziac on Monday March 17 2014, @03:49AM
Sorry, I meant 213MB to display this page. [slaps self] Or 213,580k. There, fixed!
And there is no Alkibiades to come back and save us from ourselves.
(Score: 1) by Angry Jesus on Monday March 17 2014, @10:57AM
That is more realistic. However, what I am seeing on linux is a fresh start is 136MB resident and 138MB resident after loading this story's discussion page at -1 and flat. So 2MB consumed for displaying the page.
The about:memory says 46MB of that is misc heap, 50MB is javascript runtime and 30MB is javascript heap. You might say 80MB for javascript's starting point is out there, but it seems reasonable to me given the emphasis on making javascript fast as possible.
(Score: 2) by Reziac on Monday March 17 2014, @01:47PM
I have javascript turned off. And 213 mb was just that one page open. A 3k page of nothing but text.
For comparison, to display the SAME page with the SAME settings (no JS, no CSS, no images), Netscape 3 uses 7mb TOTAL. And NS3 is orders of magnitude faster, as becomes evident with larger or more complex HTML. So it's not like it can't be done.
My observation is that Mozilla evidently uses a lot of bad coding Zen (per Michael Abrash's concept); the disaster that's its cache management as case in point. Funny how with no caching (which I would do if I had anything like a reliably fast connection) or when there's hardly anything in it, the galloping memory usage doesn't happen.
Right now SM is using 280mb, having peaked sometime overnight at 349mb... while doing nothing but keeping one moderately 'complex' page open (forecase from NOAA.gov).
I've seen it peak at over 1.5GB, tho, after a few days of being up and moderate use -- and once it starts growing like that, it never gives back much of it.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 1) by Angry Jesus on Monday March 17 2014, @03:10PM
> I have javascript turned off
What does "about:memory" tell you?
> And NS3 is orders of magnitude faster, as becomes evident with larger or more complex HTML.
It is indeed super fast, easy to do so when it doesn't even support as complex as CSS1.
(Score: 2) by Reziac on Monday March 17 2014, @03:30PM
The NS3 engine itself was vastly faster -- which was obvious once NS4 came out and did the same jobs (initially it did very little more than NS3 did) at about 1/10th the speed, even with JS and images off. But the NS3 source code has been lost (I once spoke to one of the major coders about it; he said he'd tried and tried to get it released once opensource became a thing, but it wasn't happening) and evidently no one since has been competent to recreate that efficiency. :(
Right now SM claims to display this page takes 159mb... a few bits:
68.23 MB (43.17%) -- heap-unclassified
45.93 MB (29.06%) -- js
and
Other Measurements
0.19 MB -- canvas-2d-pixel-bytes
0.00 MB -- gfx-d2d-surfacecache
0.00 MB -- gfx-d2d-surfacevram
0.00 MB -- gfx-surface-image
14.34 MB -- gfx-surface-win32
141.49 MB -- heap-allocated
175.67 MB -- heap-committed
2.78 MB -- heap-dirty
102.50 MB -- heap-unallocated
6 -- js-compartments-system
28 -- js-compartments-user
27.00 MB -- js-gc-heap
3.47 MB -- js-gc-heap-arena-unused
0.00 MB -- js-gc-heap-chunk-clean-unused
12.40 MB -- js-gc-heap-chunk-dirty-unused
58.74% -- js-gc-heap-unused-fraction
206.43 MB -- private
225.40 MB -- resident
4.44 MB -- shmem-allocated
4.44 MB -- shmem-mapped
419.75 MB -- vsize
This is just nuts. What on earth does it have to do that takes all this to display a page that even Mosaic 0.9 doesn't struggle with??
This is why I've said for years that developers should be constrained to working on the dead minimum hardware that will run their software, so they can experience it how average folks will. We should not be forced to buy new hardware just because the basic coding philosophy now seems to be "Junk fills the space allotted".
And there is no Alkibiades to come back and save us from ourselves.
(Score: 0) by Angry Jesus on Monday March 17 2014, @04:11PM
> The NS3 engine itself was vastly faster -- which was obvious once NS4 came out
Everyone knows NS4 was a clusterfuck, which means comparing NS3 to NS4 as a means to say thing about modern firefox is cherry-picking.
Still, you are missing the point - modern firefox implements orders of magnitude more functionality than NS3. Any comparison of speeds on "complex html" is to beg the question because NS3 can't do complex html. The price for additional functionality is additional memory and cpu.
> 102.50 MB -- heap-unallocated
I don't even see heap-unallocated in 27.0.1, are you running an old version of firefox?
> "less verbose" to "more verbose" consistently uses about 9mb. To display about 30 more lines of text. :(
I get 2MB difference and when I cut-n-paste the text on the page into wc, regular has 248 lines, verbose has 4,371 lines.
(Score: 2) by Reziac on Monday March 17 2014, @04:45PM
SeaMonkey v2.5 at the moment. I tend not to upgrade unless I have to, because the next version is invariably worse in some way either annoying or critical. :( I don't use Firefox at all, because it makes me want to kill the developers. (If forced by some cranky site, I'll use PaleMoon, but not for everyday.)
And verbose wasn't much more in my case, but I had very little going on at that instant.
See, there's the point I was making -- NS4 was indeed a clusterfuck, yet in its early stages it did very little more than NS3. Just did it massively slower. Sometimes a total code rewrite is NOT a good thing.
Incidentally, Abrash's old book is now available online (it's been a freebie for years, I think I got it with his Black Book):
http://www.jagregory.com/abrash-zen-of-asm/ [jagregory.com]
And there is no Alkibiades to come back and save us from ourselves.
(Score: 0) by Angry Jesus on Monday March 17 2014, @05:07PM
That's odd, I thought your point was that firefox is a pointless memory hog and when required to drill down to the actual reasoning and evidence behind that point, it turned out to be technical innuendo.
(Score: 2) by Reziac on Monday March 17 2014, @05:21PM
Dunno how you concluded that, but whatever.
Read Abrash's Black Book, it'll give you some insights.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 2) by Reziac on Monday March 17 2014, @03:34PM
Addendum: with no pages open but the "about:memory" page, going from "less verbose" to "more verbose" consistently uses about 9mb. To display about 30 more lines of text. :(
And there is no Alkibiades to come back and save us from ourselves.
(Score: 2) by Reziac on Monday March 17 2014, @03:44AM
Only a slight exaggeration... right now it's using 213k to display nothing but THIS page.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 5, Insightful) by lennier on Saturday March 15 2014, @11:24PM
"So it's going to take Mozilla a whole new language just to fix the memory problems in Firefox"
Yes. For the same reason that it's going to take everyone a whole new language to fix the endemic memory problems everywhere on the Internet. The language layer is exactly the right layer to fix this stuff, because if you leave it up to individual programmers they will get it wrong. And we can't afford to ever get memory issues wrong anymore, because that's how security vulnerabilities happen. And if you recall, it only takes one security vulnerability to pretty much compromise your entire machine, which means your entire password history and your entire organisation.
Seriously, we need to quit it already with this "but C++ is the perfect tool as long as all programmers are a super-genius space wizards and never make mistakes" Dunning-Kruger thing. C++ is mathematically untractable to automated code analysis... to put it politely... and it turns out that there actually aren't any super-genius space wizard C++ programmers. The ones who thought they were, including Linux kernel hackers, keep making mistakes that destroy our systems' security. And they keep making entire classes of these mistakes decades after these classes of mistakes have been pointed out and solved by academia. There's something wrong with this picture.
See, programming is about automation. If you do something twice, you write a function so you don't have to do it three times. But we're very slow to apply this logic to our language itself; if you have to type a single character of boilerplate code twice, you should be able to make a function so you don't do it three times; if your language doesn't let you do that (or if the results of doing that can't be reasoned about), then there's something wrong with your language, and your language needs to be repaired. Programmers laugh at office clerks who rote memorise huge sequences of commands rather than script them; but programmers for some reason are weirdly averse to automating the tools they themselves use, and take a perverse kind of pride in how much pain they can endure from their programming environment. That attitude needs to change if we're going to make any progress.
Delenda est Beta
(Score: 1, Informative) by Anonymous Coward on Sunday March 16 2014, @12:05AM
Linux kernel hackers don't usually use C++, though.
(Score: 0) by Anonymous Coward on Sunday March 16 2014, @12:25AM
You make a compelling argument but I have no idea what you're talking about.
The problem with Rust is that it's a plain ugly syntax; that is not where the problems lie with C++ and Rust is a step backwards. Every attempt to improve on C fails for a variety of reasons unrelated to the 'language' -- as-in that thing which we read and write.
Somebody else commented that Rust makes PHP look elegant and I agree (bows head in shame etc). We really just need C with a sane object system and decent runtime library... Vala is probably the cleanest I've seen and then... javascript. And I'm being serious here. The winning language is something we can already use, one that handles concurrency and offers us both 'managed' and direct access to hardware. Bonus if the compiler / runtime can identify and dl appropriate code to run on the GPU. A very simple cross platform GUI would be nice too.
(Score: 4, Insightful) by Daniel Dvorkin on Sunday March 16 2014, @01:57AM
That was beautiful.
Pipedot [pipedot.org]:Soylent [soylentnews.org]::BSD:Linux
(Score: 2, Insightful) by clone141166 on Sunday March 16 2014, @03:23AM
Good C++ code doesn't require "super-genius space wizard programmers". Good C++ code requires good C++ programmers, good Java code requires good Java programmers, etc. Bad programmers will always write bad code, the language is largely irrelevant to this fact. The more you tie down a language in an attempt to prevent programmers from being able to hurt themselves, the more features and flexibility that language loses.
Looking at Java, automated memory management might stop the program from crashing at times, but things like garbage collection can introduce a whole slew of other problems that can be equally bad. GC in a large program will often stall the entire program for a few seconds at a time. It is extremely difficulty to prevent this as Java provides no way to allocate objects on the stack instead of the heap, or to manually delete old objects because these features were deemed too dangerous to let programmers handle.
That said, ultimately a programming language is just a tool. Some tools are better at some things than others. Java is still great for some things and terrible for others, just like C++. The reason C++ excels is because it has a much wider scope of application than a lot of languages, albeit at a higher effort cost. To give a somewhat flawed analogy, you can use a hammer on a nail or a screw; obviously a screwdriver would be better for the screw but useless for the nail. Maybe Rust will solve these problems and be the perfect language, or maybe Ruby, or maybe Go or maybe......
"programming is about automation. If you do something twice, you write a function so you don't have to do it three times". Yes, but you have to be careful where this automation occurs. Automation actually adds complexity at the same time. It's the reason why RISC processors beat out CISC processors. Keeping the CPU instruction set very simple so that you could build anything out of a few small building blocks turned out to be more useful than trying to add too many complicated "useful" instructions into the CPU. If you try to keep stuffing more and more complex functions deeper and deeper into your system, you end up with a system so complex that it is practically unmaintainable. Languages should provide programmers with the basic building blocks they need to program. It is up to *programmers* to automate the processes that apply to *them* rather than expecting the language to provide every function they will ever need. In this regard I would rather see Mozilla write a C++ library to provide some level of automated memory management than an entirely new language.
I agree with parts of what you said, but the crux of my argument is that automation both adds complexity and removes access to functionality, and thus removes control from the programmer. At times this can be particularly painful to deal with. I think it is important to maintain a balance between automation and control. My personal preference bends more toward placing control in the hands of the programmer. Doing so allows for the creation of some pretty amazing programs by good programmers, at the cost of having to deal with some pretty awful programs written by bad programmers.
(Score: 1) by rev0lt on Sunday March 16 2014, @03:41AM
You're fond of C++ and I respect that. Everyone is broken in their own special way :)
It's the reason why RISC processors beat out CISC processors
Well, they didn't. The truth is somewhere in the middle. Modern RISC implement complex instructions like div, and modern CISC use microcode RISC architecture. Its a crazy world out there.
If you try to keep stuffing more and more complex functions deeper and deeper into your system, you end up with a system so complex that it is practically unmaintainable.
I'd say you actually just defined modern C++ or modern Java, but its okay.
Languages should provide programmers with the basic building blocks they need to program
For me, objects aren't building blocks, they are aberrations. OOP will suck your soul (I know a bit about both soul sucking and OOP, I do it everyday). I'd switch in a heartbeat to assembly listings.
In this regard I would rather see Mozilla write a C++ library to provide some level of automated memory management than an entirely new language.
Well, they wrote a full-blown WYSIWYG rendering platform (also linkable as a library) and still has memory problems. They call the main product "Firefox".
Doing so allows for the creation of some pretty amazing programs by good programmers, at the cost of having to deal with some pretty awful programs written by bad programmers
Amen! But do we really need rendering engines in C++? Is OO the best paradigm for a browser?
(Score: 1) by clone141166 on Sunday March 16 2014, @03:55AM
That's fine, I have very little experience with functional programming languages so I'm not qualified to argue for or against OOP vs. Functional.
But my question would be, if hypothetically OOP is bad for writing browsers and a functional language is needed, then why is an entirely new functional language required? Are existing functional programming languages so terribly bad that a whole new one needs to be written from scratch?
(Score: 1) by rev0lt on Sunday March 16 2014, @09:22PM
Well, DSLs are on the rise. And having a browser building language would theoretically allow the easy building of customized browsers, using the same core features.
(Score: 1) by digitalaudiorock on Sunday March 16 2014, @02:25PM
That's the genius behind this approach...then they can focus on fixing memory leaks in the language.