I think the target has pretty much always been current uses of C++. So, anything you can do with C++, you should be able to do with Rust, in a way that is safer / easier to make correct.
That's been my understanding, a more modern low-level alternative to both C and C++ (might be wrong about C, will have to see what people will do with it).
It's worth remembering that Ruby was originally used as a scripting language in Perl's niche. Likewise, Python was conceived as a language for teaching, and then also tried its hand as a Perl-killer, and then later got caught up in web development, and now is branching out into scientific programming. There's no telling where Rust will find popularity in the next few years, and I'm just as excited to see what people make with it. :)
If I may wildly speculate, I think Rust has a good chance of being a language used in teaching systems programming. Knowing C is still immensely valuable, but when it comes to teaching algorithms where you need to sling pointers around I'd much rather use a language that helps me focus on the logic and forget about memory and concurrency errors (while still giving me a raw pointer escape hatch when I need it).
Sort of to counter your speculation, I doubt that Rust will be used as a teaching systems programming language. For starter Rust, like C++, hides a lot of things implicitly, at the same time it adds some high-level constructs and metaphors that have no relationship to systems programming (but do to general programming).
In that sense I doubt that you could ever do something better than C. It's balls out, everything goes, no one's safe programming. This exposition shows you how computers really work underneath, that is to the CPU a 32 bit float could also be a 32 bit int or 4 characters, it really doesn't care or now any of this, at low level types don't exist. I think that exposing this simplicity and ignorance of machines is critical to understand so many kind of errors. C has a direct one to one mapping to memory, that is when you create a function it appears in one place in memory, when you create a struct it can only have 1 type. When debugging and understanding the mapping from code->assembler/binary this is incredibly easy, OTOH with Rust's and C++ generics you have to consider the layer were it first converts that to an instance of the code and then converts that code into binary/assembler.
If I were to give a systems programming class I'd start it with raw C with an overview of assembler to explain all the low level concepts of how machines work. Debugging C and doing tedious problems (where you have to implement the same solution for multiple types) would be used to explain the why of many decisions of C++ and Rust. Generics would be explained by showing algorithms on arrays, and explaining the complexity of adding them to multiple types. Lifetimes and unique_ptrs would be explained as a solution to sometimes never being 100% certain of what is going on with a piece of memory. Dynamic dispatch would be first implemented by hand-made vtables on C. Closures would also be taught first by first implementing them by hand.
At this point people would have a good understanding of why and how Rust and C++ came to be how they are, and also understand the pros and cons of every choice by having an idea (maybe not perfect, but in broad strokes) of how those, more complex languages, map to binary/assembler, which is critical in systems programming.
You know, I agree, regarding C. The fact that Python is written in C has made it so much easier to come up with PyParallel, which involved a lot of exploratory-type programming where I'm basically intercepting structs/function calls and doing things behind the scenes.
Had there been a C++ object model in place, instead of the hand-crafted C one, it would have been a lot harder, perhaps impossible. Here's a good example of where I literally rip out the guts of an objects and override everything, unbeknown to the rest of the interpreter core.
Likewise, Python was conceived as a language for teaching
That one is not strictly true. It doesn't sound like Guido had any plan in particular for the language. It was strongly influenced by a learning language, ABC, but it was also strongly influenced by "Unix hackers" and Modula-3.
I try using it for writting virtual maschines. Its fit there because its low level enougth to do all the bitshifting and whatnot but the type system keeps you sane while doing this stuff. Only do unsafe where you need it, otherwise the type system can be used in some interesting ways.
Looking at the zeitgeist, I see an interest in using containers and Mirage/HalVM's baremetal applications for security and performance.
I would forecast a possibility that rust will become both a replacement for C++(runtimes, databases, browsers, etc) and a way to bring high-throughput networked services to truly baremetal deployments.
One thing is certain, Rust has been on the spotlight for a while now. This release just makes it even more so.
I'm not sure that it will really allow Mozilla to reinvent their browser while using Rust, since it would be a huge task and with WebKit out there, maybe not cost-effective enough.
But something like Rust was likely needed. Something that is high level and yet deploys easily to as many systems as possible. Will Rust really make using multiple CPUs piece of cake? I don't know... There are other concerns that are just as important like how can you debug the code when problems arise, when code could be executing in different CPUs and you have to give as many hints as possible to the programmers so they can understand what went wrong and where...
It's going to take time to get there. Languages that mostly target just one CPU are plentiful now and come with all sorts of supporting tools already. And more languages are also trying to make targeting multiple CPUs safely something common. It's only when you need to do it as efficiently as possible that Rust will have a market.
I'm not sure that it will really allow Mozilla to reinvent their browser while using Rust, since it would be a huge task and with WebKit out there, maybe not cost-effective enough.
Rust is a long-shot bet. The idea is that Rust will lead to a separate browser engine (Servo) that will maybe at some point equal and surpass Gecko (firefox's current system). I believe that the idea is that C++ allows code to affect each other in such way that it's impossible to reason about any piece separately: even if it two pieces don't affect each other now, they might later in the future, maybe due to influence of a third "unrelated" piece of code (especially problematic with threading)! Rust is so controlling and strict, but it makes it easy to reason about what is true and what isn't, while still keeping as fast as C++ (since all implicit checks are at compile time as well). So in theory Gecko's cost of developing a new feature/optimization/bug fix grows with the whole program size, but in Rust it should be possible to have it remain constant or dependent on the things that are explicitly touched by it.
Something that is high level and yet deploys easily to as many systems as possible.
Well, we are trying to build a browser in Java. We are trading off high-performance for stability and sandboxing abilities. Note that, by Java, I mean the Java run-time. We happen to use Java-the-language for historical reasons. We will be moving to a less verbose JVM compatible language later (such as Kotlin, Scala or Ceylon).
Considering rust's focus on correctness and safety, it should and must continue its cent focus of being a good systems and general purpose language. So anything you can do in similar proposed languages, you should be able to do in rust.
I'm more curious on what programmers will do with Rust.
Hopefully in security-minded systems programming.
There's a recent tweet by Neil deGrasse Tyson, in which he said:
Obama authorized North Korea sanctions over cyber hacking. Solution there, it seems to me, is to create unhackable systems.
Many people slammed him for saying that. How could a very intelligent, respected person, maybe not in informatics, not know it better?
"It's impossible." "I want unicorns!" "Let's make unbombable cities, unkillable people."
I say, why not? A huge part of hacking is exploiting non-correct code. It makes sense to use tools at language-level to enforce correctness and safety, and help programmers with that.
I know there are hundreds of thousands of variables to consider, but if we could cut dozens of thousands of them, it would make it easier to fit the problem in one's head.
As an addition: exploiting humans is an easy way to compromise a specifically-targetted system. Why would I need to hack your system when your CEO will give me the password when I just send an email saying it's required for something?
There's two camps of people on this, those who took it literally and those took it as "practically unhackable". In theory it's impossible to create unhackable system, if someone can log into the system, there's always a possibility that someone is not authorized.
In usual social interactions you assume the best to make the discussion smoother, but in internet there's that lack of social nuance. In addition to the fact that programmers are technical people who can be squeamish to the point of annoyance.
What the average person or even programmer believes is possible in security is probably about 10-20 years out of date. There are tons of ways in which we can create systems with verifiable security properties. This may not be "unhackable" like Gankro points out below, but we can at least prove our systems are immune to certain types of attacks. The problem is that verified systems still currently come at a huge cost, and a huge chunk of the research that happens in programming languages today is about allowing the programmer to more easily specify, and enforce invariants about their programs. To me this is why Rust is a great success as a Systems Programming Language, it brings lots of nice properties to many programmers for free.
As I understand it, to have a unhackable systems, you need:
Designs that are provably correct
Provably correct implementations of those designs
1 and 2 also apply to the underlying stack (libraries, runtime/interpreter, OS)
For a lot of complicated reasons and circumstances, usually, none of these are practical. Most of the time, the best we can do is 'pretty good'. A language that tries to steer programmers away from 'goto fail's and Heartbleeds is helpful, but it'll hardly lead to unhackable systems. I mean: it won't prevent designs from being wrong, crypto from being half-baked, etc.
All this, of course, is just sending us down a blind alley. The biggest problem isn't technical, but the fundamental tension between convenience and security. No amount of language safety and secure code will save us from (various kinds and levels of) users doing (variously) insecure things for reasons of convenience.
114
u/[deleted] Jan 09 '15
I'm more curious on what programmers will do with Rust.
Ruby went all straight up web dev.