Rust and the Future of Systems Programming [video]

https://hacks.mozilla.org/2016/11/rust-and-the-future-of-systems-programming/

by philbo • 10 years ago

475 478 10 years ago

hacks.mozilla.org

z3t49• 10 years ago

when you can run javascript on a pebble watch it blurs the boundaries ... Want to concat an number and string ? JavaScript wont complain.

wyager4• 10 years ago

Want to concat an number and string ? JavaScript wont complain.

Is that supposed to be an endorsement?

z3t49• 10 years ago

  foo = (string, number) => string + number

Now go write that in your preferred language!

0xAA552• 10 years ago

Want to make a fast application on a pebble and with actual type checking? C and Ada won't complain or blur your lines... http://blog.adacore.com/make-with-ada-formal-proof-on-my-wri...

steveklabnik30• 10 years ago

You can do it in Rust too; though most of the demos I see on GitHub are just demos.

z3t49• 10 years ago

And real programmers write in machine code. Want to get shit done ? Most systems now a day has more then 20kb RAM! Where do you draw the line between systems programming and non system programming ? And why not write some quick and dirty code in say JavaScript and then do what needs optimization in C/assembly ? Assuming you are not restricted to a CPU that cost less then a dollar. And where does Rust come in ?

bsder4• 10 years ago

when you can run javascript on a pebble watch it blurs the boundaries

And yet Javascript can't access a network socket or my flash storage in any useful portable way.

Javascript is hampered by everybody trying to bolt on "security" after the fact and basically hobbling usage of the language.

z3t49• 10 years ago

You also need a hardware abstraction layer with Rust, so why not use a higher level language like JavaScript or Haskell, besides optimizations and personal preference !?

wyldfire11• 10 years ago

GC pause ... sufficiently low power hw .. cheap phone

Yeah, but even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive.

IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust.

EDIT: I mean to say that many of my colleagues who write realtime software dismiss new languages as including GC baggage by default (because so many do!). So, hey, good that the video calls this out.

vvanders2• 10 years ago

It's starting to go that way but that's a very hard space to push new things into. I talk with all my ex-gamedev contacts and they're hesitant to even use lambda or other C++11 features that have been around for a while now.

I think Mozilla's plan of driving things forward with Servo and using that as an large-scale example of the gains that can be made is a good approach.

pron7• 10 years ago

even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive.

That's true, but high-powered, abundant-RAM realtime applications can use approaches that are cheaper than Rust's. See, e.g., the interesting work currently being done updating realtime Java[1]. The idea is that memory is composed of a few kinds of lifetimes: eternal, scoped and GCed-heap. Scoped memory is basically nested arenas, and GCed heap contains objects that are used by non-realtime portions of the app (which, even in realtime systems, may comprise the majority of code, especially when the system runs on large servers).

An approach like Rust's, however, is crucial when the application is RAM and/or energy constrained.

[1] https://www.aicas.com/cms/en/rtsj

hinkley4• 10 years ago

If I had infinite free time, I'd love to explore the problem space of implementing interpreters for GC-based languages on top of Rust. It's quite hard to get the concurrency right, and indeed we see a number of major languages that gave up on even trying.

shandor2• 10 years ago

IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust.

It would, and definitely should, move into the direction of safer languages than C.

The biggest problem I see is tooling and legacy. Tooling, because there's a ginormous amount of testing and design software that "works with C" (whatever that means in the context of the tool). Legacy, because everyone already has their 20 year old codebases and it's just not convenient to start focusing on two languages and switching the old code to Rust is just plain impossible economically.

Third problem is compiler. LLVM (rustc is a frontend to it, no?) is really good choice, but gcc has enormous advantage in supporting so many small platforms and it's very significant in this area of SW dev.

On the plus side, I've really gotten the impression that the Rust folks are truly trying to make adoption as smooth as possible. If that works, and Rust proves to be much better than C for these kinds of systems, I'd guess adopting Rust rather than not would start looking economically viable to companies. I mean, in the end that's what matters to them the most, and it's not easy to replace all you C ninjas with competent Rust writer.

qwertyuiop92412• 10 years ago

I wouldn't hold your breath for C to die though. C sucks at many things, but it's pretty good in embedded, if you're not writing ASM.

duneroadrunner14• 10 years ago

If you're considering switching to Rust for code/memory safety reasons, SaferCPlusPlus[1] may be an easier/cheaper/low risk option. It allows you to add memory safety to your existing code base in a completely incremental way, with no dependency risk. (At the moment, standard library support is required though.)

[1] https://github.com/duneroadrunner/SaferCPlusPlus

kibwen12• 10 years ago

Rather than a ground-up rewrite, I expect people will begin using Rust in the same way that Firefox has: identify individual components that would most benefit from Rust, segment those components off behind well-defined C interfaces, then write a compatible Rust lib using Rust's ability to expose C interfaces.

erikpukinskis• 10 years ago

because everyone already has their 20 year old [C] codebases

It's comments like these that remind me how exclusionary the software world is. Your definition of "everybody" is such a tiny number of people. But that's who you have in mind when you are constructing the world around you each day.

naasking16• 10 years ago

IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust.

Rust cannot make any latency guarantees either. Reference counting and its lifetimes also have pathological cases, ie. worst-case, an object can reference the entire heap which will take time proportional to the number of dead objects to free.

Copying collection in this case takes literally zero time, but it's pathological case is when all referenced data survives the current GC cycle, ie. proportional to live objects.

There's no free lunch!

Rusky2• 10 years ago

Lifetimes are compile-time only and do not do any reference counting. So Rust has the same latency guarantees as C, for example.

qwertyuiop92412• 10 years ago

Rust itself can't, but you as the programmer can.

It's not quite C, but you can do a lot of reasoning about what the compiler will do with your code, and avoid pathological cases.

Manishearth19• 10 years ago

Rust cannot make any latency guarantees either. Reference counting and its lifetimes also have pathological cases, ie. worst-case, an object can reference the entire heap which will take time proportional to the number of dead objects to free.

Rust doesn't use reference counting by default. Refcounting is very rare in Rust, much more rare than it is in C++. Most large C++ codebases I've worked with have thrown in the towel and started refcounting all the things. In Servo, for example most of the refcounting is across threads (where you basically have no other option), and a few interesting cases in the DOM, each with very good reasons for using refcounting.

Lifetimes are a concept at compile time and don't exist at runtime.

Edit: Oh, I see what you're talking about. A sufficiently large owned tree/graph in Rust will introduce latency. It's predictable latency though. I can make the same argument about for loops.

Unpredictably sized large trees in Rust are again pretty rare in general.

dikaiosune2• 10 years ago

It's worth mentioning that there are several strategies for avoiding cascading deallocations like arenas or arena-backed graph abstractions. For example:

https://crates.io/crates/typed-arena https://crates.io/crates/petgraph

Rust's generics make this fairly pleasant to work with, and lifetimes/borrowck ensure safety when managing your own object allocations.

akiselev3• 10 years ago

You will always have these pathological cases when you choose to use higher level memory management like simple reference counting or garbage collection no matter what language you use, whether it's Rust or assembler. The point of Rust is that you have complete control over what you use and pay for. If your concern is the overhead of lifetimes then you need to evaluate if you can afford heap allocation in the first place. Otherwise you can make de/allocation explicit in Rust just like in C, without losing the benefits of ownership checking.

Embedded hardware and software can only provide realtime guarantees because they are simpler, without complex pipelines, caches, branch predictors, or thread schedulers. If you want low latency embedded software you have to document the pathological cases, test whether they happen in real world use, and profile the code with each microarchitecture you're targetting anyway, let alone every product family. What language you use doesnt change that.

pcwalton13• 10 years ago

I keep seeing this latency claim about GC, but it would be trivial to solve with free if it were actually a problem: just add freed objects to a list and incrementally free over time to achieve whatever latency guarantees you wish.

The reason why no malloc/free implementations that I'm aware of actually do this is that the latency of freeing isn't a problem in practice.

solidsnack90003• 10 years ago

The latency of your Rust or C program is "static" in that you can infer it from the program text. This is not actually true of most garbage collected languages. (Erlang, with per thread heaps, is a notable exception.)

enqk5• 10 years ago

Although I am not against improving the safety of languages we use for system programming, the model that Rust advocates are pushing of "preventing mistakes" as a way to make systems secure doesn't convince me.

Mistakes (and security breaches) happen. A system should be written in such a way as mistakes are few, indeed, however it is essential to also efficiently protect our users' assets (data) first, assuming that mistakes are being made.

Ideally as a user I should not care much, nor can I trust that all software is "mistake free." I need the assurance and the tools to guarantee that 1) mistakes are detected 2) my data/privacy/identity is protected.

gcp9• 10 years ago

Nothing prevents you from doing both approaches. I mean, while Mozilla is increasing Rust usage, they're also rolling out more extensive sandboxing.

Either of those by themselves are not a good enough solution though. Just trusting on Rust means you are vulnerable to Rust bugs or logic errors. Just trusting on sandboxing means you're hoping that your trusted code (written in C/C++) doesn't have any security bugs.

sidlls3• 10 years ago

It also means trusting that the "unsafe" usage in the Rust code doesn't have any security bugs.

qwertyuiop92412• 10 years ago

#2 is up to the engineers making the product. #1 is why Rust exists: it eliminates whole classes of errors. No, it won't stop you from screwing up badly, but it just might stop the buffer overflow or race condition that would have helped a hacker steal your users' identities.

glandium• 10 years ago

The fact that #1 is (partially) handled by the language also allows engineers to spend more time on #2.

Jweb_Guru• 10 years ago

Every systematic approach I've seen to enforcing privacy, nondisclosure, etc. and has to deal with dynamic security rules ends up having to include knowledge of information flow (via things like program counters, aka lifetimes, and in some cases explicit ownership tracking) into the language. Rust isn't enough but I think something like it will be necessary to take that next step.

pcwalton13• 10 years ago

Defending against remote code execution turns out to be an excellent way to help protect your data.

kibwen12• 10 years ago

  > assuming that mistakes are being made

Mozilla isn't using Rust as an excuse to skimp on security elsewhere. For example, Servo sandboxes tabs as you'd expect from a modern browser, despite being written in Rust from day one. Defense-in-depth is fundamental to good security, and being able to rely on the safety properties of your language adds yet another layer of defense.

SkyMarshal• 10 years ago

The name of the game for the software industry is to continually create better tools that systematically, inexorably reduce the attack surface of apps built with them.

Haskell does this in an interesting way by quarantining all side-effect code into Monads and preventing data races with immutability. Rust does it by making memory errors and race conditions impossible via its ownership mechanism.

Think of it as guiderails that reduce the cognitive load on the programmer by ensuring some classes of mistakes/errors/bugs simply cannot get past the compiler. Compared to C/C++, the programmer has less to think about since the compiler handles that for them. That is immensely valuable.

enqk5• 10 years ago

Nevertheless these language specific solutions are completely opaque to an end user. These are software developer centric. As an end user I cannot inspect how these were applied and therefore develop trust in the end product.

There's always an element of trust at the root of running a piece of software on my machine. I wish I could quickly inspect and be sure that say, the audio engine that mozilla firefox is running runs completly in a segregated zone/container/sandbox that will prevent, even in the presence of defects, its exploitation to leak data that is important to me.

I guess it's just a question of words and goals being a little bit too overlapping. Rust's approach is to address safety as in the rates of defects. However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets.

As an end-user I care much more about security than I care about defects.

erikbye3• 10 years ago

Reading your comment made me think of Erlang, where the guiding principle is the opposite: large systems will contain errors, and will fail. That is what fault-tolerant is, you design your software (language, libraries and end program) in a way that will handle unforeseen errors and failures. Because in large systems there will always be bugs.

http://erlang.org/download/armstrong_thesis_2003.pdf

enqk5• 10 years ago

That does sound rather interesting! (And anti-fragile, to use a talebian neologism)

staticassertion8• 10 years ago

I'm also a fan of this approach, and am currently learning Erlang because of it. However, I do not feel that the approaches are exclusive.

Erlang is dynamically typed and it is robust because Actors act as isolation boundaries and are managed by supervisors. So the approach is "bugs happen, always recover". You can also use type annotations in Erlang to get "bugs happen less, always recover".

AsyncAwait5• 10 years ago

I don't get what you're saying here.

- Without Rust you program to protect users assets without guaranteed memory safety.

- With Rust you program to protect users assets, with the addition of guaranteed memory safety.

Sounds like a win win to me.

enqk5• 10 years ago

Indeed it is a good thing. What I'm just a little bit weary of is equating that sort of improvement with increasing overall security. We went there already with Java and this hasn't stopped Java from being an attack vector.

The way this sort of reasoning affects the behavior of engineers and the products they put out in front of users.

Retra6• 10 years ago

It should be pretty obvious that security is not solely the responsibility of your compiler. I mean, if your OS is compromised, in can inject code into whatever you're running, whether it be rust code or not. Anyone trying to make iron-clad systems needs to understand the whole system.

But if you're not trying to do that, it's nice that you don't have needless and easy-to-avoid weaknesses like those your compiler could prevent.

leshow5• 10 years ago

Rust is great. I've been following it since pre-1.0 and writing code with it for about as long also. It's really come a long way, my favorite language for pretty much anything except web development.

Narann• 10 years ago

Wow! You've got my attention!

I mean, I feel many rust stuff (crates/dev/tools) seems to focus on high performance web so, as a low level guy enjoying bitwise ops and dynarec stuff I was wondering if rust what a good thing for me or if it would be better to stick in C. Can you tell me which kind of project you do in rust, what was your original language and why rust shine compared to your previous language?

xpe• 10 years ago

(different person here, but I wanted to reply) I'm not sure that I agree as strongly as the first post on this branch, but I really do enjoy Rust. I'm using it for a particular tree-search with pruning computation that caches to RAM and saves to disk. The speed, memory compactness, and correctness are very beneficial. I will admit that getting comfortable with the borrow checker has taken some time, and I still have more to learn!

leshow5• 10 years ago

I started on Java in school for software eng. After that I did a lot of front and backend development in dynamic languages and forgot all about types.

Until I discovered Haskell and saw what a really powerful type system can do. Rust's type system is very very similar to haskell's if you substitute the word 'trait' for 'typeclass'. However code is imperative, so that's nice for some applications, and is faster/lower level.

I've used the crate nom (https://github.com/Geal/nom) in the past, it's a parserc library for consuming bits/bytes. I used it to write a function that consumes a vector of unsigned bytes, 11 bits at a time. If you're interested in that sort of stuff, take a look for yourself and see if you like it.

As with most things in Rust nom generates parsers with little to no runtime overhead, so you pay nothing for the increase ergonomics.

shmerl5• 10 years ago

Does Emscripten support Rust already?

gcp9• 10 years ago

AFAIK yes but not in a "production ready" way.

steveklabnik30• 10 years ago

https://users.rust-lang.org/t/compiling-to-the-web-with-rust...

shmerl5• 10 years ago

Thanks, I should experiment with that.

wyldfire11• 10 years ago

Yes. See [1] for details.

[1] https://users.rust-lang.org/t/compiling-to-the-web-with-rust...

etherealG• 10 years ago

Thanks so much, I was digging into this a few weeks ago eagerly and didn't find anything. Glad it's here now!

Animats6• 10 years ago

Unfortunately, this is just a promotion for a series of videos. Probably talking head videos with PowerPoints.

Most people who do systems programming probably already know about Rust. They may not have used it, but know it exists.

What's "Hacks"?

kibwen12• 10 years ago

https://hacks.mozilla.org/ ("Hacks" for short) is Mozilla's blog for technical content focused at developers, as opposed to their outlets aimed at normal Firefox users or general web advocates.

steveklabnik30• 10 years ago

  > Probably talking head videos with PowerPoints.

Almost everyone in this video is an engineer on Rust, Servo, or Firefox. The exception is Dave Herman, head of Mozilla Research.

These are unscripted responses to questions, no powerpoint involved.

  > They may not have used it, but know it exists.

There are a lot of programmers in the world, and many of them don't read Hacker News. I meet new people who have never heard of Rust every week almost. Or may have heard of it, but can't tell you what it's for, just vaguely remember hearing the name. Or have heard of it, but remember their first impression from a pre-1.0 version and haven't listened since. ("How's its GC?")

kibwen12• 10 years ago

  > but remember their first impression from a pre-1.0 version

Can confirm, I routinely observe people in the wild dismissing Rust based on the existence of the `@` and `~` sigils, not realizing that we removed those years ago. :P

pimeys• 10 years ago

Now I have four services running on production, all written with Rust. If it compiles, it usually works. Of course you have these late night sessions where you write that one unwrap() because, hey, this will never return an error, right? And bam...

I'm seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugly callback code. Also the native tls support is coming and the dependency hell with openssl would be gone forever.

If you need http server/client, I'd wait for a moment for Hyper to get their tokio branch stable and maybe having support for http2 by migrating the Solicit library.

kibwen12• 10 years ago

Speaking of HTTP clients, just yesterday the person behind Hyper announced their new high-level HTTP client crate: http://seanmonstar.com/post/153221119046/introducing-reqwest

Animats6• 10 years ago

Not sure what to think of that. Does everything have to be async I/O now? How often do you need massive numbers of client connections?

tmzt3• 10 years ago

Would it make sense to have a cargo/rustc flag to disable unwrap and friends when building for production?

steveklabnik30• 10 years ago

unwrap has legitimate use-cases, and it's not clear what "disable" it would be, as it changes the type of the thing it returns. You could write a lint to fail the build, if you want, I guess...

conradev• 10 years ago

If by "and friends" you mean "calls that can panic", there are a few of those. Slice bounds checks, for one.

wyldfire11• 10 years ago

"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?"

Unwrap implies "either this operation should succeed or we should panic". Doing anything other than panic seems like it's terribly difficult to determine what that should be. And I might've put unwrap() there because that's really what I want to happen. For `mv`: don't let's dare go ahead and do the unlink() if the link() failed!

Tangent: errors and exceptions aren't bad, they're how computers work. I've encountered folks who, when faced with runtime errors pepper their code with "if (!NULL)" or truly evil things like "except:pass"/"catch (...) { }" which rarely make sense anywhere but the base of the stack and even then don't usually. If you've ever asked yourself "but how did we even get here‽" it may be because someone dropped something totally incongruous like that in a related module.

burntsushi13• 10 years ago

To put this into perspective, this would also necessarily disable expressions of the form `xs[i]` where `xs` is a slice. Why? Because `xs[i]` is equivalent to `*xs.get(i).unwrap()`.

In other words, banning unwrap isn't really that productive because an unwrap, when properly used, is an expression of a runtime invariant.

The problem is that unwrap can be very easily misused as an error handling strategy in a library, and in that case, it's pretty much always wrong. But that doesn't mean using unwrap in a library is wrong all on its own, for example.

dep_b4• 10 years ago

Isn't if let similar to Swift's if let where it either unwraps safely or does something else? I really wish I could disable forced unwrapping as it mostly leads to mistakes by less experienced or overconfident programmers and the amount of extra code by using guard instead if you program smart is negligible.

AsyncAwait5• 10 years ago

Rust's if let is indeed inspired by that of Swift and behaves practically the same way.

amelius• 10 years ago

I'm seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugly callback code

By which [1] is meant, for those not knowing.

[1] https://github.com/tokio-rs/tokio

shmerl5• 10 years ago

Wasn't there some other effort in Rust to enable asynchronous I/O?

cryptrash• 10 years ago

I'll never use rust for anything important. Too dangerous, unstable, badly organized, toxic development community, the list goes on.

shmerl5• 10 years ago

Huh? Did you mix it up with something else? Rust community is one of the best. And what's "dangerous and unstable" there?

noir_lord• 10 years ago

Check his comment history and draw your own conclusions ;).

TazeTSchnitzel• 10 years ago

Toxic?

allengeorge2• 10 years ago

Of all the invectives to level at Rust, "toxic development community" would be the least applicable. Frankly, I've found the Rust community super welcoming and willing to answer questions from a newbie.

As for the rest of your points - I don't think they're applicable as well. I've found Rust to be super solid and the ecosystem a pleasure to work with. Could you give examples to support your claim?

chamakits• 10 years ago

A lot of your attacks seemed to be aimed at personal beliefs of some of the rust developers. I follow some on twitter and they may have some views people disagree with, but nothing exceedingly controversial.

Furthermore, all other criticisms you've mentioned specifically towards rust and the community of rust are literal opposites of everything I've experienced.

The community is friendly and helpful. Rust is extremely stable, both as code, and as far as the developers making sure to not break backwards compatibility, going as far as testing EVERY PROJECT available in crates.io for regressions. They are also extremely organized, having all discussions in well thought out and documented RFCs,and allowing all to give input on it all.

I don't know what problems you have with Rust. I'm sure there valid things to critize. But everything you mentioned is categorically false. If you disagree, I'd be open to see proof of it all.

colemickens3• 10 years ago

I've had nothing but amazing experiences in the Rust community, and was actually proud/embarrassed the one time that I was chastised for being rude in /r/rust.

The Rust community reminds me of how welcoming the Go community used to be... (I love Go and write it every day, this isn't some sort of commentary about Go).

VoidAgent• 10 years ago

IMO C++ is unstoppable now, c++ 11, 14 and 17 additions with GSL and all things in the pipeline ...

kibwen12• 10 years ago

Rust doesn't need to stop C++ to be successful. The market for programmers is already large enough to successfully support dozens of programming languages, and that market will only continue to grow. PHP didn't "stop" Perl, Python didn't "stop" PHP, Ruby didn't "stop" Python, and yet all of these languages continue to be enormously successful. Why should we expect a monoculture on the systems side?

user59944614• 10 years ago

What's the place for Rust in the market?

The distributed systems have already moved to Go (when it's not Java/C# :D).

The system programming is done in either C or C++. (Depending on history and availability).

The oldest stuff and/or most constrained is stuck with C. They're struggling to have anything moved over to C++. Rust is entirely out of question.

qznc• 10 years ago

I'd say Python did stop Ruby roughly 2006. ;)

https://www.google.com/trends/explore?date=all&q=python%20pr...

unethical_ban• 10 years ago

Python in my mind has supplanted perl, and ruby seems only to live on for the sake of Rails.

gcp9• 10 years ago

A project like Servo means that the proof will be in the pudding.

Gecko and WebKit/Blink are C++ (though stuck at C++11 due to compiler and platform compatibility). So we'll see how they end up comparing.

thewhitetulip2• 10 years ago

I really wish that they replace Firefox with a browser written using Servo. That'll be fun.

scythe• 10 years ago

Rust will have a niche regardless of the momentum of C++ as long as it's easier to learn to use than C++ for someone who's new to solving these kinds of problems. The question is whether that goal is in sight.

baq3• 10 years ago

rust does things C++ simply cannot and will never do. that doesn't mean rust is strictly better. actually i believe C++ and rust should be best friends; there's only this small ABI issue - i hear smart people are working on it, though.

wyldfire11• 10 years ago

I love C++, for decades it was one of the only games in town. But IMO there's a huge pipeline stall in C++17.

Features postponed beyond C++17 related to or bound to C's legacy are already in Rust (modules, e.g).

qwertyuiop92412• 10 years ago

I disagree. There are a lot of us who want a higher level systems language, but don't think that C++'s kitchen sink approach is a good design. Those people are flocking to Rust already, and more people are coming because it's interesting or cool.

Rust doesn't have to beat C++. If Rust steals 1/10th of C++'s marketshare, it will have a viable ecosystem.

colemickens3• 10 years ago

Except that even if you write perfect code and have a compiler that supports all of the features... you code still won't be as safe as it is if rustc signs off on it.

This conversation happens in literally every single thread about Rust. Every single time someone implies that new features in 14/17 will somehow make Rust irrelevant, but it's simply not true. There are classes of problems which Rust can catch which a C++ compiler cannot. And I don't really care about "if all devs wrote perfect code" because we get a new CVE every 3 weeks from some C/C++ codebase that has brilliant people working on them.

djhworld• 10 years ago

I keep trying to learn rust but fail miserably.

They do say on their website that there's a hump that you have to climb over before everything fits into place, which is probably applicable to everything you'll learn, but sometimes I think that hump is too much of a hurdle

steveklabnik30• 10 years ago

How are you trying? What are you getting stuck on? I'd love to improve things.

q3r3qr3q• 10 years ago

I'd get excited and go through some tutorial on their website, probably the main? tutorial, bu then when you get to the lifetimes section is seemed to get really complicated instantly. I tried twice and think I hit the same problem. Maybe some more good examples would help?

cbHXBY1D• 10 years ago

Not specifically about your book, but I would love if there was a quicker way to find methods in the docs.

Right now, if I want to find the methods used by BTreeMap you have to wade through a good amount of information until you can find how to just get the keys. I'm currently on mobile where the issue is more prominent.

shriek• 10 years ago

I'm also in a similar boat but my primary thing being that I learn by doing and since it's branded as "system programming" I immediately think of big projects like kernels and drivers. I wish there were some small projects that I could do apart from just doing "project euler" that would be helpful to me. I even bought raspberry pi to learn rust but don't quite know what to do with it and rust.

lacampbell2• 10 years ago

Not OP, but as someone who theoretically would like Rust - I'll bite. Maybe my usecase is a common one.

I understand memory management in C. I understand it modern C++ (destruction when going out of scope, smart pointers etc).

Basically, a description and discussion of borrow-checking for people who have already used system programming languages would be really helpful. I feel like the book is targeting people who have only used garbage collected languages.

Or is the memory management of rust so novel it can't be described in those terms? I find the concepts aren't very concrete to me.

papaf2• 10 years ago

What are you getting stuck on? I'd love to improve things.

I feel I am getting over the hump of learning rust now and coding in rust is becoming less frustrating for me.

However, one thing that slows me down is the lack of indices in the documentation. For instance, if I want to know the return type of a vector len() I go here:

https://doc.rust-lang.org/std/vec/struct.Vec.html

.. and then I have to search the web page for all instances of "len". It would be good if there was an index similar to Javadoc, Godoc or Doxygen.

There might be a good reason for not having the index, but as a beginner it is lost on me.

swuecho• 10 years ago

same feeling here. There are docs here and there, but not good.

I am waiting a good book on rust. similar to Haskell, I really did not get much until the book http://learnyouahaskell.com/

currently, "The book" is too dry.

dj-wonk2• 10 years ago

Programming Rust by O'Reilly is in early release and I recommend it.

eggy2• 10 years ago

I am having the same inertia.

I have resorted to using Nim for now, and it is going real well. I would like to rewrite the Nim stuff in Rust to compare for my own sake when I have done something substantial in it.

dagmx• 10 years ago

Have you tried: http://rustbyexample.com/

jokoon2• 10 years ago

A good language should be like a good game: easy to learn, hard to master.

We don't care about expert cases, we only care about getting productive ASAP, which means having students hoping into a language and learning it quickly. Solving the details is easy: just teach coding discipline and enforce good practice and do code reviews, and discourage "throwable" code. Security is not only the job of a programmer, it has many many facets.

In short: english is better than latin or esperanto. The more time and space you need to describe your language, parse it or the more character or syntax it requires and the longer it requires for an individual to read a program and guess what it does, the worse it is.

I'm getting a little tired of the "novelty" languages these last few years. Maybe I'm more conservative and don't like the hype. To me only D is relevant and it has been there for a long time now.

rweichler3• 10 years ago

LuaJIT + C have suited me just fine for systems programming. I don't care about security, so I find it hard to care about Rust. All I care about is lessening the burden on me as a programmer.

I think Rust may be useful in cases like ripgrep, where you basically rewrite an existing, established tool or service used by many to be as performant and secure as possible. But other than that niche use-case, I don't think Rust will catch on in the long-term.

pcwalton13• 10 years ago

Do you have a proposal to achieve Rust's goals in a way that's easier to learn?

Skalman• 10 years ago

For me the hump was from the get-go.

Following the book, I installed Rust directly, but then i realized that I should've installed it via Rustup. Next, I want a good editing environment, so I install VS Code and Racer, but then I find out that I can't use Clippy unless I use Nightly... and I'm not interested in using Nightly, so I'll wait.

steveklabnik30• 10 years ago

Rustup has been in beta for a while, which is why we don't recommend it in the book. Soon though!

sidlls3• 10 years ago

I just installed the nightly tarball and used my usual editor (emacs). I'm not sure what the editing environment has to do with a learning hump.

Now, coming from loose dynamic typed languages or really terrible C or C++ code bases is another matter.

staticassertion8• 10 years ago

Feel free to stop by the IRC and ask questions/ seek help - lots of people there who are willing to answer your questions.

Or the rust forums: users.rust-lang.org

Or the rust subreddit: reddit.com/r/rust

fizzbatter• 10 years ago

It's worth it, imo. I was in your boat a few months back and hated every minute of it. With that said, i'm still not 100%. I semi-regularly see syntax that makes me go "Wat is what!?", but then i sit for a moment and understand it. Rust introduces a lot of visual baggage and that seems to cause me syntax blindness.. not enjoyable.

Unfortunately though, i'm back on Go. I want to be on Rust, but i had to pick a language for work and i can't ask my Team to go through what i did. Rust, despite the safety, is too unnatural for our larger codebase.

Luckily i think Rust has seated itself as the language we will use if the need is truly there. Unfortunately though, not everything.. just the specific things that need it.

CodeMage2• 10 years ago

I'd love to see someone write a game engine in Rust to compete with the "big boys" like Cry or Unreal. C++ game code can be such a nightmare.

jcoffland• 10 years ago

It would be in Rust too.

CodeMage2• 10 years ago

True enough. However, I'm willing to bet that a non-trivial amount of nightmarish code in C++ comes from the language itself. Also, I'm willing to be that a Rust build would be an improvement over a C++ build. As an example, I'm really sick of header files.

mordocai• 10 years ago

Game code in general is usually a nightmare. I do think Rust would be better than C++ though, in a lot of ways.

Thaxll• 10 years ago

Not going to happen in the next 10 years, everything is built around C++. And tbh I don't see what would games benefit from using Rust instead of C++.

cderwin• 10 years ago

I've never worked on anything gaming related, but the bigger cross-platform games certainly have crashes. I can't even tell you how many times Fallout 4 has crashed for me (likely hundreds). I obviously don't know if rust could help, but it's not unreasonable to think it might.

zanny2• 10 years ago

Games are large codebases often not replacing the OS standard calls (which is where replacing C with Rust becomes problematic as you start breaking the standard library) that would benefit insanely from the safeties and default saneness Rust gives developers.

Any time you work in a large team in a corporate environment you want a language that lets you stab yourself in the foot as little as possible.

wyldfire11• 10 years ago

Consider Piston. Not able to compete with Unreal and Cry yet but it's a WIP.

[1] http://www.piston.rs/

[2] https://github.com/PistonDevelopers/piston

Retra6• 10 years ago

Piston is a mess, documentation wise. It's got like 50 different things called `Texture` and they're spread across 20 modules and every function you'll want to call is hidden under 5 layers of trait indirection.

I'm exaggerating, of course, but my experience trying to use Piston was absolutely miserable. Next to zero documentation, with endless layers of confusing abstraction. It's designed to have swappable back-ends, and that's a big hassle when you don't care about that.

htaunay2• 10 years ago

Cry/Unreal? Unlikely. But something in the lines of LOVE(https://love2d.org/) would be awesome!

kazagistar3• 10 years ago

I don't see why not, other then time and a healthy skepticism of the untested by the AAA game devs who might build one.

harveywi• 10 years ago

The state of Rust editors continues to evolve [1], but I would be curious to learn more about the editors/IDEs that people are using for Rust development. Any stories or thoughts?

[1] https://areweideyet.com/

vvanders2• 10 years ago

VSCode + Racer have been working really well for me. Pretty decent auto-complete and integration.

endisukaj• 10 years ago

rust-mode[0] has worked well for me so far. But I haven't written anything major with rust yet.

[0][https://github.com/rust-lang/rust-mode]

allengeorge2• 10 years ago

I'm using IntelliJ-Rust [1]. Doesn't go to the definition of macros, and sometimes auto-complete doesn't work, but - it's comfortable enough to use.

[1] https://intellij-rust.github.io/

baq3• 10 years ago

vim + racer do the job, but you have to annotate types quite a bit for autocomplete to work. I'd love it if there was a way to auto-annotate variables like the haskell plugin does it.

qwertyuiop92412• 10 years ago

Well, I'm an Emacs user. I don't necessarily care about the tools that more IDE focused people might (OTOH, RMS should loosen up on the AST: you can't afford to lose much more than you already have), but rust-mode works fine for me.

hawkice• 10 years ago

I use Emacs, mostly because my workspace has gotten too big for Atom to be consistently responsive (I've got dozens of projects with tens of thousands of lines of code and who knows how many files deep in the dependency managers internals).

dj-wonk2• 10 years ago

I use Atom with the language-rust package. I'm very pleased. Before Atom I was using Emacs. I don't expect to go back to Emacs unless I need terminal-based editing.

brandur• 10 years ago

I've had good luck so far with Vim + You Complete Me [1] (which uses a Racer background).

Check the GIF in its repo, but it gets you code completion boxes in Vim that pop up automatically in which you can tab through for the next results. It's very ergonomic compared to Vim's awkward built-in completion shortcuts, and gives you completion intelligence that's trending towards something like Visual Studio + C#.

[1] https://github.com/Valloric/YouCompleteMe

hguant• 10 years ago

Literally just started looking into Rust for use in production yesterday. I've been playing with it in two different editor.

SublimeText + Rust Enhanced has been really really awesome. In line error messages, fairly decent autocompletion (from what I've seen so far) - I don't really use full IDE's that often (vim is my go to) so this is what I imagine that feels like.

vim + vim-racer has been good. I use the `gd` command (go to definition) every now and then. I'm probably not getting the full use out of it.

I think my problem is that at the end of the day, it's a text editor and I don't have very high expectations. I want some syntax highlighting, I want curly brace and parenthesis matching, and I'd like to be able to change the font. Everything on top of that is gravy.

jdub• 10 years ago

For the last few weeks, I've been doing all my Rust hacking in Visual Studio Code + the RustyCode extension on both Windows and Mac. It's a good experience, but the (currently early in development) Rust Language Server will make it superb.

zanny2• 10 years ago

KDE recently broke off the syntax highlighting from Kate, so I'm super hopeful for eventual Rust support using racer in KDevelop soon, since its semantic highlighting is second to none.

fabianhjr• 10 years ago

Spacemacs' Rust Layer (Emacs) https://github.com/syl20bnr/spacemacs/tree/develop/layers/+l...

user59944614• 10 years ago

I'd like to see an analysis: "The amount of real world jobs available for Rust, in comparison to Ada."

The numbers may be self explanatory.

gcp9• 10 years ago

What would they explain though?

wyldfire11• 10 years ago

They would explain Rust's relative youth and corresponding growth opportunity. ;)

hubert123• 10 years ago

still compiles too slowly, a language in 2016 just cannot take multiple seconds for me to use it add 5 crates and watch ur compile/run cycle climb to a cool 10+ second average.

steveklabnik30• 10 years ago

We had significant compile-time improvements in the release yesterday, with more to come in the future. Also, you might want to give incremental recompilation a try, it's nightly-only for now, but being actively worked on.

add 5 crates and watch ur compile/run cycle climb to a cool 10+ second average.

It should not recompile those crates each time, if it does, that's a bug. Please report them!

coolsunglasses2• 10 years ago

Just to litmus test this, I rebuilt a small Rust project of mine that depends on 41 crates.

Debug build took 15 seconds, release build took 37 seconds. Rebuilds are sub-second.

This is 0.15 nightly.

TBQH, Rust's release builds are already faster than GHC's -O0 builds for me. I'm still bereft a REPL (I live in a REPL), but it's not a deal-breaker.

nnethercote2• 10 years ago

It should not recompile those crates each time, if it does, that's a bug. Please report them!

Depends on the inter-crate dependencies, alas. Touching one crate can easily cause multiple other crates to rebuild.

computerphage3• 10 years ago

Incremental compilation is stabilizing on Nightly. It won't help the initial compile, but waiting even 5-10 Minutes when I start working on a new codebase doesn't really matter to me. It's only the incremental speed that I care about.

anfroid555• 10 years ago

Anyone know a tutorial course for someone only knowing high level languages. And not c or Ruby. More JavaScript, PHP, nodejs, Python

oldsj2• 10 years ago

Rust for rubyists?

steveklabnik30• 10 years ago

It basically doesn't exist anymore; I stopped maintaining it pre-Rust 1.0.

salicideblock• 10 years ago

I did one of the rust-koans out there and it went very well. Can't really remember which one, though...

quotemstr15• 10 years ago

I lament what Rust could have been had its designers not jumped on the anti-exception bandwagon. Rust's error handling is bad and makes me prefer C++

IshKebab• 10 years ago

Seriously? Rust's error handling is great, and frankly I'm glad that exceptions have gone out of favour. I tried them but they never really delivered their promise. At their best they do is give you nice stack traces. At their worst they make error handling stupidly verbose, they erase the context you need to properly handle errors, and they make it much more difficult to even know which errors can occur!

Rust's solution is the best I've seen so far. Go's multiple return values are pretty good too but I think Rusts's is better.

quotemstr15• 10 years ago

I very strongly believe exceptions are a lot closer to optimal than Result is. Exceptions remove the need for inline error checking code and make it possible to implement types with value semantics. You can't have reasonable value types that own resources if you need explicit error checking.

The need for explicit error checking makes OOM handling in Rust awkward at best. I've ranted about this side effect before.

Also, in Rust since we can panic, we need to worry about exception anyway! Rust has the worst of both kinds of error handling.

Exceptions are anti verbosity: you're supposed to let them propagate, not catch and rethrow them. They don't erase context: they preserve it, since an exception object is constructed as close as possible to the error site that caused it.

I realize that I have a minority view, but I'm utterly convinced that I'm right and that I'm living in a world gone mad. I've written a ton of code over the years. At least hear me out and try to understand my perspective.

htaunay2• 10 years ago

Congrats to all the Rust team!

Love the zero-cost abstraction approach, love the good practice compiler warnings, love the cargo ecosystem, love the markdown code dox that tests the example code.

First time I actually enjoyed reading a programming language's documentation.

deavmi• 10 years ago

I agree. We need safer languages. Not that I know much about safety. I still know we need it.

mavsman• 10 years ago

Coincidence that many of the Rust promoters have red hair?

Rust and the Future of Systems Programming [video]

Related Stories