Slashdot Mirror

The Rust home page makes it sound like Rust is some sort of a panacea. It leads one to believe that they'll get the power of C++, but with greater "safety".

But the more I look into Rust, the more uneasy I start to feel.

Despite all of the claims about how Rust is safer and leads to better code, the Rust compiler and standard library, both of which are implemented in Rust, are full of bugs! Don't forget that this is Rust code written by people who ought to know Rust better than anyone else; they designed the language after all! If they can't write non-buggy Rust code, then we shouldn't expect less-talented Rust users to be able to do any better.

It's also a big problem that there's only one implementation. If you run into a bug with it, and they don't fix it promptly, then you're likely fucked. At least with C++ there are multiple high quality implementations from different vendors. You can use GCC and Clang on most platforms. Then there are other systems like Intel C++, MSVC++, and so forth. You aren't left at the mercy of a single implementation when you use C++.

The syntax of Rust is unremarkable. It's like a bad version of C++ in many ways. Its resource management approach is also inflexible and impractical, despite the claims that it's one of Rust's most significant benefits. You're typically better off using modern C++ techniques. You'll get just about the same amount of safety, but with much fewer headaches. Even C++'s standard library, which is not known for being very good, is often better than Rust's.

It took them forever to get Rust 1.0 released. They were constantly changing their mind about anything and everything. While some evolution of a programming language is to be expected, all we saw from them was spastic thrashing about. It got so bad that you couldn't write code on a Monday and reliably have it compile by the following Friday! The fact that it took libcore up until release 1.6 to "stabilize" just goes to show how bad things were. The supposed "stable" release was full of non-stable interfaces!

The Rust community gives me a particularly bad feeling. They're rather tyrannical about enforcing their code of conduct. They even have a moderation attack squad to go after anyone they deem to be an enemy! I've never seen this kind of orchestrated control exerted over the community of any other programming language. This sets off warning alarms for me.

There's no reason to use Rust, in my opinion. You're better off with C++, or D, or Java, or Scala, or C#, or Go, or Swift, or one of the many other non-Rust languages out there. The language isn't very good, the standard libraries aren't very good, there's only one implementation, and the attitude of the community is downright frightening. I think you're better off not using Rust.

The most important thing I see out of all of this is that he isn't using Gecko, despite his very long history with that technology.

He's also not using Servo, the browser engine Mozilla is working on to eventually replace Gecko.

I think this says a huge amount about the sorry state of Mozilla's offerings today.

Users of Firefox already know what I'm talking about. They know how much slower Firefox feels than Chrome, Edge, Safari, and browsers using other engines. They know how Firefox uses more memory. They know how Firefox suffers from bugs that haven't been fixed even after many years.

It's truly sad what has happened to Mozilla's products. They've shot themselves in the foot by going off on stupid tangents like Firefox OS, Persona, and especially Rust and Servo.

Rust and Servo are leading Mozilla down a dead end trail. They're a twin example of software rewrites gone bad.

Rust is basically trying to rewrite C++, but hasn't done a very good job. The syntax is no better, and sometimes much worse. Its approach to resource management is harder to understand and use practically than C++'s. There's only one Rust implementation, and it's buggy and slow. The Rust community is way too focused on social justice and censorship. They even have a moderation squad, for crying out loud! It took them ages to get a 1.0 release out, and it isn't good at all. Then there's the fact that C++ has continued to evolve and get better, along with having multiple excellent implementations.

Servo is written in Rust, so that helps explain why it's a failure so far, too. When I tried it recently, it gave me what I'd consider an experience similar to IE 3, which dates back to 1996. Servo has a huge amount of catching up to do. The entire situation is not encouraging at all.

Mozilla should end the Rust and Servo projects now, along with Firefox OS and their other failed initiatives. They need to get back to focusing on Gecko and Firefox. They need to restore Firefox's UI to the usable Firefox 3.6 approach. They need to migrate Gecko to C++14, and prepare for the use of C++17 instead of switching to Rust. They need to fix Gecko's performance issues. They need to fix the longstanding bugs.

Right now there are at least a few remaining users of Firefox and Gecko, although their number is dropping. There are basically no users of Servo. Mozilla's only hope for salvation is to win back the Firefox users they've alienated over the past few years. I fear that if they don't do that, then they will slide into irrelevancy. That won't be good for them, and it won't be good for the web either.

I have heard a lot of people saying that the Rust programming language is the best for writing secure and unbreakable software. Rust's home page says that it "prevents segfaults" and "guarantees thread safety". But does Rust also make software HIPAA-compliant by default? Because if it doesn't, then I think that's a pretty big problem! How can Rust be called a safe language if it doesn't enforce HIPAA rules?

I don't see how anyone can suggest that Mozilla isn't innovative.

Mozilla has shown itself to be among the leaders in the field of Social Justice innovation.

Just look at how swiftly their former CEO Brendan Eich was ousted merely for expressing his views about marriage.

Then there's Rust, which is one of the first open source projects to have a harsh code of conduct enforced by an unaccountable moderation team.

I don't know what else they're working on, but I would not be at all surprised if we saw them make some great strides with automated privilege detection, and make some breakthroughs in the prevention of triggering.

I don't see how anyone can suggest that Mozilla isn't innovative.

Mozilla has shown itself to be among the leaders in the field of Social Justice innovation.

Just look at how swiftly their former CEO Brendan Eich was ousted merely for expressing his views about marriage.

Then there's Rust, which is one of the first open source projects to have a harsh code of conduct enforced by an unaccountable moderation team.

I don't know what else they're working on, but I would not be at all surprised if we saw them make some great strides with automated privilege detection, and make some breakthroughs in the prevention of triggering.

Uhhh, rust's way of dealing with pointers that might be null is optionals...

https://doc.rust-lang.org/std/...

Instead of Swift you should use the Rust programming language. It is the successor to Swift, and is an improvement in every way.

If you don't know what Rust is, let me refer you to what Rust's home page says: "Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." It has guaranteed memory safety and threads without data races.

Rust is what Swift should have been. Rust is all about safety, while still keeping the programmer totally in control and the generated binaries fast.

Rust is clearly the future. It's being developed by masters of the trade like Yehuda Katz, Steve Klabnik and Patrick Walton. These fine men are visionaries and many years ahead of the rest of the industry. We need to follow their valiant lead today. We need to use Rust for all new projects, and start porting all existing software to it immediately.

Let's put an end to software security problems. Let's put an end to software bugs. Let's use Rust.

Instead of C++17 you should use the Rust programming language. It is the successor to C++, and is an improvement in every way.

If you don't know what Rust is, let me refer you to what Rust's home page says: "Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." It has guaranteed memory safety and threads without data races.

Rust is what C++ should have been. Rust is all about safety, while still keeping the programmer totally in control and the generated binaries fast.

Rust is clearly the future. It's being developed by masters of the trade like Yehuda Katz, Steve Klabnik and Patrick Walton. These fine men are visionaries and many years ahead of the rest of the industry. We need to follow their valiant lead today. We need to use Rust for all new projects, and start porting all existing software to it immediately.

Let's put an end to software security problems. Let's put an end to software bugs. Let's use Rust.

All of these security flaws, and software bugs in general, would not be an issue if we used a better programming language than C or C++ or Objective-C.

There's just one language out there today that can give us this, and it is called the Rust programming language

If you don't know what Rust is, let me refer you to what Rust's home page says: "Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." It has guaranteed memory safety and threads without data races.

We need to immediately start using Rust for all of our software, and we need to start doing this now. It will take a lot of effort, but we need to port every single application out there to Rust.

Rust is clearly the future. It's being developed by masters of the trade like Yehuda Katz, Steve Klabnik and Patrick Walton. These fine men are visionaries and many years ahead of the rest of the industry. We need to follow their valiant lead today. We need to use Rust for all new projects, and start porting all existing software to it immediately.

Let's put an end to software security problems. Let's put an end to software bugs. Let's use Rust. Rust is our only savior at this point.

Native apps from "garage" developers: zero users on Wii U. Web apps from "garage" developers: greater than zero users on Wii U.

You're not genuinely trying to argue that the Wii U is a significant application platform, are you? It's a games platform for children, and the least successful console of the current generation by a mile. You'd be crazy to target it for applications, native or otherwise.

Even HTML5 game support is weak on the Wii. No support for sound? Does it even have WebGL support? Nope, guess not. And look at this weird non-standard stuff. Effortless support it ain't.

You haven't provided evidence for your claim that web development with all its current limitations, with all the vagaries of differences between browsers is more efficient or productive than native cross platform application development. Some me some real, measurable outcomes instead of making vague assertions.

First, there's the overhead of obtaining hardware on which to test the build for each platform. You essentially have to buy a Mac, buy a copy of Parallels, and buy a retail copy of Windows.

Welcome to professional development. And as you said yourself it's the same deal for web development. What, you got your Wii U for free in a box of cereal or something?

That's fine once your company is big enough to afford "the right development environment".

Many cross platform languages, libraries, and development environments are free. You can use GCC or Rust or Python or Free Pascal and their associated libraries, or use none of them and use something else. You want to do GUI applications? Look, here's an option. Here's another. Use what you want, I don't care.

There are more options available now than ever. Small companies can easily find the right development environment for them for native application development for as much or as little money as they want to spend.

Computer security is inherently a technological problem. Attempting a political solution to a technological problem rarely succeeds. When faced with a technological problem, it is often a much better idea to look for a technological solution.

Since we're talking about computer security, the obvious answer in this case is to use the Rust programming language.

Rust's very own web page describes it as ``a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.'' It also says it has ``guaranteed memory safety'', ``threads without data races'' and ``zero-cost abstractions''.

I think that Rust is the solution to technological security problems. From what I can tell about it, Rust is the kind of programming language that makes it nearly impossible to write buggy code. Since security problems are a type of bug, if you don't have buggy software then you don't have security problems.

So all we need to do is start using Rust for everything. It will take time and it won't be easy but we should rewrite all of our existing software in Rust. I think that's the only way we can move into this uncertain future safely. We need to use a programming language like Rust for everything.

There's a fellow at work who keeps going on and on about how great the Rust programming language is. He keeps raving about how its community is totally diverse, how it has a code of conduct, how there's a team that goes after people who don't follow the code of conduct, and how it's the most progressive programming language community he has ever been a part of. Yet when I go look at the contributors to Rust, I see one male after another. Why are so many Rust contributors men? If the project is so inclusive, tolerant, and open to everyone then why aren't there more women contributing to Rust?

Here's the part about all of this that really bothers me: if so much of the current SSL/TLS infrastructure is written in C and C++, can we really consider the entire system to be secure? I know a lot of the bugs have been caught so far, but there's only so much that humans can do. We're limited beings with limited minds. That's why we need computers to do the hard work for us. I think we should rewrite all of our SSL/TLS infrastructure using the Rust programming language. On its home page it says "Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." That's just what we need for critical security infrastructure like the entire SSL/TLS system. We need to use a programming language that makes it totally impossible for the software to have bugs. I think that Rust is that programming language. It's the kind of language that makes bugs just not possible in the first place. That's why I think we should use it for the SSL/TLS infrastructure.

I don't see why QA is needed at all. All you need to do is use the Rust programming language. On its home page it says "Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety." It sounds to me like Rust means that all programmers will write perfect software because Rust won't let them write buggy code.

The winning team will use Rust to program their car.

Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety.

Featuring
        * zero-cost abstractions
        * move semantics
        * guaranteed memory safety
        * threads without data races
        * trait-based generics
        * pattern matching
        * type inference
        * minimal runtime
        * efficient C bindings

It is a systems programming language so it can be used for systems like artificial intelligence driving a car.

It is blazingly fast which is what you need when driving fast.

It prevents segfaults which is good because you don't want a segfault when you are driving!

It guarantees thread safety which means the fabric on the seats of the car will remain clean and intact.

It has zero-cost abstractions which will keep the price of the car down.

It has move semantics which is just what you want from a car: movement!

It has guaranteed memory safety which is good because you don't want your car to forget where it is.

It has threads without data races which is critical because it means that there can be no data racism because there are no races.

It has trait-based generics which are good because they mean that, generically speaking, the car has good traits.

It has pattern matching which is very important because the car needs to differentiate between what is road and what is not road.

It has type inference which is good to have because it can infer what is road and what is not road.

It has minimal runtime which is totally what you want in a race: you want to run it in the shortest time possible!

It has efficient C bindings which means it's as fast as C because most Rust code actually gets written in C and then glued together using Rust because C is a much more useful, efficient, and faster programming language than Rust is.

A generation of experts will have to work to ensure computer math, science and games can often be spread over the many cores.

I think that Mozilla will take care of that problem.

They're working on Rust, which according to its home page is "a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety."

They're also working on Servo, which according to its home page is "a modern, performant browser engine designed to be appropriate for applications including embedded use. Written in Mozilla's new systems programming language, Rust, the Servo project aims to achieve better parallelism, security, modularity, and performance."

Wait, who the fuck am I kidding?! After witnessing the destruction of Firefox over the last few years, I have my doubts about the eventual success of both Rust and Servo. My only experience with Rust so far has been horrible. It's like C++, but done wrong, and C++ isn't done all that right, either! I tried Servo, too. Browsing modern web sites using Servo was like browsing them using Netscape Navigator 3: more seemed broken than was working!

That's really not how version numbers work. Having said that, this is from the project FAQ:

Is any part of this thing production-ready?
No. Feel free to play around, but don't expect completeness or stability yet. Expect incompleteness and breakage.

Can you go:

Of course you can, syntax notwithstanding. But asking questions here is an awful way to learn the capabilities of Rust given they have published a free online book to teach you just that. It would only take you a day to work through the entire thing. It being open source and all, once you have done that next step would be to look up the code for the standard libraries for that that does something like you want. There is nothing like studying the work of an expert in the field to get you up to speed fast. They even give an example that looks like yours in the standard library doco.

Can you go:

Of course you can, syntax notwithstanding. But asking questions here is an awful way to learn the capabilities of Rust given they have published a free online book to teach you just that. It would only take you a day to work through the entire thing. It being open source and all, once you have done that next step would be to look up the code for the standard libraries for that that does something like you want. There is nothing like studying the work of an expert in the field to get you up to speed fast. They even give an example that looks like yours in the standard library doco.

Would have been nice if the official manual mentioned some of this...

It also doesn't mention the one thing I wasn't clear on. Can you go:
let size :u32 = readbytes(protocolStream, 4);
if makes_sense(size)
let data :protocolstruct = readbytes(protocolStream, size);


I know I made a total hash of the syntax there, but you get the idea I hope.

Looks to me like the problem with OOM is the standard library. You probably want to avoid the Rust standard library when doing safety critical embedded.

https://users.rust-lang.org/t/...

Rust should add rudimentary support for exceptions

It does have exactly that, rudimentary being the operative word. It has panic(), which doesn't kill the program but does kill a much larger unit of it (a thread actually) then try/except/finally normally controls. Still, it's enough to recover from things like out of memory, because it guarantees the memory will be freed.

The reason it has only rudimentary exceptions is because it can do the by combining it's type inference engine with it's spectacularly powerful macroing system. The type system allows you return arbitrary stuff with the caller really having to know or care (because it has an implicit type generation), and they have provided a "try!" macro in the standard library. So it's all there, just not done in the conventional way.

And in case you are wondering why force you to learn this newfangled way when the old way worked perfectly well - it's because the old way imposed run time over heads on everything. The new way handles it in the type system so overheads disappear at compile time.

It's just a repeat of Rust's memory handling solution, really. In C you handle memory allocation and exceptions manually, with all sorts of nasty consequences like dangling pointers and people dereferencing NULL. Java/C#/YouNameIt eliminates the nasty consequences using run time solutions like gc and exceptions - but they impose a runtime overhead. Rust brings something totally new to the table - the programmer handles it, but the language eliminates all the nasty consequences. So it's fast like C, and safe like Java/C#/YouNameIt. But there is nothing free in this world. Rust's extracts it's pound of programmer flesh with it's borrow checker.

Some things rust guarantees, others it doesn't:
https://doc.rust-lang.org/nigh...

Rust considers it "safe" to:
        Deadlock
        Have a race condition (https://doc.rust-lang.org/nightly/nomicon/races.html)
        Leak memory
        Fail to call destructors
        Overflow integers
        Abort the program
        Delete the production database

Yeah, for now this is one of the bigger drawbacks. The officially supported platforms are:

Windows (7, 8, Server 2008 R2)

Linux (2.6.18 or later, various distributions), x86 and x86-64

OSX 10.7 (Lion) or greater, x86 and x86-64

There is supposed to be ARM support in the works.

I want to see a useful language with automatic bounds checking that still compiles to native code. That anyone actually uses, so it has some kind of community built around it. That was well designed, not faddish, and not pushed by corporate marketing like Java was.

https://www.rust-lang.org.

God damn it, each time I have to patch one of these kinds of bugs it reminds of how we need to start rewriting all of our software in Rust. Face it, Rust is the future. Rust will soon be the only option. If you don't know what Rust is then let me quote to you from its home page: "Rust is a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety." Rust is developed by some of the best programmers out there, including Patrick Walton and Steve Klabnik. Now that we have Rust I don't think that there is any need for C, C++ or even Ada. Rust is the language to use from now on.

It'll be another dangling pointer, buffer overrun/read, integer overflow, etc. Time to stop using stone axes and sharpened sticks. We have tools now that can end this nonsense. We need to use them.

Not disagreeing with you, but a nullptr-to-reference cast would at least crash immediately (unless you have a compiler that takes "undefined behavior" too literally). Here's another contrived example:

const char *c = std::string("oops").c_str();

I'm not a c++ expert but I'm pretty sure 'c' now points to freed memory. The real problem is that the code will usually work until a customer runs it. And solutions like valgrind aren't always optimal (consider code coverage and execution speed) or even necessarily available, depending on your platform.

Rust eliminates this class of errors (and several others) entirely, unless you are abusing 'unsafe' (which you can at least grep for in your code) as you mentioned.

I would like Rust to succeed. In several ways, it is basically a 'better' C++ without the C baggage that a lot of people seem to want, and it is clear that Rust's developers have put a lot of thought into it. Still, the language has its warts and oddities. My biggest concern is that support for implementing intrusive data structures (you can Google that, but the Linux kernel's double-linked lists is an example) seemed to be possible, but not Easy, and I think it should be. I also haven't wrapped my head around Rust's lifetimes yet, but it looks clunky. Other things (slow compiler, incomplete library support) should get better with time.

I wish the Rust guys the best of luck, and look forward to using it.

We've got breaking news going on right now, guys. Rust 1.0 has been released!

This is a prime example of why we need to use the Rust programming language for all software development.

This is how the Rust website describes Rust:

Rust is a systems programming language that runs blazingly fast, prevents almost all crashes, and eliminates data races.

Rust even has guaranteed memory safety and threads without data races!

Rust is a language developed by some of the greatest minds in the industry, including the great Patrick Walton, the superb Brian Anderson, the glorious Steve Klabnik, and even the mightiest programmer known to have ever lived, Yehuda Katz.

Rust's development team also uses GitHub, which further shows that Rust is developed by people who know how to do things properly.

Rust 1.0 is on the horizon, so there's no excuse for not using Rust these days.

Rust is where it's at. Rust is what we need. It's what we need now.

Nobody said writing a compiler is easy. But we're talking about a compiler for Rust, written in Rust, in this case.

The Rust web site states very prominently that "Rust is a systems programming language that runs blazingly fast, prevents almost all crashes*, and eliminates data races." (emphasis added).

Even the asterisk message only says "* In theory. Rust is a work-in-progress and may do anything it likes up to and including eating your laundry."

For a language that explicitly claims that it should "prevent almost all crashes", even the people who should know how to use it best (its creators) seem to run into an awful lot of crashes on the multiple projects that they've worked on using it!

Have you actually tried Servo? It doesn't even have a usable UI

Yes, I have. You can use servo-shell

the date then became May 2015. I don't have much faith in them meeting that deadline.

You don't need faith. It's software, not religion. Here's the Rust 1.0 schedule, so why whine?

You worry too much. Relax, take a rest. You'll be happier.

This is a bug. The same bug could happen with any codec

We're not talking about codecs as much as we're talking about implementations and what you're free to ship without a patent license. If a codec is implemented in, say, Rust, then a whole class of security problems are mitigated by the design of the language. You can implement an MP3 decoder in Rust right now, but someone has to pay the patent licensing in order to ship it, which is antithetical to the goals of many software projects and frankly to the Web in general.

Or use a language like Rust which aims for memory safety without garbage collection. Servo is implemented in Rust.

MEMORY SAFETY

As do countless other languages.

NO RUNTIME

You're joking, right? Every language has a runtime. From the Rust documentation:

Rust includes two runtime libraries in the standard distribution, which provide a unified interface to primitives such as I/O, but the language itself does not require a runtime. The compiler is capable of generating code that works in all environments, even kernel environments. Neither does the Rust language need a runtime to provide memory safety; the type system itself is sufficient to write safe code, verified statically at compile time. The runtime merely uses the safety features of the language to build a number of convenient and safe high-level abstractions.

That being said, code without a runtime is often very limited in what it can do. As a result, Rust's standard libraries supply a set of functionality that is normally considered the Rust runtime. This guide will discuss Rust's user-space runtime, how to use it, and what it can do.

1 What is the runtime?

The Rust runtime can be viewed as a collection of code which enables services like I/O, task spawning, TLS, etc. It's essentially an ephemeral collection of objects which enable programs to perform common tasks more easily. The actual implementation of the runtime itself is mostly a sparse set of opt-in primitives that are all self-contained and avoid leaking their abstractions into libraries.

The current runtime is the engine behind these features (not a comprehensive list):

I/O
Task spawning
Message passing
Task synchronization
Task-local storage
Logging
Task unwinding

IMO it's much cleaner to consider code as a series of transforms of varying kinds than a grab bag of tools.

I agree entirely - functional approaches tend to result in much more elegant code, where suitable.

I like Coffeescript's switch [coffeescript.org], but that's partly because I like having every construct being an expression, removing an element of the code/data divide.

That looks very similar to Rust's match construct, which is basically the same thing but with C-style syntax. Another useful feature I've seen (that would be incompatible with Python's preference for duck typing) is D's final switch, which ensures that cases exist for all members of an enum.

I have been mulling similar question for myself for some time. i.e. where should I spend my limited hobby time: learning Obj-C or C++?

In the last few months Rust has caught my attention. Even then it's not yet at verstion 1 (at time of writing its at alpha-1), I really like the concept and what they are try to achieve with the language.

My comment will probably be burried, but if you do read it, spend a few minutes wondering around their web site. For exmaple their 30 minute introduction to Rust.

I have been mulling similar question for myself for some time. i.e. where should I spend my limited hobby time: learning Obj-C or C++?

In the last few months Rust has caught my attention. Even then it's not yet at verstion 1 (at time of writing its at alpha-1), I really like the concept and what they are try to achieve with the language.

My comment will probably be burried, but if you do read it, spend a few minutes wondering around their web site. For exmaple their 30 minute introduction to Rust.

http://www.rust-lang.org/

Somehow my link got eaten. It actually is expect.

A safety systems programming language sounds great but they had to ruin it by putting a garbage collector in it. This makes it useless for systems programming.

No they didn't: http://doc.rust-lang.org/compl...

Rust's raison d'etre is fast but safe programming. It seeks to achieve this by expanding the type system with the different pointer types owned, borrowed, and garbage collected, as well as explicitly unsafe sections of code.

Rust does not however attempt to address array length issues via such type level mechanisms. Instead, they use compile time lengths for arrays and offer for slices for arrays with run-time lengths. That's okay, but it ignores swaths of optimizations.

Ideally, you want a fully dependently typed language like Idris for this because dependent types let you tell the compiler to prove at compile time that two arrays must have the same size.

Idris itself is a research language that doesn't currently worry about speed, but one research topic they're exploring is uniqueness types, which hopefully should provide the "right" abstraction for Rust's pointer types.

Anyways, I sincerely hope that Rust eventually kills off the dumb C style languages like Go, but it's not the last word on fast but safe programming.

Interesting alternatives to C seems to be D, Vala and Rust.

Perhaps C# with the .NET Micro Framework?
Or C# with .NET Native?

Mozilla Labs projects is for experiments.

Things they've started which seemed like good ideas always moved on to be their own projects.

For example the Rust language:
http://www.youtube.com/watch?v...

Now almost at 1.0:
http://blog.rust-lang.org/2014...

If there is a problem, it might be that they haven't started any new projects.

We desperately need a language for OS work that is protected more than C is.

http://www.rust-lang.org/

Instead use safer languages like Pascal, Eiffel (design by contract), Ada, etc.

Yes, I agree. And as mentioned in the article, Rust is a good choice here too, or will be once it gets to version 1.0. I think the plan is for Rust to get version 1.0 this year.

Use Rust. It's not at version 1.0 yet but it's promising. See some comments on Rust's benefits for security. And some blog posts by Andrew Ruef and Patrick Walton.

Rust

All the more reason to consider using new programming languages like Rust which are built with memory safety in mind. Better programming languages are by no means a silver bullet for security problems, but they help.

* memory management is explicit [merriam-webster.com] -- what does this mean?

Quantifying the Performance of Garbage Collection vs. Explicit Memory Management
Automatic vs. Explicit Memory Management: Settling the debate

* deterministic [merriam-webster.com] -- what does this mean?

I thought it was self evident. Here is a discussion of the matter.

* endemic [merriam-webster.com] use of a garbage collector... -- what does this mean?

Pervasive would be a better word. Languages that make garbage collected allocations for most or all things. For example in Java, aside from primitives, all allocations conceptually occur on the a garbage collected heap.

reference-counted heap objects

Reference counting: counting the number of references to an object.
Heap: an arena of memory maintained by a memory allocator. Also CPUs typically have no knowledge of how software manages heaps. You may be thinking of virtual memory
Objects: object in the generic sense of some amount of memory managed on a heap. These lecture notes show the same usage. The editors of this page also use the word 'object' in exactly the same manner when discussing pointers. It's not that hard to follow.

Putting it together we have objects on a heap for which reference counts are maintained; reference-counted heap objects.

"exchange" heap -- what does this mean?
* "local" heap -- what does this mean?

The link I provide to Patrick Walton's blog would get you there. Also, there is documentation, Sorry if discussing a new programming language involves terms you haven't heard. Computing can be like that sometimes.

(note: there is only one "heap" on most CPU architectures, so now we have added abstraction)

Now you are definitely confusing heaps and virtual memory. There are usually many, possibly thousands of heaps on a system at any given time with many distinct implementations of which the CPU is entirely ignorant. Memory allocators and virtual memory are different things.

* via an "owned" pointer -- what does this mean?

Similar to a C++ auto_ptr or unique_ptr. Again, the link I provided would get you there.

* wild pointers -- what does this mean?

Dangling pointer and wild pointer are synonomous.

Use of the exchange heap is exceptional and explicit yet immediately available when necessary -- what does this mean?

I provided a link directly to a discussion of this.

Memory "management" is reduced to efficient stack pointer manipulation -- uhh, what? the language sits around modifying content at %esp and %ebp along with some offsets? sounds far from efficient)

Incrementing a decrementing stack pointer registers is very efficient. Offsets are computed at compile time and the instructions typically require one CPU cycle and no memory access, given a naive model of a CPU. These techniques are a ancient and ubiquitous. Sorry you weren't familiar with them.

or simple, deterministic destruction -- what does this mean?

Others seem