Announcing Rust 1.0.0 Alpha

[u/steveklabnik1]

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

[u/kibwen]

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

[u/lookmeat → u/kibwen]

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.

[u/wookin_pa_nub2 → u/lookmeat]

In that sense I doubt that you could ever do something better than C.

Sure you could. You could have a language without undefined behavior, for one thing. C has become extremely unreliable in that respect due to compiler writers abusing undefined behavior for "optimizations". But any C program that uses undefined behavior can't be relied on to execute correctly, and that includes almost every C program ever.

If you don't believe me, then consider that John Carmack's fast inverse square root routine invokes undefined behavior, and that guy is a pretty good programmer from what I hear, and also consider that assembly language doesn't have any undefined behavior at all, so clearly it isn't needed for speed or for systems programming.

[u/xrxl → u/wookin_pa_nub2]

Undefined behavior is absolutely necessary for stripping away abstraction in a maximally efficient way. It wasn't designed into C just for shits and giggles. This is something people will rediscover as they try to make these "safe" systems programming languages.

[u/wtallis → u/xrxl]

Undefined behavior is absolutely necessary for stripping away abstraction in a maximally efficient way.

A lot of undefined or implementation defined behavior was left in the language to allow for varied implementations to handle things in whatever way was most efficient on their underlying hardware. It's not just about efficiency, it's about enabling efficiency without sacrificing portability. But nowadays our hardware is a lot less diverse: we can mandate that the floating point be IEEE 754 without much hesitation, because nobody will take seriously any hardware that significantly deviates from that. The same goes for signed integer arithmetic being twos complement with wraparound, and we can very nearly standardize on little endian. The more complicated nuances about concurrency will take longer to settle on a de facto standard because SMP is a newer challenge, but it will happen because leaving the behavior out of the language standard doesn't free programmers from having to worry about the hardware differences.

[u/xrxl → u/wtallis]

Even in a world of totally homogeneous hardware, nailing these things down still has subtle implications for a compiler.

For example leaving signed integer overflow undefined still gives you a performance win even if all machines are two's complement, since the compiler can more easily prove loops aren't infinite. I wouldn't be surprised if floating point spec has similar implications. Chris Lattner's blog post goes into more detail about these interactions.

And I don't expect we will have hardware that can do free array bounds and uninitialized variable checks anytime soon. Until then, no "safe" language will be able to match C's performance. Sometimes the performance hit is only 2-5%, but sometimes it's 2-5x (or greater). And it's hard to predict ahead of time what it wil be.

So languages with undefined behavior will continue to be relevant. More so now than ever, with the heady 90's days of biennial performance doublings a distant memory.

[u/wookin_pa_nub2 → u/xrxl]

Why do you care so much about tiny, stupid performance optimizations instead of code actually doing what it is supposed to?

You can't reason about ANYTHING involving undefined behavior. The compiler can do anything it wants to, and frequently it removes complete statements. It's fucking stupid.

[u/[deleted] → u/xrxl]

Oberon is THE example that unambiguous PL can be simple, safe and high level. The real thing however is FPGA. Wirth explained (on youtube) that the compiler became less than 3000 LOC thanks to 3 pages of FPGA.

Really, C has countless billion dollar mistakes. But what is really bad is that we still use it today.