TMI: Open Source Bridge talk: given!

[tim]

Here are the slides for my talk, "Rust: a Friendly Introduction". I'd love to clarify anything that needs it in comments on this post.

Comments

[corvi]

How'd it go?

[tim]

Pretty well. Attendance was actually fewer people than my practice talk, but then again, it was scheduled against some other great-sounding talks! Some amount of questions, almost all really good ones that showed people were listening. Reddit found my slides but is mostly pretty subdued about them :-)

[juli]

Great talk, and I found it really interesting and enjoyable to read! I generally wonder about the omission of modern compilers from talking about C's features. Yes, as a language the typing is all crap, but in practice implementations can be more aggressive about type checking, etc. And C++ in particular is not as content with treating enums as just plain integers — using enums as integers in C or C++ can lead to very awful pain and should usually be avoided, IM!HO.

For instance:

enum Foo { Cock, Dong };
int f(Foo x) {
	switch (x) {
	case 30:
		return -1;
	}
	return 40;
}

Which, with the default Clang setup on Mac OS X, no additional warning flags, yields:

x.cc:4:7: warning: case value not in enumerated type 'Foo' [-Wswitch]
        case 30:
             ^
x.cc:3:10: warning: enumeration values 'Cock' and 'Dong' not handled in switch [-Wswitch]
        switch (x) {
                ^
2 warnings generated.

So, yes, the language isn't offering guarantees there as such, and some of them are there if you want them (and I can't imagine not turning on the vast majority of warnings and treating them as errors.)

[tim]

Yeah, admittedly I could have made a stronger case about what guarantees Rust's semantics really does give you that C++'s semantics don't. Arguably "you can turn warnings into errors" is not ideal, though, since if you're using libraries that you don't have control over, you don't know whether the authors used all the warning flags :-)

[etb]

p. 6: It's easy (at least, used to be) to see the connection between Java source and JVM bytecode. But you were probably talking about machine code.

pp. 8, 45: If you have the whole program and monomorphize, like MLton does, you don't have to box everything.

[tim]

Fair points. I added something about whole-program analysis to the slide notes so that people aren't misled. I still think the basic point still stands (in practice, people want separate compilation).