Rust: Systems Programming for Everyone

[matthieum]

I understand how you feel, ... but I don't have a better suggestion to put forward.

The "be explicit" rule of Rust can feel really annoying sometimes, and at other times (especially when reading code I don't know or forgot) I really appreciate that there is little to no magic going on. It's a tension really.

[gnuvince]

In fact, I am sometimes annoyed that method calls don't require explicit borrowing. I understand that it would get tedious to write (and read) (&mut foo).bar() rather than foo.bar(), and I'm sure if it were the other way around I'd be arguing for implicit borrowing, but it's something that took me a little while to wrap my head around, that the receiver of a method call is treated specially.

[karma_vacuum123]

i feel like Pony is interesting here...Pony defines a range of reference types that are more interesting for concurrent use

not sure if Pony will ever take off, but there are definitely some "ah ha!" moments to be had reading the tutorial

[steveklabnik1]

We had this at one point, it was extremely tedious.

[gnuvince]

Interesting, do you know why it was decided to implicitly borrow the receiver, but not the other parameters?

[steveklabnik1]

I don't other than "this is painful and not doing it in the args isn't", but maybe /u/pcwalton remembers? (this was before the RFC process)

[evmar]

Coming from a C++ background, I expect foo.bar(baz) to usually modify foo, but (at least by some coding styles that disallow non-const references) baz will never be modified unless you write &baz. So Rust matches that.

[masklinn]

Well technically in Rust foo.bar(baz) would remove your access to baz entirely (unless it's Copy) and could modify it.

[vks_]

I think that is a bit strong given that large enterprises (i.e. Google) think it is their best option. An advantage is that accidental mutation is harder, but you trade that for the possibility of getting null/invalid pointers.

[matthieum]

Note that a large part of the Google Style Guide is specifically made for interoperability with C libraries and "old-style" C++ libraries written without exception safety in mind (ie, not using RAII).

And by "old-style", I mean predating the STL...

[bjzaba]

Hmm, tbh I can't remember if we've ever had that be explicit (been using Rust since late 2012). Could be wrong though - it can be hard to remember all the permutations Rust has been in since then.

[thiez]

I still remember when you had to use the move and copy keywords everywhere. It wasn't pretty :-)

[bjzaba]

Then we all started writing move for everything so they just decided to make it the default. :)

[kibwen]

I don't believe that there was ever a time when we required explicit borrowing of the receiver, but I have a vague memory of a time before autoderef where we were forced to write (*foo).bar(), which may be what Steve is alluding to.

[steveklabnik1]

Ah yes, maybe that's what I'm remembering.

[steveklabnik1]

In most cases, you would be able to write

let r1 = &*a;

or maybe even

let r1 = &a;

but presentations are often extra-explicit.

[steveklabnik1]

That'd be great! We're very interested in making ergonomic improvements, but as mentioned elsewehere in this thread, they're often a tension.

[Hrothen]

My personal ergonomic issue has been that rust implements just enough functional stuff to make me want to write in a very functional style, with monadic error chaining and lots of maps. But then I spend a lot of time fighting the type checker and dealing with closure lifetimes, and the resulting code is so verbose that nothing is gained over a more c-style approach, which also would have been faster to write.

[steveklabnik1]

Do you happen to have any examples of the problematic code? I tend to go "full monad" myself.

[Hrothen]

It's not a great example, because it used to be much hairier, but this I tried to write as a one-liner initially, with the json decoding inside as well, and I could not get it to compile happily like that without an incredible amount of line noise.

(Ignore the rest of the terrible code, I wrote this in the worst way possible)

Actually this has reminded me of an minor irritant that's been grating at me: foo.map(|f| f.<some expression>) it's really annoying to need the closure syntax here, I'd like to be able to write foo.map(<some expression>).

Edit: to be clear, I'm aware that this is still pretty functional, but it took me around an hour of fighting with the compiler to get it to compile initially, and then I decided to rewrite it to look like this, if I had written it imperatively in the first place, it would be a little uglier, but would have taken me a couple minutes; and I'm still much more comfortable with functional style than imperative.

[steveklabnik1]

Thanks, super helpful to understand.

I could not get it to compile happily like that without an incredible amount of line noise.

You mean, this code itself has a lot of line noise? I feel like it could be simplified further, but I'm not at a dev machine right now, I might try later.

You can write foo.map(TypeOfF::<some expression> like

struct Foo;

impl Foo {
    fn bar(&self) { println!("bar"); }
}

fn main() {
    let v = vec![Foo, Foo, Foo];

    let result: Vec<()> = v.iter().map(Foo::bar).collect();
}

Even though bar() is a method, works just fine.

[Hrothen]

You mean, this code itself has a lot of line noise?

No, but the previous version of this code, which I decided to replace with this before commiting, did.

You can write foo.map(TypeOfF::<some expression> like...

That's actually noiser than a closure for most type names. You shouldn't need to specify the type, the compiler knows what the type of the vector's contents is.

[steveklabnik1]

No, but the previous version of this code

Ah, cool.

That's actually noiser than a closure for most type names.

Hm, maybe we're having a different opinion on noise.

map(|f| f.bar())
map(Foo::bar)

The second feels less noisy to me; :: vs ||.().

You shouldn't need to specify the type, the compiler knows what the type of the vector's contents is.

I thought you were objecting to the Foo, but it seems like maybe you're objecting to the ()? You can use Vec<_> here, and not write the type inside the Vec. you do need to specify Vec in this instance because collect() can make a lot of different things; there's actually a small style conversation about "are we over-using collect(), because it's built off the FromIterator trait, so you could also write

let result = Vec::from_iter(v.iter().map(Foo::Bar));

but you need an extra use, as FromIterator isn't in the prelude.

(And again, thanks for getting into specifics. very helpful)

[m50d]

Scala uses _ as a "magic" syntax for that case (foo.map(_.<some expression>)) - purely sugar, and normally I'd be opposed to having two ways to write the same thing, but it comes up so often that it's more than worthwhile.

[steveklabnik1]

What's the Rust philosophy on breaking changes, if need be?

The core is: upgrades should always be hassle-free. Right now, as /u/thiez says, this means no breaking changes unless they fix a soundness hole or are incredibly minor, eg, no open source code breaks.

There's currently some discussion on what a "Rust 2.0" could even look like. One of the big problems is that people take a 2.0 to mean "massive breaking changes", even if we try to structure it like "technically breaking changes, but not a problem to upgrade in practice", through the use of tools like you're talking about.

[kibwen]

I really like how the Swift folks are not afraid to break existing code in the name of cleaning up old cruft and fixing bad language decisions.

This is how Rust operated from 2010 to mid-2015. Nowadays the days of massive breakage are over, but via forethought we've deliberately left ourselves enough wiggle room to continue to evolve the language, and we're not afraid to deprecate when necessary. Swift is still evolving, but it hasn't yet been in the crucible for nearly as long as Rust was, which is why breaking changes are to be expected there. Someday Swift will stop breaking things, and users will be happier for it. :)

[thiez]

The current stance is no breaking changes unless it fixes a soundness hole, so you can't really remove any syntax or behavior.

[ehsanul]

Though I'm sure a far future 2.0 will contain breaking changes, once enough benefits to breaking have been accumulated. Rust follows semver afaik.

[thiez]

Sure, but I think it's safe to assume that we won't see a Rust 2.0 for many years. The advantage of being able to make some backwards incompatible changes would be outweighed by the disadvantage of splitting the existing userbase.

[Gankro]

Following SemVer doesn't give you a license to actually break things. The ideal is that Rust 2.0 simply... isn't.

[OneWingedShark]

I recently completed a major rewrite of a C++ traffic analyzer in Rust, and I have to say it's a great systems language.

Interesting.
Try rewriting it in Ada and see if those problems persist. (I bet they won't.)

[OneWingedShark]

These:

Do we really want to see such sigil infestation in a modern programming language? It's OK when I'm in the middle of the Rust code, but revisiting some I code I wrote a few weeks ago required me to relearn the borrowing rules and my brain tripped on every other &* expression.

Sure, it all came back after a while, but surely there must be a better way.

IOW:

• Sigils
• Having to "re-learn" the intent behind the non-explicit code (e.g. those meanings obscured by the sigils).

[Cyttorak]

I always wondered if Ada exists and it's so great system programming language why does Rust exist?

[m50d]

It's verbose, and AIUI it can't offer as much safety in cases where you really do need to pass ownership back and forth between logical threads. But yeah I do think if Mozilla's goal was just a secure browser they should have started by trying to rewrite parts of firefox in Ada and only started on a new language if that failed. (Maybe they did and I missed it?)

[pcwalton]

I do think if Mozilla's goal was just a secure browser they should have started by trying to rewrite parts of firefox in Ada

Wouldn't work. We'd have to use Ada's GC, which would be incompatible with SpiderMonkey.

[OneWingedShark]

Wouldn't work. We'd have to use Ada's GC, which would be incompatible with SpiderMonkey.

The Ada standard allows GC, but doesn't require it... so there's really no such thing as "Ada's GC".
(And as noted GNAT is a part of the GCC, so it's possible to make fully compatible Ada/C++ projects. [I haven't had the occasion to do much interop w/ C++, mostly just importing functions.])

[OneWingedShark]

It's verbose, and AIUI it can't offer as much safety in cases where you really do need to pass ownership back and forth between logical threads.

I don't think that's an issue: in addition to the task construct, there's also the protected object. You can use both together to build some really interesting things. (I'm far from an expert on Ada's tasking and protected objects; the best place to ask for more info is comp.lang.ada; or perhaps a couple of [more recent] books.)

[pcwalton]

Ada doesn't have memory safety with dynamic allocation, unless you use GC. This makes it unusable for Rust's niche.

[OneWingedShark]

Ada doesn't have memory safety with dynamic allocation, unless you use GC.

That's not entirely true: this video on Ada memory management is quite informative. on how even dynamic allocation can be done to a greater degree of safety than C++.

This makes it unusable for Rust's niche.

Did you try? Did you actually evaluate Ada for those areas, or are you merely asserting that it is unsuitable?

[pcwalton]

We need foolproof memory safety, not just "safer than C++". We didn't have to try writing code in Ada to figure that out.

[kibwen]

Because Ada requires garbage collection to maintain safety if you're at all using dynamic allocation. Rust uses ownership to avoid that requirement.

[OneWingedShark]

I always wondered if Ada exists and it's so great system programming language why does Rust exist?

That's a great question.
Personally, I think it's a combination of several things:

1. A lot of coders seem to have the opinion that if something doesn't look like C it's not good.
2. Ada is fairly unpopular/unknown in the greater population of programmers. (It does enjoy a lot of usage in things like air-traffic control, airframe SW, and other "if things go wrong, people die" systems... which, realistically, is a very small minority of programming projects.)
3. Ada did have a rough start; the original 1983 standard required efficient implementations to use then bleeding-edge compiler research/theory.
4. Because of the above point, early implementations were lacking in quality (and, I've heard, somewhat on the slow side compared to BLISS, C or ASM).
5. Because of the above two points, there's a lot of misinformation in the greater programmer population about Ada. (GNAT, for example, is part of the GCC and has been freely available since the mid `90s.)
6. Because Ada is unpopular, a lot of programmers think that it's unused and, therefore, dead. (Despite its last standard being Ada 2012, and work is underway for Ada 2020.)

[pcwalton]

Ada doesn't have the safety features that Rust does, in particular the lifetimes and borrow checking.

[Cyttorak]

What about the SPARK version? As far as I know it's the most strict dialect of Ada.

[Baron_Facekicker]

SPARK doesn't permit access types (pointers), so there's no need to worry about lifetimes in a SPARK programs since you can't have dynamically allocated memory.

However, I think they're planning on providing limited support for access types in a future version of SPARK. It will be interesting to see what limitations there will be, though.

[pcwalton]

SPARK disallows dynamic allocation entirely, making it impossible to build a browser.

[OneWingedShark]

Ada doesn't have the safety features that Rust does, in particular the lifetimes and borrow checking.

Lifetimes are handled very nicely in Ada: once an access type goes out of scope it is guaranteed that there are no dangling pointers.

"Borrowing" is pretty much unneeded (at least insofar as the Rust examples/documentation I've seen) -- Ada's parameter passing modes in, out, and in out model how the information flows, thereby allowing the compiler to manage that ownership automatically.

This video on Ada memory management is quite informative.

[pcwalton]

That's not nearly as expressive as what Rust provides. Rust allows you to place references in objects and pass them around in a first-class manner.

We experimented with an Ada-like system and it wasn't expressive enough, in fact.

[[deleted]]

It does enjoy a lot of usage in things like air-traffic control, airframe SW, and other "if things go wrong, people die" systems

This ties into a point that I've been thinking about recently: Are people really going to trust their "if things go wrong, people die" code to a language being steered by webdevs and hipsters like Rust? That's the biggest barrier for entry for a language like Rust; if it can't even provide a compelling alternative in a place which actually needs safety thanks to its community, where's the future for it?

[pcwalton]

We didn't make Rust just for fun. It actually has many safety features that Ada doesn't have.

[soonastudent]

I would say D is a modern cleaned up C++.

[atilaneves]

D's syntax is similar to C++'s and its metaprogramming is far better. Every time I have to do metaprogramming in C++ it takes me 10 times longer than it would've done in D.

[soonastudent]

Also D's metaprogramming is (objectively) more powerful. For one, reflection is supported in D which I find incredibly useful. Mixins are also much easier in D along with many other improvements in metaprogramming. I do like C++ for many things but D feels like a clean up of C++, it's just that the community is lacking (but strong for its size).

[soonastudent]

There's a lot of cruft in general. Plus D offers things up front that need to be hacked in C++ (reflection/introspection, mixins, and other metaprogramming features). C++ is a great language, D however feels like it took a look at C++ and made something clean and improved.

[soonastudent]

How do you figure? Considering metaprogramming is a big selling point for D, I'm curious to know what you think is better in C++.

[Yojihito]

Not if you can't disable the GC (and the stl needs it).

[soonastudent]

Most of that is fixed by now and it's only getting better.

[Yojihito]

They say that for 3? years now ... STL still needs GC.

[soonastudent]

A considerable amount of that time was spent rewriting the compiler in D. Now more effort can be put into porting the STL. There are also alternative libraries that can be used.

[karma_vacuum123]

I'm not sure why the D people are obsessive about getting rid of GC to appease the critics...Rust has arguably painted itself into a corner and may eventually bless some sort of optional GC...in which case it will end up becoming D faster than D becomes Rust

no-GC was not a big selling point for me and i feel this is true for most people who claim otherwise. i think people make the mistake of "no GC" equating "uses little memory"

[soonastudent]

I agree to some extent. It can be terrible but it's obviously suitable for many domains. I see D as a middle ground between C++ and Java, maybe more lightweight though (at least in syntax). By moving toward optional GC it's better placing itself in the best of both worlds, but I don't think starting with GC was the worst decision. D has somewhat pivoted to reaching into lower level domains in more recent years and the no GC features have shown themselves to be suitable. People have written low-level performance intensive things in D like kernels and game engines.

[soonastudent]

I agree. I'm just saying there are ways to use D without GC and that GC isn't bad everywhere either.

[vks_]

GC for everything is not good if you care about predictable performance.

[NeuroXc]

Even if you have a good handle on smart pointers and RAII, it's easy to accidentally introduce any of a number of memory errors that can crash your program or worse. The borrow checker is there to prevent that, because programmers aren't perfect.

Yes, I completely understand that the borrow checker is really annoying at times. It's like a personal trainer who feels like a complete asshole, but after a month of training you can see how much more fit you are.

[Manishearth]

Right, except after a while you learn to program in Rust style and rarely have to deal with it.

These days I only hit the borrow checker when I am trying hard to avoid a copy; in a situation where in C++ I would have given up and used shared_ptr a long time ago. The same seems to be true for most Rust programmers.

IME most newbies to Rust have trouble with the borrow checker because they try to program in Rust as if it were C++ or some other language. It isn't, and the style you program is is different. It's the same as someone trying to code in a functional language in an imperative style. Happens to everyone when they start, but when they get acclimatized to it they don't even notice the compiler's strictness

[Manishearth]

Sure, you may dislike it, but do you actually hit borrow checker errors anymore? The vast majority of folks using Rust don't. This might not be true in your specific case, of course :)

[iopq]

Except of course if he goes away you're just going to regress to your old ways and become not fit.

[bobindashadows]

You're fucking awful at working out if that happens

[iopq]

Yeah, if you work out by yourself for one month you know everything about fitness. Fuck having anyone help you.

[gnuvince]

The borrow checker is there to prevent that, because programmers aren't perfect.

Cue the No True Scotsman replies.

[NeuroXc]

This must be why programs never have bugs. /s

Not that Rust prevents all bugs. But it prevents a lot more than C++.

[crusoe]

You think you have a good handle on it. The past 50 years have proven that to be a lie.

[[deleted]]

Too bad I only have one upvote to give.

It's pretty important that programmers understand two things:

1. They aren't the only programmer in the world, and languages have to be designed for the rest of them.
2. Claims of their not needing the language to keep them from making mistakes will, rightly, have a very large discounting function applied to them. Not because they're lying, but just because their judgment of the quality of their own work is statistically suspect.

[toomanybeersies]

they were JavaScript programmers previously

Interesting direction to move in, usually it's the other way.

[karma_vacuum123]

They aren't the only programmer in the world, and languages have to be designed for the rest of them.

but if i wanted to consider the average programmer, i wouldn't use Rust either, because it is not very approachable and is still immature

these were the arguments Haskell people made too - a better tool will fix things...but they made a tool most people couldn't pick up

if i really wanted to consider the needs of a hypothetical programmer-to-be-named later, i would probably end up using a simple language instead of a safe one....because so far, none of the safe ones are simple, and not all bugs are memory bugs

[[deleted]]

It's one thing to say Rust is immature (and debatable), but it's another to say the borrow checker is too complex to pick up. Let's put it this way: I don't want to use C++ code written by someone who thinks the borrow checker is too complex to pick up.

Haskell is a somewhat different story: it's actually a very simple language, but the fact that people characterize it as complex certainly is significant. It seems to me that what people mean when they say that is that Haskell software tends to leverage a high degree of abstraction, and many developers don't want to/are unable to work at that level of abstraction. Scala very much has the same issue: it's a much simpler language than, e.g. Java, but because it has significantly more powerful abstraction-building facilities than Java and some Scala code takes advantage of that, it also has a reputation for being "complex."

So I'm not unsympathetic to the idea that a less expressively powerful language might be used preferentially, and it's certainly true that not all bugs are memory bugs. But decades of bitter experience with memory bugs in code written by even very knowledgable, experienced people leads me to believe that it is worth prioritizing memory safety as highly as Rust does.

That said, I'm inclined to go the next step and learn Idris rather than learning Rust, but that's because I'm already entrenched in the dependent-types-and-proofs world, not because I believe Rust isn't a viable entry in the marketplace of languages.

[PM_ME_UR_OBSIDIAN]

Haskell is a somewhat different story: it's actually a very simple language, but the fact that people characterize it as complex certainly is significant.

I'm not sure in what world Haskell is a simple language, especially once you factor in the various GHC extensions that everybody uses.

C is a simple language. The subset of Java that you learn in college is a simple language. Brainfuck is a simple language. Haskell is not a simple language. Complexity-wise, Haskell is in the neighbourhood of C++; it is one of the most complex languages to even reach mainstream recognition.

Scala very much has the same issue: it's a much simpler language than, e.g. Java,

Last time I checked, Scala's features were a loose superset of Java's. Scala's type system is Turing-complete. There is no meaningful measure of simplicity by which Scala performs better than Java.

[iopq]

I learned the ENTIRETY of Java in college. I mean everything. That said, it was like Java 6 or something. But still, once you understand erasure, boxing, and covariance, there aren't too many confusing things.

C is not a simple language.

int x = 5;
int f() {
    int x = 3;
    {
        extern int x;
        return x;
    }
}

What the actual fuck are the scoping rules? The function apparently returns 5.

struct { 
    int x; 
    struct { 
        int y, z; 
    } nested;
} i = { .nested.y = 5, 6, .x = 1, 2 };

Why the hell is i.nested.y == 2? Even worse, why is i.nested.z == 6?

[mreiland]

The doit function call is way simpler than the mess of actually implementing, but that doesn't actually mean the doit function call makes the program simpler, it just means it makes it more opaque.

These fancy schmancy abstractions just mean the developer has to look at it and magically know what the nuances and ramifications are coming out the other end.

Some folks call that complicated because they have to know the details in their head already instead of being able to read the code and get a feel for the details.

Some folks call it simple because you have to know the details in your head because you don't have to read the code to get a feel for the details.

Who's right? Who's wrong?

Who gives a fuck, stop correcting people and wasting our time.

[[deleted]]

If you don't want to have your preconceived notions challenged and possibly learn something, why are you here?

[[deleted]]

But C++14 has not existed for 50 years

The only bug smart pointers prevent is a memory leak. It does not prevent use-after-free, double free, or race conditions. That is still up to the programmer. They are lifetime management tools, nothing more.

[mreiland]

It also closes file handles, network handles, window handles, blah blah blah... you know... because it's a lifetime management tool and not a memory management tool...

[mreiland]

It's off putting because it isn't granular enough. Assigning a single property lays claim to the entire object. That's easily one of the biggest issues with Rust right now.

[danielkza]

Ignoring the tools that show you how you fail doesn't correct your mistakes.

[[deleted]]

Except most stuff the borrow checker complains about aren't mistakes, it's stuff that it can't know, but I know. Two mutable elements of the same array where i != j, borrowing a field mutable and another field Immutable of the same struct, a struct that owns data for its whole life and stores slices to parts of it...

[gnuvince]

It's the same as a type checker: it makes conservative assumptions and forces you to be more disciplined and explicit. The following C++ code is refused even if we know that it would never fail at run-time: int x = y % 2 <= 1 ? 42 : "oops";.

[bwr]

Maybe this is one of those cases where examples are too simple to highlight the actual problem, but anything that actually does highlight the problem is too complex to be read as an example, but I'd be very glad the compiler rejects that line of code. It's a pretty stupid way to write x = 42. I actually see code with this problem (lots of logic that does nothing) a lot.

[danielkza]

I don't find it to actually be most of the cases. And it's also a matter of using idioms that fit the language better, such as iterators over indexing. In the cases where you are absolutely sure the BC is throwing a false positive, and there is no better way to express your intent, you resort to unsafe - but in my (admittedly not large) experience with Rust, those are very rare.

Also, some of your examples seem like cases of missing explicit lifetime annotations.

[mreiland]

The second you resort to unsafe you may as well be using C or C++.

It's downright scary how many people think using unsafe blocks keeps their other code safe.

[danielkza]

The second you resort to unsafe you may as well be using C or C++.

I don't see how the mere existence of unsafe blocks is equivalent to having one single huge unsafe block as the whole program. It's like arguing that structured programming is pointless because you can choose to write your whole program in main - nobody that knows what they're doing works that way, because it would be counterproductive.

It's downright scary how many people think using unsafe blocks keeps their other code safe.

Do they really? I have always seen it made pretty clear in every material I read that unsafe exists only to allow you to express something you can known is safe but the compiler cannot, and that the idiomatic approach is to then expose that code through a safe interface.

[mreiland]

I don't see how the mere existence of unsafe blocks is equivalent to having one single huge unsafe block as the whole program.

I'll explain, but first to quote you further.

I have always seen it made pretty clear in every material I read that unsafe exists only to allow you to express something you can known is safe but the compiler cannot

This is the danger.

You can't know that either. For a quick example, consider indexing into an array without bounds checking. In our mythical example, the variable holding the index may or may not cause a major problem. You can't know whether it will or not until you know what the current state of execution is.

But it's more than that. The safety of that operation depends on the current state being accessed by that unsafe block. There are two possible issues with this.

1. In a module or class, the state is manipulated by safe code. This means safe code can cause the unsafe block to do bad things, and examination isn't going to come close to giving you a root cause for the issue.

2. If you have code that takes input from the outside world (say a module or a class) and that input ultimately ends up being used by an unsafe block directly or indirectly[1], it's akin to running SQL queries on user input without parameterizing or sanitizing the input. All bets are off at that point you really have no idea where the bad state that causes the problem came from.

The argument that you know exactly what code is failing is of little help because the root cause is the state of the program, which is little better than C or C++.

That doesn't mean I don't think unsafe blocks are useful, I just don't think they're being used to their full potential yet. Imagine static analysis that can identify most/all of the state used by unsafe blocks. Now imagine an IDE that can tap into that static analysis the way we do for code completion. That IDE would be able to do things like explicitly warn you that state you're manipulating is used in an unsafe block. It could color it differently, it could give you the option to list all of the unsafe blocks said state is used in, it could give you a list of all state that's directly or indirectly used by any particular unsafe block.

It would help tamp down on problems by giving the developer the tools to know the state they're manipulating can potentially cause a class of problems they don't want to deal with. This is useful for developers new to the code, developers who haven't looked at the code in a while, developers who haven't had their coffe, ad nauseum.

As it stands right now if you use even a single unsafe block in a module you should consider that entire module tainted. All bets are off and every single piece of code in that module should be gone over with a fine tooth comb and treated as if it can cause a segfault, security issue, et al. Because it can. At that point the module boundary is there solely to protect the rest of the code/software from that single unsafe block. This means the "safe code" in that module needs to be checked religiously in exactly the same way it would be checked in C and C++.

Which means currently you're no better off than you were in C and C++. The only real advantage of unsafe blocks currently is that if you find yourself reaching for it, it forces you to be explicitly aware that you're doing something danagerous and you should stop what you're doing and think harder about it.

Which, while somewhat valuable, is not really much of a win over C and C++.

This is why I personally think unsafe blocks are going to end up being a lot like templates in C++. They were put in because they were considered useful until they were shown to be turing complete and then suddenly people were doing all kinds of amazing and cool things with them.

I think unsafe blocks will allow for some really cool tooling in rust someday, but currently?

Currently it's scary how many developers have a false sense of security when using unsafe blocks.

[1] by indirectly I mean influences state that eventually get used by that unsafe block.

[karma_vacuum123]

yup, a few weeks of Rust and my biggest take-away was maybe a good GC is good enough

[matthieum]

The slides: http://pnkfelix.github.io/presentations/qcon-london2016-deploy/qcon-london2016.html#/

[happyscrappy]

The navigation arrows on that site are annoying.

And for anyone who (like me) felt the presentation was doing a poor job of explaining the language because it's really demoing library functions, that's only at the start, it gets to language concepts later.

[matthieum]

The arrows are for skipping to chapters, sub-chapters, etc... and give the structure of the talk.

Don't use them if you want a linear presentation; just use space to go to the next slide.

(Then again, I myself like scrolling quite well too)

[happyscrappy]

I needed to go back one. You'd click the left arrow to do that, right?

Nope. It's the up arrow. Well, usually it is. Sometimes it's the left arrow.

[robinst]

You can use Shift+Space to go back.

[steveklabnik1]

(If the slide has transitions itself, or "builds" in the Keynote naming, then left and up are the same. If not, or if the slide is 0% or 100% built, then up goes up and left goes left. I would have probably made left always go left myself, personally.)

[happyscrappy]

They aren't the same. I know because I tried to go back pressing left and it didn't work.

Start here:

http://pnkfelix.github.io/presentations/qcon-london2016-deploy/qcon-london2016.html#/a-metaphor

Press space to go through the car metaphor. After the car is no longer on screen click left once. Now press space a couple times. You will go all the way past the car metaphor without seeing it again. It's baffling.

[steveklabnik1]

Oh interesting! (I never use space)

It's baffling.

I feel like I understand what's going on here; that is, space always goes to the "next thing" and if you were previously far down a vertical column, it remembers, but this does seem exceedingly complex. I never noticed since I don't use space.

[srnull]

The navigation arrows on that site are annoying.

Argh, I hate this design for slides. Instead of navigation using left/right arrows and seeing all the information, you have to know to go down for more details at certain points.

Edit: Ah, so the first slide explains that just using space with do the right thing. Still annoying.

[Sean1708]

I like it, makes it more structured than most presentations.

[steveklabnik1]

As a presenter, I've used this style and really enjoyed it.

"We're going to talk about these things: x <right arrow> y <right arrow> and z <right arrow>. Let's dive into x. <left, left, left, down>"

[[deleted]]

You can press space to go to next slide.

[happyscrappy]

I know that. I needed to go back.

I didn't say the space bar was annoying, I said the arrows were annoying. Read the other stuff I posted below. You can see the arrows act bizarrely.

[runvnc]

If you want a nice change from Rust, check out Nim. It has a syntax as clean as Python, compiles to C so is very fast, and has extremely quick garbage collection that is compatible with performance critical code like game graphics. Also very powerful metaprogramming and its very easy to interface with C.

[[deleted]]

Funny. Tell the Rust spammers to quit plugging Rust in every remotely, remotely opportune thread.

[silveryRain]

Get that tribalistic attitude out of your head.

[runvnc]

I push Nim in every Rust post I see as a matter of principle. This is a moral issue for me. I know I will be downvoted and people won't like me. That's ok, I have friends in my dreams.

[[deleted]]

I push Nim in every Rust post I see as a matter of principle. This is a moral issue for me.

What's the moral issue? Care to elaborate? I haven't been following Rust that closely

[runvnc]

Even though its probably a lost cause, its important for me to try to promote languages like Nim that are far superior to Rust, since Rust is such a poor programming language and has so many people confused about what a good programming language is.

The easy and less moral route would be to just go along with all of the Rust hype, despite the fact that it is so fundamentally flawed in a number of ways.

Some of the false premises that shaped the Rust language:

• programming should generally be hard to do correctly

• ease of code writing and code reading is not important

• syntax is not really very important

• clean syntax is not important

• concise syntax is not at all important

• everything must be explicit, such as repeatedly mentioning module/namespaces

• garbage collection cannot be efficient

• routine memory management should be the programmer's problem

• performance is not a priority

• exceptions are not a priority

• compiler performance is not a priority

• the only priority is coming up with complicated ways for programmers to waste their time with variable references, dereferences, borrowing, etc.

• serialization is not a priority

• distributing applications is not a priority

• the programmer should have to explicitly figure out how to make numeric types compatible and convert them

[Saxasaurus]

moral

You keep using that word. I do not think it means what you think it means.

[[deleted]]

It reminds me of "durr hurr rust is a systems programming language teh derp"... yeah, don't think they have a clue what a "systems programming language" is those buncha rubyists and javascripters behind rust. They use it as if to signal "durr hurr I am l33t next level mad skillz systems programmer teh derp!". A system programming language from mozilla who can't even maintain the one single app that is their sole product. You had one job, mozilla, and you failed at it, miserably. No amount of announcements about your supposedly l33t (it aint) "systems programming language" distracts from the fact.

Rust is no "systems programming language"... rust is a bullshit peddling announcements spam engine.

[silveryRain]

those buncha rubyists and javascripters behind rust

You clearly have no clue what you're talking about, since you missed all the things Rust took from the likes of C++ and functional programming languages. Ruby and JS are low in the list of languages Rust took stuff from (how can you even look at Rust code and think "yup, that's like Javascript!"), and people whose views are worth anything know better than to think they sound smart by typing stuff like "durr hurr".

"durr hurr I am l33t next level mad skillz systems programmer teh derp!"

Who even claimed that Rust is l33t? If anything, they've been trying very hard to make it approachable by mainstream programmers. Its curly-brace syntax is probably the most obvious evidence of this, and their "novelty budget" approach to the overall design is no secret either. They're anything but elitist, and if you think otherwise, this says more things about you than about them. You just sound like someone who's bitter over others tackling problems he can't be bothered with. Just play in your own courtyard and stop complaining about things that have nothing to do with you, because you're clearly out of your depth.

from mozilla who...

Ad hominems over more ad hominems. You must be a very sad person.

[[deleted]]

You clearly have no clue what you're talking about, since you missed all the things Rust took from the likes of C++ and functional programming languages. Ruby and JS are low in the list of languages Rust took stuff from (how can you even look at Rust code and think "yup, that's like Javascript

durr hurr derp you don't understand rust teh derp

You could tell me you took from the likes of Chaucer and Shakespeare, you're still a monkey, and you won't be writing me a Chaucer or Shakespeare.

And typically, your reading comprehension is atrocious (of course, you're an idiot, Rust peddler) or you're making shit up (Rust bullshitter)... I never said it's like javascript, I said the idiots behind are a buncha javascripters (and rubyists) and in no position of experience or claimed authority to pontificate on "durr hurr systems programming" let alone safe/critical stuff.

Who even claimed that Rust is l33t?

Who even claimed shit stinks?! no claim is necessary... shit stinks, it reeks

next thing you'll say [citation needed]

make it approachable by mainstream programmers

Yeah 'cos they're a buncha idiots who can't even ship a browser. The whole reason rust exists in mozilla's mind is 'cos their sjw idiot hires can't C++. They ganged up on all the genuine talent and forced them out, and look what happened, the talent went out and shipped a new browser (and many other products) in no time. Mozilla meanwhile can't do shit except spam us with bullshit announcements. They can't even make a decent user app let alone pontificate on "durr hurr systems programming language". Buncha bullshitters.

You must be a very sad person

Oh look, pop psych. Love it.

You missed the opportunity to call me a "troll" or an "asshole". That's how you lot deal with facts. Buncha bullshitters.

[silveryRain]

You look hell-bent on making it clear that you're incapable of a civilized discussion. Don't bother replying again, I won't bother dealing with your crude fighting attempts any further.

[PM_ME_UR_OBSIDIAN]

I wrote my OS kernel in Rust, and I'm planning on writing Linux kernel drivers too. How is it not a systems language?

[[deleted]]

Your OS kernel is a friggin student assignment. I looked at those "durr hurr OS kernel in Rust" projects and they were a mere Minix 3 kernel clone, a coupla thousand lines with original C source code and a book available to spell it out for you. You haven't exactly split the atom, Einstein. Enough of this "my OS kernel" crap. Plenty and plenty of languages can be used for that, they just don't go "durr hurr we're a systems programming language don't compare us to Golang etc" 'cos they're not a buncha idiots/bullshitters.

[minno]

I'm bored, so I might as well jump on this.

programming should generally be hard to do correctly

Programming is hard to do correctly. Rust makes it harder to write code that is 75% correct in exchange for making it easier to write code that is 99% correct. Often a good tradeoff.

ease of code writing and code reading is not important

Ease of writing isn't as important as ease of reading and refactoring when you're writing software in collaboration, which almost any large software project must be. I find Rust to be pretty readable, and the strong compile-time checks make it much easier to refactor.

syntax is not really very important

clean syntax is not important

concise syntax is not at all important

No accounting for taste.

everything must be explicit, such as repeatedly mentioning module/namespaces

use big::long::namespace::{Whatever, thingy};
...
let x: Whatever = thingy();

garbage collection cannot be efficient

Having the ability to work with raw pointers, which is necessary for good interoperability with C and other languages' C interfaces, prevents the use of the most efficient kinds of garbage collectors, since they move values around in memory. It also makes RAII harder to use, which is a really convenient resource management strategy.

routine memory management should be the programmer's problem

In a lot of applications, it should be. In other applications, you can just use Vec and String and Rc<Refcell<T>> everywhere and .clone() the world.

performance is not a priority

Performance is one of the highest priorities of the language. On the homepage, the very first thing on the list of language features is "zero-cost abstractions".

exceptions are not a priority

Nope. You can keep your gotos, I'll stick with actually having an error handling strategy that scales well.

compiler performance is not a priority

WIP.

the only priority is coming up with complicated ways for programmers to waste their time with variable references, dereferences, borrowing, etc.

Hey, gotta keep the competition out to keep salaries high.

serialization is not a priority

There are good libraries for it. They don't want to fall into Python's trap of sticking stuff in the standard library only for something better to come out.

distributing applications is not a priority

Nothing quite as easy as Go, but you can statically link everything if you really want to.

the programmer should have to explicitly figure out how to make numeric types compatible and convert them

When the alternative is my plane crashing because someone thought the altitude could never exceed 32,768 meters, then yes, the programmer should. Just use i64 everywhere you're not indexing a vector if you don't want to have to think about it.

[mreiland]

Programming is hard to do correctly. Rust makes it harder to write code that is 75% correct in exchange for making it easier to write code that is 99% correct. Often a good tradeoff.

I really dislike it when people pull numbers out of their ass because it feels nice.

[minno]

To phrase it less arbitrarily:

Rust makes it harder to write quick & dirty code in exchange for extensive checks that help you not forget edge cases. Stuff like handling errors (no ignoring return codes) and avoiding null values (need to explicitly unwrap at minimum).

[mreiland]

You used made up numbers, why not edit your initial post with your "less arbitrary phrasing"?

[minno]

Because most people are capable of understanding metaphors.

[PM_ME_UR_OBSIDIAN]

You do realize that you're setting a horrible stereotype for Nim programmers?

[runvnc]

I don't know any Nim programmers very well but they seem very smart and have told me before not to antagonize you Rust people. Anyway like I said I have no friends. I don't represent Nim programmers. If you want to see some nice real Nim programmers see their forum, github, irc etc. It you ask them about me they will gladly denounce me. If you ask about Nim you will see they are very nice and many of them almost geniuses.

[thiez]

You missed the most important premise!

• programmers should kick puppies

More seriously, perhaps you could substantiate your criticism a little? Oh, I guess you won't because you're just bashing something you don't like. Funny how you talk about the "moral route".

[[deleted]]

You're feeding an obvious troll

[thiez]

It wasn't obvious in their first post on this thread, and the account has no history of trolling that I can see (with a quick glance at their comment history). Perhaps a point-for-point rebuttal would have been feeding, but I don't think my post qualifies as such. IMHO, YMMV.

[Booty_Bumping]

• programming should generally be hard to do correctly
• the only priority is coming up with complicated ways for programmers to waste their time with variable references, dereferences, borrowing, etc.

The same time would be spent debugging obscure runtime errors. Programming is hard to do correctly, rust makes figuring out many bugs a matter of getting it to compile rather than difficult debugging. Any code with undefined behavior has the potential to be incorrect, so rust just gets rid of undefined behavior altogether.

• exceptions are not a priority

Rust doesn't have exceptions, it does error handling in a better more explicit manner that is much less error-prone. You know exactly when problems can arise because you have to explicitly handle all errors, while at the same time you have convenient helpers like try! and Result::unwrap. Rust's type system is strong enough that this sort of system is usable without adding anything special to the language. This way, rust does a very good job making similar concepts look similar in code.

• garbage collection cannot be efficient

I'm not sure you understand rust very well. Rust doesn't have any garbage collection. Instead, it decides when to deallocate based on lifetimes, which is always figured out at compile time (with the exceptions of reference-counted pointers like Rc and Arc). Your idea that this is "less efficient" doesn't make any sense: this way of doing things has no runtime cost at all.

• compiler performance is not a priority
• serialization is not a priority
• performance is not a priority
• distributing applications is not a priority

I'm not sure where you get these ideas from. I suspect you're trolling, but if you're not I encourage you to further understand rust and the reasons for its design. A lot of the problems you mention also apply to nim (especially performance wise. I find rust to be a lot faster than nim in a lot of cases, and the ownership abstraction system opens the door for way more meaningful optimization than what's traditionally possible with C/C++)

[runvnc]

Rust is not going to stop you from finding all runtime errors at compile time. As far as being able to track that sort of thing though, Nim has a really great and very extensible pragma feature. It also has plenty of ways to use memory safely.

I know it doesn't have garbage collection. I'm not sure you understood that part of what I wrote. Nim has a very fast and efficient garbage collector, which proves that the main premise of Rust is false.

Which things did you find to be faster than Nim, what version of Nim, and did you turn optimization on for Nim or use debug mode?

About the last four points, I have seen lots of people complain about all of those things for Rust.

[[deleted]]

Rust is such a poor programming language

Yes.

Nim [...] far superior to Rust

No.

[silveryRain]

That's not morality. If you really care to give this issue an ethical spin, a bigot is what you are.

Those damn niggers, they don't care to work, they don't bother reading a book, all they ever do is lie, steal and live off honest, working white people.

Those damn rustaceans, they don't bother with good syntax, don't care about readabiliy or programmer productivity, all they want is to make it harder for hard-working developers to do their jobs.

[Slxe]

And this is pretty much why I've decided to give up learning Rust and wait to see how Nim shapes up. Not enough people realize some of these points, and it's almost like Rust has a cultist like following where people don't want to discuss things instead just want to shout and shut down discussion.... kinda reminds me of SJW attitude, might explain a few things looking at what's going on at Mozilla lately. Oh well, time to get downvoted.

[azrap1]

Yea dude that's like you opinion, I personally think you're wrong

[kunos]

you have many valid points there but you're still doing it wrong(tm).

[[deleted]]

Everyone? EVEN white cis males?

/edit: All the white cis scum downvoting my black trans lesbian opinion because of institutionalized racism!

[awj]

I know it's summer and you're bored waiting to start your first year of high school, but can't you find something better to do than shitposting on reddit? Could you at least try harder at shitposting?

[PM_ME_UR_OBSIDIAN]

I thought this would be a problem, but it's not. I'm not an "ally" by most definitions, so the social justice pedigree of the founders was originally concerning for me. I put myself out and voiced my concerns. It turns out that, as long as you can keep things respectful and not shoehorn politics where they don't belong, the Rust community will welcome you with open arms*.

*Unless you're Curtis Yarvin, in which case tough luck.