Somewhere in this direction lies the post-C era. The post-buffer-overflow era. And do we need it.
It has been 6 days since the last CERT advisory for a buffer overflow security hole.
It has been 6 days since the last CERT advisory for a buffer overflow security hole.
However, if Rust doesn't get adopted by an OS vendor in their SDK, it will join the ranks of Object Pascal, Extended Pascal, Modula-2, Modula-3, Ada, Oberon,Cyclone, ATS.
This just to mention the alternatives on my lifetime, while ignoring the Algol and PL/I variants that existed before C was even born.
My point was about Rust real use case, systems programming.
B) A browser is about the beefiest user space program of which I can think at the moment.
Of course, the expectation would be that the said OS vendor would give more emphasis to Rust.
For example, C++ earned its place by being bundled alongside C compilers and having things like CORBA, OpenDOC and Windows pushing for it.
> Anyone could write and maintain one for Rust, so what's the difference?
This is how the alternatives to C and C++ faded away of the IT market. The vendors could not keep up with the tools that the OS vendors had on their SDKs and many developers got fed up with writing FFI code.
Something about this doesn't sound right to me. I think the third-party factors are overwhelming. After all, the basic I/O and other low-level stuff is going to be there on any supported OS. But availability of compilers/VMs/interpreters, and good libraries for GL, Qt, audio, etc. are all at the top of my reasons for not going with a particular language that would otherwise be suited to the task.
I think Rust is in a better position than one would normally expect. People are looking at it for web dev, and web devs tolerate more diversity in their language of choice. The existence of Go, and the frequent (if misguided) comparisons to Go helps, since writing a web-facing app in Go is a sensible thing. I'm not sure if that will work out, but if it does I think it's a trump card. No web language ever died, except things like Cold Fusion and languages that were superseded by offerings from their own vendors.
On the other hand, I think Rust is better suited to game development. I don't know of Carmack being sweet on Rust in particular, but a few years ago he did start talking about how it would be nice if id could use safer languages (though his biggest complaint was about script writing.) More to the point, Rust is growing a collection of gamedev libraries. Piston is ambitiously trying to curate an entire ecosystem. This is a rare phenomenon among the pretenders. Piston is in no shape to take over the world today, but if it continues to grow and polish it could turn a number of heads.
I am a big fan of Wirth's languages.
I'm not saying that security holes are nothing to worry about, as I am no less irritated by buggy programs than anyone else, but the alternative might be worse.
Why is that? I don't see why this has to be true.
A device maker which makes completely open machines is going to get out-competed with low-margin knock-offs, or generic branded copies from places like china. This is good for the consumer, but not good for a business's bottom-line. This is why there are very few branded computers these days (at least, desktop). You can count them on your fingers.
* Good will among the community
* More familiarity with Cell software development for clusters (although this was behind a VM)
* Import tax savings in certain territories due to the box being classed as a ‘computer’ instead of a ‘games system’.
Which do you think was most important? (hint: it’s the last one) Conversely, when the ability to run Linux was pulled a hypervisor exploit had been discovered. Now the cost equation tipped back the other way. The import tax hit was still there, but the machine had halved in price since launch so that wasn’t as painful. The community had moved away from PS3 clusters as they weren’t energy effective any more: not as painful. The major pain point from removing it was losing the goodwill of the community, but when balanced against the piracy implications they made their decision.
Personally I think they should have patched the hypervisor holes and kept the functionality, but you can see why they decided to remove it.
Walled gardens and eroded digital/computational liberties are here to stay, and even more so in the future. The trend has been that "hacking the device" has become harder and harder, and devices have became more and more closed and controlled. I don't expect this trend to change any time soon. I sure as hell wish it did, but why would it?
We are living in very interesting times indeed...
No such thing. There is no protection once someone has physical access to the hardware.