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