> 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?
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}.