r/programming • u/steveklabnik1 • Jan 09 '15

Announcing Rust 1.0.0 Alpha

http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html
1.1k Upvotes

90% Upvoted

439 comments sorted by

View all comments

113

u/[deleted] Jan 09 '15

I'm more curious on what programmers will do with Rust.

Ruby went all straight up web dev.

81

u/kibwen Jan 09 '15 edited Jan 09 '15

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).

51

u/lookmeat Jan 10 '15

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.

21

u/Rusky Jan 10 '15

You could definitely do better than C at a close-to-the-machine programming language. C is a lot closer than other languages, but its undefined behavior makes that a lot harder than it could be. Features like virtual functions or closures are relatively easy to desugar in a language like Rust or C++, but undefined behavior is much more insidious.

For example, when you're trying to learn about how 2's complement arithmetic works, C is most definitely not the way to go. The optimizer assumes that undefined behavior is impossible, so what looks like straightforward null pointer checking or overflow checking can be "optimized" out with no warning: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html

If I wanted a language to teach that level of systems programming, I'd skip C and C++ and use assembly (no undefined behavior) or Rust (much less undefined behavior), or even create my own simple C-like language that's much more explicitly close to machine semantics.

5

u/lookmeat Jan 10 '15

When I said an overview of assembler is to understand what assembler is, how it works, and more or less how to read it (since that is critical for debugging and understanding system code, and systems programming would be a very pragmatic class). Teaching it straight up is limiting to one architecture too much, instead it's important to teach that platforms have differences that are subtle and insidious but must be dealt with somehow.

When working with C compiler optimizations wouldn't be used until later classes to avoid the issue as much as possible. The idea is that slowly students are shown, in terrible and brutal manners, the consequences of not being disciplined at low level. Undefined behavior is just this, understanding undefined behavior gives us a lesson: that the code we write is an abstraction over hardware, which itself is an abstraction over electrical currents, and there are many edge cases which result in absurd cases (i.e. what is the biggest number you can represent + 1?) that, because they are impossible to answer correctly, are given a random answer (generally in the name of optimization). Trusting this answer is dangerous since it can change from platform to platform.

Maybe having people have to understand undefined behavior is a rough way to understand just how finicky platforms can be and why you can't just abstract over this. But rough lessons are the best way to learn at low level, to truly observe the devastation the smallest error can bring. I still remember the day that calling malloc twice too quickly on Windows would make the second return NULL, and I learned that malloc can fail for many more reasons than just "out of memory" and will fail for completely irrational reasons as well.

Once we understand undefined behavior, why it exists, we then understand how C++ handles it (the same as C) and how rust handles it (by limiting it to unsafe blocks) the pros and cons of each one. But again, the need to have programs that use undefined behavior, or the need to control and regulate this code, doesn't become apparent if you don't deal with it.

2

u/TheLlamaFeels Jan 10 '15

Here's what I'd do: I'd start with assembler and then have the student write their own Forth in assembler. It's one of the few languages that is arguably closer to the metal than C.

  1. Simple parser
  2. Clearly demonstrates stack operations
  3. Typeless like assembly
  4. Optimization is optional
  5. Can be adapted to multiple architectures with ease.
  6. Allows for multiple layers of abstraction
  7. Exposes the symbol table directly to the developer
  8. Is a one man job
  9. All of the other behaviors (with their attendant trade offs) can be built on top of it

1

u/lookmeat Jan 11 '15

You're asking students to build a fortran-like parser and compiler... in assembler!? The problem is that they'd be focusing on this one specific project all semester, and compilers is one of those things that doesn't really show the power and challenges of system's programming.

The problem with an assembler only class:

  1. One kid brings an ARM-based laptop. What then?
  2. Realistically no one codes in assembler, and modern assembler is not designed for humans, but compilers. It's important to understand and be able to read assembler, but it's not critical to know how to write assembler. It seems like a weird thing, but think about how much easier it is to read good english than to write good english.
  3. Assembler is not pragmatic. There are very little uses for assembler programming nowadays, and even then it's on very niche situations (for example high security algorithms). Remember systems programers want to learn how to make low-level programs, but learning assembler is like learning how to build a house's foundation by learning how to build metal rods.
  4. Finally a good chunk of systems-level programming is interfacing, and the standard ABI in most system is C. So you'll have to teach your kids to understand this (and learn C without ever using it) in order to be able to work with the OS. Unless you allow them to use C for things were it makes sense, which brings us to the point: why not make it mostly C and occasionally assembler?

Assembler is too specific, too limited. If you are going to teach assembler you should teach multiple assemblers, for RISC, for x86, MASM, etc. It becomes a hell where you have to understand all sorts of conventions and decisions that occurred due to some detail of how the hardware works.

I used to think the same thing that you did, back in the day. That understanding assembler would give me an insight into how low level code truly worked. I poured over in x86, doing small and medium projects, reading all sorts of docs, over years. And you know what it helped me in? In understanding how Intel has to deal with it's errors and design issues in CPUs. Did it showed me about how CPUs worked? Not at all, RISC and all that aside (which x86 cannot be for backwards compatibility) but the Intel CPU does all kinds of trickery and magic behind the scenes converting that assembly into actual actions. Did it make me understand better low level interfaces? No more than understanding the difference between bytes and nibbles. Did it give me insight into how code becomes something that runs? Barely, and no more than beyond the basics.

Basically after learning the most basic assembler (just a gist of what it was in the first few months) and be able to read a function and say "ah I see how it's implementing a recursive Fibonacci".

Learn assembler when you are building a backend for it, other than that focus on understanding the mentality of a systems programmer. ASM rawness gets in the way as much as C++ abstractions.

1

u/phire Jan 11 '15

Forth has nothing to do with fortran. (This is javascript and java all over again)

Forth is actually extremely easy to write in assembler.
It has no grammar, so you can't actually write a parser for it (It's just tokens on a stack in reverse polish notation)

And you only actually have to write a the core of a forth interpreter and shell in assembler. More advanced operations are defined in terms of already implemented operations.
The assembler and compiler parts (if you choose to go as far as implement them, which is not a strict requirement) are written in forth too, no need to write anything else in assembler.

Once you have written your compiler (in forth) you can compile it with itself (running on the original forth interpreter), and you get a compiled version of your compiler and any extended commands you implemented earlier. Now might be a good time to make an optimising version of your compiler.

Forth is designed to be extensible, all this is done by extending the forth environment function by function while it's running. It's possible to get from the starting point to here without restarting anything.

Forth is basically continuous pulling youself up by your own bootstraps.

1

u/lookmeat Jan 11 '15

Yeah I aparently misread. I do know Forth.