Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Saturday March 15 2014, @10:07PM   Printer-friendly
from the we-always-need-new-languages dept.

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."

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by SlimmPickens on Saturday March 15 2014, @10:13PM

    by SlimmPickens (1056) on Saturday March 15 2014, @10:13PM (#16971)

    Great work guys, just chuck it over there on the pile.

    • (Score: 1, Informative) by Ethanol-fueled on Saturday March 15 2014, @10:30PM

      by Ethanol-fueled (2792) on Saturday March 15 2014, @10:30PM (#16976) Homepage

      Speaking of piles, the idea was pretty exciting until I saw how goddamn ugly the language is. Utterly hideous. I haven't seen anything that ugly since SCALA. Even PHP's prettier than RUST.

      • (Score: 2, Funny) by ticho on Saturday March 15 2014, @10:56PM

        by ticho (89) on Saturday March 15 2014, @10:56PM (#16986) Homepage Journal

        But this one comes with a plateful of buzzword soup. Therefore, it can't not be good, ask any PHB!

      • (Score: 4, Informative) by forsythe on Sunday March 16 2014, @05:23AM

        by forsythe (831) on Sunday March 16 2014, @05:23AM (#17093)

        Any language I've seen looked ugly, the first time I saw it. Quite a few still do.

        That said, lots of people have found Rust ugly, which probably stems from the way syntax conventions are inspired by very different sources (I've heard Rust described as "What C would look like if it were designed by somebody who had only ever known Haskell"). Ugliness isn't a sin for a language, but it may mean that newcomers to the language will have trouble finding parallels to other languages, and that it will therefore be rather difficult to pick up.

        Given that new languages are almost impossible to get adoption for anyway, that's a valid and very harsh criticism of Rust.

        (I've been picking it up a little myself over the past few months. As a language with no mandatory GC, it promises to be actually useful for systems programming. Given more time, I think I wouldn't have any more problems with format! and ~ than with C's *.)

      • (Score: 1) by Hairyfeet on Sunday March 16 2014, @07:41AM

        by Hairyfeet (75) <reversethis-{moc ... {8691tsaebssab}> on Sunday March 16 2014, @07:41AM (#17115) Journal

        Hey if it gets rid of the "bandaids on bullet wounds" that is JavaScript? Then I don't care if its the ugliest damned thing on the planet YES PLEASE!!!

        I mean do you have ANY idea how much the net is slowed down by JavaScript malware? I know at the shop that is pretty much ALL I see anymore is JS malware infections. Hell since Adobe made "update automatically" the default setting for Flash I've been seeing Flash infections go down, not JS though and if you think about it the reason is obvious....it was just never made with security in mind and instead of starting over and doing it right bandaids have just been bolted onto a broken mess.

        So if it gets rid of the "Hey we'll just run third party code from anywhere, whats the harm?" of JS and gives us a web language built from the ground up with best practices and least permissions in mind? All for it. Sadly considering that while Webkit had support for Low Rights mode 6 months after Vista came out while Moz has had SEVEN YEARS and still hasn't implemented it in FF? Really doesn't give me much hope of them making anything but a mess, but maybe Google or the Webkit guys can give us something to replace JS..

        --
        ACs are never seen so don't bother. Always ready to show SJWs for the racists they are.
        • (Score: 2, Informative) by sjames on Sunday March 16 2014, @08:08AM

          by sjames (2882) on Sunday March 16 2014, @08:08AM (#17119) Journal

          Sorry, it won't do that. Rust will be used to write the browser which will, in turn, support Javascript.

          I can sure sympathize with your position though. I can and do code in Javascript when it needs to run in the browser, but much of the functionality feels bolted on and then mysteriously restricted to paper over a gaping security hole that resulted from security not really being a priority when the runtime was designed.

          It would be nice if Javascript would just implement declared domains of trust and be done with it.

          It could use a good syntax cleanup as well.

    • (Score: 1) by No.Limit on Sunday March 16 2014, @04:24PM

      by No.Limit (1965) on Sunday March 16 2014, @04:24PM (#17200)
      A programming language is the most fundamental tool of a coder. Every advancement in programming languages is a blessing to all of us coders!

      Of course we already have languages with really great features (C, C++, Java, C#, Python, Haskell, Ruby etc). But while they're good, there is always room for improvement as can be seen by language updates.

      The _recent_ C++11 standard introduced many awesome features to C++. Simple and easy ones like inferred types or syntax for iterations (for (auto myIterator: myContainer) { /*...*/ }).
      Highly flexible ones like lambda expressions (also new in Java 8). Important concepts such as move semantics and more.

      But there are limits to how much we can improve existing languages. These languages always have to try to keep as much backwards compatibility as possible and that severely limits how much they can really change and improve.

      A good example is the null reference or also the 'Billion Dollar Mistake' (that actually comes from the inventor). At this point we know we can guarantee null-pointer safety by for example extending the type system to distinguish between references that could be possibly null and references that are guaranteed not to be null.

      Here an example:

      reference? couldBeNull = null; // denoted by a question mark after the type
      reference guaranteedNotToBeNull = new SomeClass(); // no question mark, so always non-null

      if (couldBeNull != null) {
        // here the type of couldBeNull changes, because here it's guaranteed not to be null
        // here we can dereference both couldBeNull and guaranteedNotToBeNull safely
      }
      // here we can only dereference guaranteedNotToBeNull safely.

      And this goes beyond forcing coders to do null pointer checking. With this we can also guarantee that functions get non-null references with the type system.
      In fact we can prove that there will never be a null pointer exception in the whole program!

      And there are so many more awesome features that languages could have and that guarantee safer programs. I for one embrace every exploration of language design hoping that in the future we'll have even better and safer languages!
  • (Score: 5, Interesting) by GungnirSniper on Saturday March 15 2014, @10:23PM

    by GungnirSniper (1671) on Saturday March 15 2014, @10:23PM (#16974) Journal

    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.

    • (Score: 2) by tibman on Saturday March 15 2014, @10:37PM

      by tibman (134) Subscriber Badge on Saturday March 15 2014, @10:37PM (#16979)

      Yes.

      --
      SN won't survive on lurkers alone. Write comments.
    • (Score: 1) by Angry Jesus on Saturday March 15 2014, @11:21PM

      by Angry Jesus (182) on Saturday March 15 2014, @11:21PM (#16991)

      > 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

        by Reziac (2489) on Sunday March 16 2014, @03:14AM (#17051) Homepage

        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

          by Angry Jesus (182) on Monday March 17 2014, @03:09AM (#17359)

          > 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

            by Reziac (2489) on Monday March 17 2014, @03:49AM (#17373) Homepage

            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

              by Angry Jesus (182) on Monday March 17 2014, @10:57AM (#17505)

              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

                by Reziac (2489) on Monday March 17 2014, @01:47PM (#17578) Homepage

                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

                  by Angry Jesus (182) on Monday March 17 2014, @03:10PM (#17633)

                  > 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

                    by Reziac (2489) on Monday March 17 2014, @03:30PM (#17655) Homepage

                    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

                      by Angry Jesus (182) on Monday March 17 2014, @04:11PM (#17679)

                      > 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

                        by Reziac (2489) on Monday March 17 2014, @04:45PM (#17688) Homepage

                        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

                          by Angry Jesus (182) on Monday March 17 2014, @05:07PM (#17701)

                          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.

                          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

                            by Reziac (2489) on Monday March 17 2014, @05:21PM (#17706) Homepage

                            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

                    by Reziac (2489) on Monday March 17 2014, @03:34PM (#17657) Homepage

                    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

          by Reziac (2489) on Monday March 17 2014, @03:44AM (#17370) Homepage

          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

      by lennier (2199) on Saturday March 15 2014, @11:24PM (#16992)

      "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

        by Anonymous Coward on Sunday March 16 2014, @12:05AM (#17000)

        Linux kernel hackers don't usually use C++, though.

      • (Score: 0) by Anonymous Coward on Sunday March 16 2014, @12:25AM

        by Anonymous Coward on Sunday March 16 2014, @12:25AM (#17009)

        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

        by Daniel Dvorkin (1099) on Sunday March 16 2014, @01:57AM (#17034) Journal

        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.

        That was beautiful.

        --
        Pipedot [pipedot.org]:Soylent [soylentnews.org]::BSD:Linux
      • (Score: 2, Insightful) by clone141166 on Sunday March 16 2014, @03:23AM

        by clone141166 (59) on Sunday March 16 2014, @03:23AM (#17054)
        "because if you leave it up to individual programmers they will get it wrong". You do realise that Rust was written by individual programmers who are just as likely to get things wrong as any other programmer. The difference being that now the errors will be stuck inside the language so when it breaks you won't be sure if you did something wrong or the language itself is broken.

        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

          by rev0lt (3125) on Sunday March 16 2014, @03:41AM (#17060)

          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

            by clone141166 (59) on Sunday March 16 2014, @03:55AM (#17067)

            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

              by rev0lt (3125) on Sunday March 16 2014, @09:22PM (#17284)

              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

      by digitalaudiorock (688) on Sunday March 16 2014, @02:25PM (#17184)

      So it's going to take Mozilla a whole new language just to fix the memory problems in Firefox

      That's the genius behind this approach...then they can focus on fixing memory leaks in the language.

  • (Score: 3, Insightful) by ticho on Saturday March 15 2014, @10:53PM

    by ticho (89) on Saturday March 15 2014, @10:53PM (#16985) Homepage Journal

    Didn't Firefox start as a leaner alternative to original Mozilla browser? Now Firefox is the unwieldy behemoth.

    • (Score: 3, Informative) by clone141166 on Sunday March 16 2014, @03:40AM

      by clone141166 (59) on Sunday March 16 2014, @03:40AM (#17058)

      *sigh* Yes, back in the good old days when there were nightly builds of Phoenix. And its entire raison d'etre was to be a stripped down, lean, mean, efficient version of the Mozilla browser. But somebody decided it needed more functionality, and then more and then more, and then that it needed an entirely new language just to develop it...

      Some might call it evolution, I call it failing to achieve original requirements.

      • (Score: 0) by Anonymous Coward on Sunday March 16 2014, @04:58AM

        by Anonymous Coward on Sunday March 16 2014, @04:58AM (#17085)

        Paradoxically, Firefox has less functionality now because "extensions". It doesn't even handle ctrl-backspace/arrow correctly.

    • (Score: 2) by everdred on Monday March 17 2014, @12:08AM

      by everdred (110) Subscriber Badge on Monday March 17 2014, @12:08AM (#17324) Homepage Journal

      "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."

      --jwz [jwz.org]

  • (Score: 3, Insightful) by unauthorized on Saturday March 15 2014, @11:08PM

    by unauthorized (3776) on Saturday March 15 2014, @11:08PM (#16988)

    C++ does not crash when it runs out of memory. Maybe someone needs to learn to catch(std::bad_alloc&)?

    • (Score: 5, Interesting) by DeKO on Sunday March 16 2014, @02:15AM

      by DeKO (3672) on Sunday March 16 2014, @02:15AM (#17041)

      And stop using explicit new/delete everywhere, that's "bad-style" C++. And write exception-safe code; no matter what language you use, if the code you write is not exception-safe, you will always end up with inconsistent/leaky programs when an exception occurs, be it an out-of-memory condition or a network timeout (e.g. thunderbird), no matter what language you use.

      And before anyone starts replying with "but you can't afford an all-stars C++ dev team that knows how to write good G++ code", writing "not-bad" C++ code just requires some training and proper code reviews; just like learning a whole new language. One that's not even mature enough to properly support Windows platforms apparently, has very limited analysis tools, or even documentation.

      I'm appalled that neither the Rust tutorial [rust-lang.org] nor the manual [rust-lang.org] mention error handling. So I can't even form an opinion on how exactly it's supposed to outdo C++ in reliability. Does it always crash the entire process in case of errors?

      • (Score: 3, Interesting) by TGV on Sunday March 16 2014, @08:18AM

        by TGV (2838) on Sunday March 16 2014, @08:18AM (#17122)

        Totally right. Ok, it takes a bit of effort to write good C++, but it can be done. I've had my simulations run for weeks without a single crash, with my own bloody memory allocation and everything.

        And who's going to build the new language? How many people and time does that take? I can remember that it took quite a few years before the first C++ compilers would behave acceptably. And that requires skills above the level of writing a browser.

    • (Score: 1, Insightful) by Anonymous Coward on Sunday March 16 2014, @10:07AM

      by Anonymous Coward on Sunday March 16 2014, @10:07AM (#17140)

      Yes exactly, people should at least have a basic understanding of a language before they criticise it and want new ones.
      It seems overly popular for people to criticise C++ these days without having even a basic understanding of it.

      "C++ crashes when it runs into memory allocation issues" - I mean really, this statement is absolutely outrageous. Shame on the author, Mozilla and anyone else involved in this total misinformation.

  • (Score: 1) by anthem on Sunday March 16 2014, @02:49AM

    by anthem (17) on Sunday March 16 2014, @02:49AM (#17047)

    is this more for firefox os than it is for traditional desktop? or no? like the future of things. i wish firefox os came on hardware like the s4.