Yes, but his brilliance was in minimising the number of components required to perform a certain function. His "art" was in solving two pragmatic problems. a) Correct function of device and b) minimising the costs (components). The constraints (physical and budgetary) are what channeled his creativity.

Personally I think that one of the problems with software development is that we don't treat it like engineering enough. Not engineering in the sense of building a bridge, but engineering in the sense of design (designing a circuit for example). Engineering is inherently a pragmatic discipline where creativity is constrained by various physical, budgetary, and time constraints. Because software has less of the physical constraints, I think that the "art" side can get a little carried away at times. But the main issue is lack of discipline; and that is more of an artefact of the culture that can be associated with software development, rather than anything inherent in the work itself. I'm biased (with an engineering background), but I think that many software companies could benefit from the attitude that comes with engineering.

Yes, but somebody had to do the proving. As that great fount of wisdom, John Wooden, once said; when we are young we tend to see all change as progress, but as we mature, we can forget that there is no progress without change. It's not easy to know when you should take on a new technology, but that doesn't mean you shouldn't take on a new technology.

I didn't ask can we get to the speed of light, I asked "does space travel become possible?" We would just need to go at some % speed of light. I thought this was impossible at the moment due to accelerating == throwing stuff over the side, and I had assumed even with EmDrive physics defying abilities it would still take "too bloody long". But perhaps not is the point.

The fact that time slows for you as you go faster; doesn't this imply that if you could travel at the speed of light, then you could reach anywhere in the universe in 0 relative (to you) time? I mean the thing you were aiming for might be gone by the time you got there, but still. If that EmDrive thing is a real thing, doesn't long distance space travel become a real possability?

Actually, the placebo effect still works even when you know it's just a placebo. Go on, give it a try. You'll feel better.

Astrology and Homoeopathy are both extremely effective, especially for difficult conditions such as mental health issues. Now sure, this is only due to the placebo effect, but doctors are pretty rubbish at exploiting the placebo and the placebo is extremely powerful! Something seems to prevent them from telling a patient nonsense that will make them believe they will get better and thus actually help them get better. Astrologists and Homoeopaths have no such issues, so this politician is completely correct that utilising astrologists and homoeopaths could help take the load of the NHS.

A millisecond is something like 4million instructions, so "a few milliseconds" can be a lot of work. A heap allocation that took a few milliseconds would be a significant concern. Also i think there is some confusion about "hard real time". Hard realtime simply means that a particular action must occur within a certain maximum time or the system is deemed to have failed. It's not about speed so much, such systems are generally running slower, it's about determinism. However it is correct to assume such systems are allocating memory less frequently. I'm getting the impression that you seem convinced that a GC has no drawbacks, only foolish critics. My own experience does not bear that out. One can work around the issues by using pooling and other techniques to prevent collections; but fundamentally a GC has a different mode of operation that means it works poorly for large numbers of objects tied to a medium term lifespan, suh as that crossing an I/O operation.

C++11 provides a new threading library which, don't get me wrong, I'm very happy about. I can finally write cross-platform thread related code without having to reach for boost or similar. However as with all languages (of which I am aware), that use threads, I can't simply look at a piece of code in isolation and determine if it is thread safe or not. There is no linkage between threads and data ownership. I still haven't had a chance to play with Rust, but what they claim is that all data is thread owned, so if you tried to write code that accessed the same variable from multiple threads it would not compile. The compiler catches the race conditions for you. Which sounds pretty good. Now in practise, you end up building fairly complicated abstractions on top of threads to avoid these kinds of issues (think tasks and contexts), so it'd need to be tried in anger to see if it made any real difference. Still it is very interesting and uniquely different.

Perhaps you should have tried to comprehend what I wrote then.

Just as an addendum: This is the feature that is missing from all current programming languages that I am familiar with, and the principle reason why threads suck as a general concept. I can't look at any data object and know it's thread ownership. I have to infer that by understanding the rest of the program. This is why we end up with elaborate task based libraries, wrapping threads in "contexts" and being careful not to cross boundaries. What Rust is doing here sounds awesome, but I'd need to try it on some real project to see if it's actually useful. Still I greatly appreciate your critique.

I think we are talking about different use cases.

That may as well be an eternity in any hard real-time application, or various finance systems as an example. The point isn't that you can't use Java/.NET in many many applications, it's just that there is a reason why C++ is still necessary for certain situations. This Rust thing looks like a potentially better systems level language (or it want's to be); addressing a number of issues that no language in this same space currently does.

Yeah, maybe you should re-read what I wrote before making assumptions. This is not a problem unique to C++, but something Rust appears to try and address.

I've never used Rust or even heard of it prior to this article, but your post here makes me hope that it gains mainstream acceptance. Modern Garbage Collectors are fine and work well in a large majority of uses cases but they fall down badly when the majority of your allocations are transitory objects of intermediate lifespan. Objects that last the length of the application run - fine, objects that are created and destroyed quickly - fine, objects that exist for the duration of an async I/O operation? Not fine. The GC becomes a scaleability bottleneck; the parallel processing eventually being throttled by that GC that can only run as a single thread (more or less). So systems that need high performance, large scalability and distributed networking etc are invariably written in C++. But in these C++ systems, ownership design is one of the most vexing issues and must be very carefully considered at all points, without any compiler support. The whole concept of threads and data ownership has exactly zero level built in conceptual support, and that sucks. It sounds as though Rust has been designed to resolve these issues for systems programmers. Which is a great idea.

Your argument here seems to imply that Rust is this great replacement for Java, and then argue why that make no sense. But it seems to me that Rust is really a great replacement for C++, and the kinds of systems that cannot suffer the burden of a GC.

[citation needed] As I have said previously on slashdot. Australia uses only cane sugar and obesity levels are similar. I think the issue is simply swapping fat for sugar.