Of course. But subtextually: had you replaced C++ with Python, you'd have had the same outcome. Obviously, a significant advancement in Rust is that it's feasible to replace performant C++ programs with Rust, and not feasible to do that with Python. But that's perhaps a performance and logistical advance, not a security advance.
I get that the combination of [memory-safe, non-garbage-collected, performant, natively-compiled] has security implications for systems programming. But developers shouldn't be swapping their Python code for Rust if security is their primary objective.
I think Rust is a security advance because it makes memory-safe programming practical in more domains than it used to be. The fact that Python has memory safety doesn't help (for example) browser engines, because it's too slow and requires too many dependencies. Rust didn't invent memory safety, of course, but it's bringing the security benefits of other languages to places they couldn't reach before, and I would argue that that itself advances security. To make an analogy, Rust is like the effort to add stronger ciphers to TLS as opposed to the effort to invent new ciphers; both are important, the latter because it creates stronger systems and the former because it makes those stronger systems more widely deployed.
I hope that Rust will be more memory safe than Python in practice. Python just doesn't have that "culture", and third party modules often have memory safety bugs.
Nobody sane would use C/C++ when they could get away with Python and nobody sane would use Python if they need to control the memory layout and access patterns like in C/C++.
Obvious candidates for such use-cases, besides kernel space, are games or video/audio systems or other stuff in which dropping frames is unacceptable, real time systems which includes some web services, or simply applications that have to use a lot of RAM, like databases, since even the most advanced mainstream garbage collectors are still awful at managing huge heap sizes.
And it seems to me like the target for Rust is pretty clear - that people are even considering it as a replacement for GC-ed languages is a pretty good achievement, but I don't think somebody wouldn't notice the stark contrast between what is a systems language and a GCed one right from the 10 minutes tutorial.
And btw, there are some instances in which Rust is safer than a language like Java in a multi-threading scenario. In Java or other JVM languages, you can happily capture a mutable object inside a closure and then mutate it asynchronously, possibly in another thread, while not synchronizing or releasing control in the thread in which the capturing happens. Even if you're using high-level abstractions, like actors, futures, streams and what not, this possibility of capturing mutable objects from the context by mistake in closures that execute asynchronously is always there, so to write safe code that protects against accidents you have to get religious with immutable data-structures and whatnot. This isn't to say that Rust is safer than Java - I doubt that. But it has some interesting ideas in it nonetheless.
> But that's perhaps a performance and logistical advance, not a security advance.
Isn't it both, depending where you come from? And isn't decreasing the performance/security tradeoff a security advance when developers in the domain do not want to compromise on performance?
> But developers shouldn't be swapping their Python code for Rust if security is their primary objective.
OTOH developers building up security primitives/building blocks aren't doing so in Python in the first place, and doing so in Python would mean it's not easily accessible for {anyone not using Python}.
Yes! I'm struggling to articulate the sentiment that boils down to "if you're already deploying Python or Scala or Ruby, Rust is unlikely to drastically improve your security, and rewrites are sure to harm security at least somewhat".
If you're currently shipping C/C++, Rust seems like a great bet. Don't write C/C++ in 2015.
Yeah Rust isn't safer than an already memory-safe language (though it might be faster, then again it's also quite a bit more work wrt e.g. Go). but
> Don't write C/C++ in 2015.
That probably isn't going to stop, even ignoring performance ricers the bottom of the stack does need control, does need good performances, and more importantly does need to be usable from just about everywhere.
You can't really/easily use a scala library from MRI, or a CPython one from Go (it's already hard enough to use a CPython library from Pypy). If there's a C interface and little to no runtime assumption however you're good to go. Currently that means C or C++ (with a nice extern C ABI/API). If it could be something safer in the future, that would probably be a good idea.
> You can't really/easily use a scala library from MRI
You can easily link Scala with Ruby by running both on the JVM. Assuming you really want MRI, on the client-side that implies running 2 processes with their own runtime at least, instead of just one process. There is a reason for why I've heard of Ruby developers choosing JRuby to deploy Ruby apps, because having only one GC for managing a long-running process is expensive enough, having more than one gets awful fast.
On the server-side on the other hand, you have the freedom of deploying your stuff on multiple servers, which is often the case so you can use a micro-services approach - in our current project the front-end is developed in Ruby / Javascript and the backend in Scala, linked through a web service API. The great thing about this, besides using the best tool for the job and so on, is that people can work on them in parallel.
IMHO, I think the reusability of C is overstated. I haven't used C libraries in any of the JVM apps I ever developed and this reduced the headaches I've had back in the days when I did stuff with CPython or Ruby MRI. And given a potent runtime, you can make both Python and Ruby run on top of it with reasonable performance (compared to their reference implementations).
Wow, strong statement! I am not going to weigh on this other to ask for clarification - do you mean not use C/C++ at all, or only in the context of security applications?
Almost all applications are "security applications", in the sense they are security sensitive, these days. If I pull data over the internet, my first person shooter now can't allow buffer overruns. Bad Things may happen in almost any environment.
Some people have to write C/C++. Kernel developers, for instance. But most people who write C/C++ in 2015 don't really have to. For every low-level game programmer or RTOS embedded systems use case you'll cite, I'll cite an unforced error that occurs 5x as often, such as "we wrote our custom database engine that only ever runs serverside in C".
"But most people who write C/C++ in 2015 don't really have to."
While greenfield projects might be able to start with a new language established products have quite a lot of inertia. Any production environment needs to factor in personnel training (or, hey, fire the tens of C++ developers and replace them with equally skilled Rust developers who are as famimiar with the domain requirements as the last lot..) and the costs and risks in architecture changes. Switching languages might not be even then feasible, given a common big ball of mud structure with computational modules, UI and domain logic cooked together into a delicious mess.
Even if the long term costs of a codebase written in Rust were, say, the tenth of the costs of a similar codebase written in C++ often the product development costs are not that large percentage for established ISV:s.
When the next greatest browser gets written in Rust, then industrial users start paying notice.
Why would I care of how organizations develop software? Because I need to get paid and I work inside an organization... I write C++ to earn my living, I don't want to write C++ home for fun.
So at home I wouldn't write C++ any way and at work I really don't have a choice :) - Of course, peoples situation vary.
On the other hand, Rust is not ready -- either from a stability or library perspective -- in 2015, most likely. What are you recommending the C/C++ programmers go to?
If you are using C or C++, it probably means you cant use those you have pointed out.
People can port Python and Ruby stuff to Go for instance and have advantages doing it, because the logic was already suited for managed languages.
But for C and C++ stuff is unlikely.. and for Rust the other possible option.. its kind of a productivity killer compared to C (even with the headers nonsense).
Its always a matter of tradeoff, and its not a casuality that C are alive and kicking til this day.. the language really has its strenghts.. and while every new lang in town claim they are the next C killer, well, in real life is much harder to make such a claim, and its not just because of the "old code that has to be maintained".
I know you are a security focused person, but security and safety is not the only one reason we choose a language to start a new project.
So until a really strong contender shows up (i particularly dont think Rust is it, but im sure there is a golden niche for it), they will still be with us, til we brake the current computation paradigm and algol and lisp langs doesnt make sense
Yes, because you remove a whole class of errors that might be exploited. Might be hard, might even be impossible, but they are there waiting to be taken advantage of.
Interestingly enough, very high performance java is a bit like rust. Almost all memory safe, except a few (10-100) lines off crazy unsafe stuff.
Of course it is possible that your C code has no memory issues and is verified to be safe, but I would not bet any money on it.
Also at the moment custom code is the last entry point for a hacker, but once all other things are hardend its the last guaranteed leak in the ship.
I also understand where C semantics can lead to faster code than e.g. java today. But I suspect that edge to disappear within the next 3 years. Just like java is going to make heterogeneous compute easy its also going to improve streaming over memory for speed where needed.
You know, I don't know if even kernel developers need to write in C/C++. Sure, those are the languages in which most kernels seem to be written, but couldn't kernels be written in, say, Lisp or Forth and have almost as much performance and at least slightly more security?
Security is never a primary objective. If it were, blah, blah, powered off, locked room, blah.
Security might be the most important objective secondary to getting things done, but because it can't be primary, there will always be security considerations for the engineer. Nothing is perfectly safe.
I get that the combination of [memory-safe, non-garbage-collected, performant, natively-compiled] has security implications for systems programming. But developers shouldn't be swapping their Python code for Rust if security is their primary objective.