Why I think Rust is the "language of the future" for systems programming

Rust and Go provide me with more day-to-day pleasure than... well... a sadly large number of things. This is a good resource for learning more Rust, thanks.

kibwen12• 14 years ago

Out of mild concern over the title (not that it ought to be changed, TFA doesn't really have a meaningful title), I'd like to preemptively defuse any potential flame war.

Go and Rust are not really competing. There may be some overlap in domain, but they occupy different niches and will likely appeal to different crowds. Go will appeal more to people who prefer its focus on conceptual simplicity and its "opinionated" nature (very much like Python). Rust will appeal more to people who prefer "functional" trimmings (algebraic datatypes, pattern matching, liberal use of higher-order functions, Scheme-style macros) as well as folks fed up with C++ who aren't willing to give up complete control over memory and performance characteristics. The fact that both languages are built around a similar concurrency model is just convergent evolution.

It's tempting to cast Go vs. Rust as Google vs. Mozilla and/or Chrome vs. Firefox, but there's no practical reason that both languages cannot peacefully coexist and thrive.

zheng• 14 years ago

Does Go not have higher order functions and pattern matching? If not, are they on the roadmap?

kibwen12• 14 years ago

I'm sure that Go has higher-order functions, I just mean that Rust encourages you to use higher-order functions all the time. For example: in Rust, `for` loops desugar to higher-order functions (it's very neat, actually). Furthermore, whereas in Go you spawn a goroutine with the `go` keyword, spawning a task in Rust is done by handing a function (usually a Ruby-esque closure) to the `task::spawn` library function. (Note also that "higher-order functions" are not the same as "first-class functions".)

Go does not have pattern matching, to my knowledge, though without algebraic datatypes I don't think it's really a big deal.

wonderzombie• 14 years ago

Go does not have pattern matching. There are type assertions, but obviously that's not the same thing.

Go has higher order functions in some sense, and the standard libraries use them for some things. But I wouldn't say they're nearly as ubiquitous as they are in Ruby or your average functional language. My read is that Go is pretty firmly grounded in imperative-land.

Regardless, since Go 1 came out relatively recently, I doubt they're going to make substantial changes to the language anytime soon. Obvs I don't speak for them, etc etc.

djhworld• 14 years ago

Go has first class functions yes, but without the support for generics/parametric polymorphism, you can't write "higher order functions" for polymorphic functional constructs like map/filter/reduce etc.

pcwalton12• 14 years ago

The two languages aren't really in the same space in the first place. Go is a simpler language that leans more heavily on garbage collection. Rust is a more complex language that can be safely used without the GC at all.

Go is a great language -- I greatly admire its simplicity -- and for its domain it's fantastic. Rust is in a different domain: low-level systems programming in which abstractions must be zero-cost and control over the machine is crucial.

shanemhansen• 14 years ago

Go actually provides what I believe to be zero cost abstractions that map straight to the c memory model, making it very easy to use for systems programming.

If you want a fixed size array of bytes, for for it. Zero overhead. If you want a slightly smarter list you can use a go slice, which is also pretty low overhead. I've personally verified that if I create a struct in go it takes up the exact same amount of memory as the same c structure.

As a concrete example, I recently built an interface to kernel crypto apis using pure go (no cgo). There's no magic to go data structures, you can define structs in go and pass pointers directly to syscalls (through the syscall package) and everything just works. Dealing with large arrays of binary data is similarly straightforward. So go does give you complete control over memory layout if you choose to use it.

The elephant in the room is that go does have garbage collection, and that ain't free. Practically you can minimize it's impact by managing your own memory. In fact that's what Brad Fitzpatrick is doing with his go based memcached implementation.

It all boils down to how you define systems programming. I guess if you mean is go suitable to write a kernel in, the answer is probably no, (but it would sure be fun to try). If systems programming requires having the complete ability to interact with the operating system and all syscalls + tight control over memory layout, then maybe go is the way to go.

https://github.com/shanemhansen/gocryptodev/

[edit]

with respect to python and garbage collection, did you know you can actually turn it off? If you have no cycles in your program you can turn off gc and let the ref counter clean up all your data, similar to Objective-C's ARC.

http://docs.python.org/library/gc.html

jksmith2• 14 years ago

Simplicity is absolutely the most crucial aspect of a language used for successful commercial application in my space (15-30 mil annual). That's what I like about Go. Don't know much about Rust, but if it's being designed by a small group of engineers who think oop is still awesome, then successful commercial software developed in Rust will be just as costly to maintain as the 500k to 5 mil line codebases I run across today, written in currently available languages.

Speaking in general:

You get all this wonderful language functionality, and I promise you that you will write some shitty code at some point just to keep up with the daily pressures presented by a successful software package (clients screaming, salespeople breathing down your neck, etc), I don't care how good of an engineer you think you are. What's really funny is that, because everything has gotten so much more complicated (dev tools, business, cost of bugs going up, how to make money with software, whatever), the successful software I work on today is not making any more money than the successful software I worked on back in the late 80's running under DOS. Back then, the oop free tools and the target os were simple enough that we really could become SME's on our domains as well as on the dev tools we used to write code for those domains.

C# and java are definitely not the solution for new applications which are expected to generate revenue for the next 10 years. If Rust is just trying to be smarter at what these languages already do, I'm not interested. Something has got to come along which simplifies development, especially concurrency, and allows programmers of varying skill levels to write productive code in. Then after 5 mil loc, programmers coming and going on a project, an app doesn't end up looking like a fragile mess.

zurn2• 14 years ago

> programming in which abstractions must be zero-cost and control over the machine is crucial

How well does Rust do in this zero (or low) cost department? In C++ STL there's the same goal, but it compiles to code very far from what you would write in assembly without abstractions.

Eg. how are code compactness and data layout optimizations?

eevee11• 14 years ago

For what it's worth, I like Rust because I like Python. Python does strive to have one "obvious way to do it", but that ends up meaning it has a very colorful toolbox full of different ways to solve different problems, much like Rust. Generators, context managers, metaclasses, decorators, and descriptors are all very different mechanisms, but they all work together well.

Hell, I keep discovering that Rust has already implemented language features I'd independently thought up half-baked versions of.

And not to encourage a flamewar, but I believe there's a gigantic unspoken niche that Rust and Go will be fighting over: people like me who stay away from systems programming because it's a pain in the ass. C is tedious, C++ is bozotic, D is obscure—so the lowest I've bothered to go for a while is Cython. But now there's Rust, and I'm genuinely enjoying it, and I see other people who've mainly been sticking to Ruby or Python who are enjoying Go. This will be interesting to watch. And regardless of what I think of Go, I'm glad there's finally some activity in this space again. :)

cdavid• 14 years ago

I have not had time yet to look into rust more closely, but do you know if it would be able to export a Rust module in a dlopen-able library, accessible from C ? Writing python extensions in Rust instead of C would be pretty exciting

cmccabe13• 14 years ago

Rust has three different ways of allocating memory. And you can't pass things allocated one way to functions that expect something allocated the other way.

A Python replacement, this ain't. More like C++ on quaaludes.

reinhardt• 14 years ago

Would be interesting to read a comparison with D. And no, "obscure" is not a meaningful description when comparing it to a language still at v0.3.

fauigerzigerk• 14 years ago

Of course they compete. People aren't born with a gene that puts them into exactly one of the camps you describe. These ideas compete and so do the languages, provided they can be used for largely the same tasks, which seems to be the case.

megaman8212• 14 years ago

Rust is what I had hoped Go would be.

Google employs some of the brightest computer science minds in the world and turns out stuff like Go and Dart, which seem to be more aimed at enterprise Java programmers rather than computer scientists or programming enthusiasts.

mtgx• 14 years ago

Maybe because that's what Google needs its own programmers to learn right now. Although, they should make a language that's meant to eventually replace Java/Dalvik for Android as well, and a language that's very easy to use and learn.

Lewisham• 14 years ago

Yeah, absolutely. Go and Dart really both fit needs of working with large software and giant scales. As I think they've both said independently, conservative design was considered a design bonus. You can see why as it gets teams up-to-speed quickly, is less off-putting to project managers, and is more likely to benefit from experience surrounding how to write effective, readable code forms.

Stuff like Rust is awesome, but no-one yet knows what an Effective Rust book might look like, and you really need that sort of solidified design understanding to work. Code is write once, read hundreds of times, so that exciting wild west of "we don't have idioms yet" simply won't fly at a big company.

stcredzero• 14 years ago

One could automatically translate the Java API part of Android into Go? Also, it should be possible to write a VM for Go by extending Dalvik? I suspect that this territory is claimed by Dart, however.

kibwen12• 14 years ago

Neither Mozilla nor Google are particularly keen to faff around designing languages for the hell of it. :)

Google needed to ease the burden of hours-long Java/C++ compile times on massive projects. Hence Go.

Mozilla needed a language that was as fast as C++, but safer and trivially parallelizable. Hence Rust.

Beyond these goals, the fact that the rest of the world is excited for these languages is just gravy.

zobzu3• 14 years ago

Well, that makes Mozilla's language goals a lot sexier to a lot of us i believe =P

nightski• 14 years ago

Seems weird. Google especially is a company that relies so much on programmer productivity & getting things right. Getting them wrong typically means lost revenue.

I mean they spend crazy amounts of money on all kinds of projects that have no directly viable monetization scheme, yet for some reason you think it would be weird for them to explore programming languages? Odd.

neilk3• 14 years ago

You attribute too much to these entities called "Google" and "Mozilla". They're made of people.

No executive asks for a new programming language. However at some enlightened organizations, they are willing to let hackers explore radical approaches.

At some point, in order for them to become "official" projects, the hackers have to align the language with the organization's goals. But the imprimatur of their creators is unmistakable.

In any case, I doubt there is any plan to move everything in Google to Go. They're willing to let the creators and some enthusiasts play around with it, maybe deploy a few apps internally. But for Rust to be a success, Mozilla's going to have to use it extensively in their main product.

ww5204• 14 years ago

I understand C++ project can take a long time to compile. Does Java project really take hours to compile?

Arelius2• 14 years ago

You know, I've worked on some pretty large C++ projects, and the only time I've seen an hour long compile time, it was due to some include hell that was pretty trivially optimized.

zxcdw12• 14 years ago

I'm assuming you'd rather see them focus on declarative programming, because it seems to be the big thing among enthusiasts and hobbyists.

Google works with software projects with planned lifetime of decades. It's far better to rely on imperative programming concepts which are tested and trusted with experience grown from what, 50's or so.

Sure, declarative programming is a nice toy, but that's all. I'm yet to see major companies investing millions, if not billions of capital on a system written in declarative languages. We all "know" functional programming "is the future", but yet nobody trusts their money and time on them.

I still wonder if there are major commercial projects started with say Python or Ruby, or JavaScript which have planned lifetimes to 2030 and beyond.

tbrownaw• 14 years ago

I'm yet to see major companies investing millions, if not billions of capital on a system written in declarative languages. We all "know" functional programming "is the future", but yet nobody trusts their money and time on them.

SQL is declarative.

Erlang is kinda-sorta functional, and was developed specifically to run expensive high-uptime telecom systems.

fijal• 14 years ago

Meerkat telescope project has lifespan of at least 20 years and it's control-and-monitoring software is being written in Python.

This is to answer your direct question only because I fail to understand how your paragraphs fit together.

bzbarsky2• 14 years ago

Hedge fund trading code may not have "2030 and beyond" lifetime, but it's certainly something major companies are investing a good bit of money into. Also tends to be in OCaml...

krickle• 14 years ago

My understanding is that a significant number of quants use Haskell.

sanderjd• 14 years ago

You seem to be using a definition of "declarative" that I'm unfamiliar with. The functional languages you target in the second to last paragraph are very different from the more imperative languages in the final paragraph, and I wouldn't consider either group to be "declarative". I'm left wondering what concepts you're attempting to criticize.

Having said all that, yes, I believe major commercial projects are started in those languages, though I have no idea if anybody plans them into the 2030s.

tptacek2• 14 years ago

What do Go and Dart have to do with each other, besides their origin at one of the largest tech companies in the world?

Have you written much Go? What do you think of it in practice?

megaman8212• 14 years ago

As languages, nothing. In design, their conservative nature.

burntsushi• 14 years ago

I am a computer scientist that has performed research using Go because I love working with Go. I absolutely despise Java. So I'd say that your assessment is a bit off.

I also look forward to trying Rust as well. Having algebraic data types makes me giddy.

Calamitous2• 14 years ago

Has anybody heard if they've finalized a spec yet, or at least come close? I've thought about getting into Rust from time to time, but the lack of a finalized spec and/or stable reference implementation has always scared me off.

pcwalton12• 14 years ago

We're getting close. Rust 0.4 (hopefully to be released next week, assuming no more schedule slips) will be quite close to final syntax-wise. Although not all the features will be implemented, your code will be mostly backwards-compatible.

If you'd like to try out the language, I recommend working off git master rather than 0.3; the language has been dramatically simplified in Rust 0.4.

Calamitous2• 14 years ago

Excellent, thanks for the update! :)

brson2• 14 years ago

There is no finalized spec (and the spec has actually fallen quite far behind for the moment), nor do I expect anything about Rust to be called 'final' for a while yet.

The upcoming 0.4 release (any day now) makes a big push to get a lot of the syntax pieces in place, but still has many rough edges. Beyond that the standard library is still an incomplete and inconsistent stew of different styles.

Rust is still firmly alpha software, but should stabilize significantly in the next year.

rokekr2• 14 years ago

Rust feels more like Perl 6 (always on the horizon) or Ada (the do everything language), while Go already is already specified, being improved, and out in production.

jallmann• 14 years ago

I see Rust has ADTs and strong static typing, how much is enforced at compile time?

One thing I love about OCaml is its exhaustiveness checking. I've been doing a lot of Erlang and it feels so dangerous without the compiler telling me if I've missed a pattern, or if a clause might return the wrong type. (Dialyzer and typespecs help somewhat, but aren't nearly as nice.)

If I could have that sense of safety with Rust, I would be persuaded to investigate it sooner rather than later.

bblum5• 14 years ago

Short answer is "all of it"[1]. 'match' statements in rust also exhaustive. I believe ADTs are used and checked exactly the same way as in ocaml (I've used SML and Haskell and they are the same as there).

[1] not to say dynamic failure is totally gone from the language -- but it is if you avoid both writing 'fail' and using library functions that can fail. A common example is option::get(Option<T>) -> T, which fails if the optional value is None -- it leaves a sour taste in my mouth whenever I use it, but I still do sometimes.

erichocean• 14 years ago

which is especially important in the multicore world where heaps must be protected by a global lock

The article seems nice, but this is misleading at best, and flat out false at worst.

Concurrent memory allocation has been around for many years, and gasp is perfectly usable with C.

bblum5• 14 years ago

I wondered how long it would take for somebody to call me out for that. It seemed like a sketchy claim when I wrote it (it wouldn't be too complicated to make the @-heap lock-free in rust, for starters), but in retrospect, I shouldn't have said it at all. Thanks for pointing that out.

bblum5• 14 years ago

I tried to think of an alternate justification, but couldn't come up with a non-awkward way of saying it, so just redacted that part entirely. I'll say here, though, a few reasons I think avoiding malloc/GC is important:

- pcwalton has mentioned his desire to be able to reason about when the garbage collector runs, so that he can statically guarantee that the graphics rendering task in servo will never take a big pause to do a GC.

- In this-must-never-fail environments, such as writing kernel device drivers, using dynamic allocation has to be avoided (and, if i'm not mistaken, even more likely to fail when done in an "atomic section" using kmalloc(GFP_ATOMIC)). Rust in its current state is not suitable for kernel-level development, but it's not far off; and it's critical to be able to reason about memory allocation for such applications.

zobzu3• 14 years ago

I don't know if it is the language of the future, but Rust is definitely high on my "let's reprogram Singularity/Plan9/Friends"-and-actually-use-it list

I'd certainly join and attempt to help any project started in that direction, at least.

mburns• 14 years ago

Makes me wonder if anyone is working on a llvm-to-rust compiler.

wmf2• 14 years ago

What would that be used for?

eholk• 14 years ago

It's interesting that you mention Singularity, as it turns out that Singularity has been a major influence on Rust. For example, the current communication is very similar to the channel contracts used in Singularity.

zobzu3• 14 years ago

Well I'm a big fan of many concepts of Singularity. And I like rust. I guess that's no coincidence ;-)

mappu• 14 years ago

How do you implement closures entirely on the stack? What about the case when a function returns a closure into an external translation unit? How do you cover the bound parameters? You can't do call-time lambda lifting if the bound parameters are out of scope at the call site, you need to put something on the heap and GC it. Same with compile-time lambda lifting (producing a chain of bind1st stubs on the executable heap)

bblum5• 14 years ago

My mistake. I meant to write "can SOMETIMES be entirely on the stack" -- fixed that just now.

Functions indeed cannot return closures without heap-allocating them. (It might be possible in specific obscure cases, but definitely not in general.) However, if you wish to curry a function foo(a,b), you can do that in the caller (instead of at the function definition itself) by writing:

let curried_foo = |b| foo(a,b);

That is then stack-allocated and can refer to 'a' in the same frame, and can be passed to other functions you might call from there (but not returned upwards, indeed).

kibwen12• 14 years ago

I'm not an expert, but I believe that Rust will allocate closures depending on the data that they close over. So if you reference a stack-allocated variable from within your closure, it gets put on the stack. If you reference a heap-allocated variable from within your closure, it gets put on the heap.

I could be dreadfully wrong, though.

pcwalton12• 14 years ago

No, where a closure is allocated depends on the type of the closure. The type of the closure is inferred just like any other type. It has nothing to do with what it closes over (although what it the closure is allowed to close over depends on its type).

james4k• 14 years ago

Three different types of pointers? Perhaps that is going a bit far?

> If you've a sharp eye, you're wondering what that "~" is that I snuck in on the type of the closure for the child task. That's actually a pointer type, of which Rust has three (none of which can be null, by the way):

> ~T is a unique pointer to a T. It points to memory allocated in the send heap, which means data inside of unique pointers can be sent between tasks. You can copy unique pointers, but only by deeply copying (otherwise they wouldn't be unique!) (and by default, they are "non-implicitly-copyable", so the compiler will issue warnings if you copy them without writing the "copy" keyword).

> @T is a managed pointer to a T. Currently, these are reference-counted and cycle-collected (they may be full-on GCed in the future). Copying one increments the reference count, so multiple managed pointers can point to the same data. These are allocated on a per-task private heap, and cannot be sent between tasks.

> &T is a borrowed pointer to a T. It can point to the inside of arbitrary data structures - on the stack, inside ~ or @ pointers, etc. Rust has a static analysis, called the "borrow checker", that ensures that borrowed pointers must not outlive the scope of the pointed-to data (i.e., it is impossible for rust programs to have a use-after-free).

kibwen12• 14 years ago

It's not too daunting. `&` is your go-to pointer for most scenarios. `~` pointers are for anything you want to send to a different task. `@` pointers are for things you want to be garbage-collected.

rohshall• 14 years ago

Fantastic summary of the pointers. It's less daunting now.

scott_s5• 14 years ago

Do you have reasons why it's going too far, or is that just an emotional reaction? Consider that these pointer types map exactly to the pointer-type templates provide by C++11: unique_ptr, shared_ptr and weak_ptr: http://en.cppreference.com/w/cpp/memory

In the interest of starting discussion and not just stating facts, I will take the position that I think Rust's adoption of these concepts into the language is a Good Idea. Many pointer-based codes have these pointer types, but they are enforced through convention alone. C++11's templates are a step in the right direction, as they make explicit what convention assumes, but the compiler does not know about them. Yes, because they are template classes, there are certain things one can and cannot do with, say, a unique_ptr, but the compiler cannot do any analysis on the usage, because the concept has no representation in the language semantics. (Ben references a blog post by Niko Matsakis about some of the analysis Rust does: http://smallcultfollowing.com/babysteps/blog/2012/07/19/yet-...)

_delirium• 14 years ago

I agree they're good to put into the language semantics, but as a side point on C++11, couldn't the compiler actually assume a bunch of things about those templates, since their behavior is specified? GCC, at least, assumes many things about even C stdlib functions, because it "knows" what they do, so rather than treating them as just regular functions, it can make stronger assumptions about them when optimizing, and/or generate code to implement their functionality internally, rather than linking the library implementation.

cmccabe13• 14 years ago

A lot of the productivity gain in higher-level languages comes from not having to manage memory. Having three different incompatible, differently allocated pointer types to fool around with slows you down. The creators of Rust are hoping that the speedup from not having to do global garbage collection in most scenarios will balance out the loss of productivity.

Personally, I'm skeptical. Azul showed us that pauseless GC was possible, even for Java. Android and .NET showed us that even without pauseless GC, the performance of GC'ed languages was adequate to build attractive user interfaecs. A lot of Rust's design choices mean that it's not really suitable as a web development or scripting language, and those two communities have shown themselves the most receptive to new languages.

Mozilla has tried to rewrite their core product in a different language before. Look up "Javagator." It did not end well. But, who knows. Maybe this time really will be different.

elchief• 14 years ago

why didn't they call it YAPL?

haberman4• 14 years ago

I'm a die-hard C guy. My motto for years has been "you can pry pointers and address spaces from my cold, dead hands."

Of the new languages I've seen lately, Rust is my favorite. I love how it gives me better ways to express things I actually want to say without imposing GC on me.

But even so, I can't see myself actually using it for much, because writing in a language other than C means buying in to that language's runtime. Buying into one language's runtime means that your code won't play nice with other languages' runtimes.

If I write a library in Rust, how can I expose my types and algorithms to Ruby, Python, Lua, etc? How will Rust Tasks play with Python threads? What if I use a Rust Pipe to send a Python value between tasks? How do I keep Rust from doing a GC pass while I'm holding the Python GIL? etc. etc.

Programming Languages by their nature want to be at the center of your world. If you buy into their abstractions, everything works nicely. But if you try to mash two of them together in a single process, you start to suffer from the fact that their abstractions overlap and don't interoperate at all.

If you're only writing an application (ie. not a library) and never want to embed other languages into your application, then this might be ok. But I'm more interested in writing shared functionality that is useful across languages. Why should the whole stack of parsers, crypto, compression, etc. have to be written separately in each language? Life is too short to do some great work that is only usable by one language community -- computing is so big and changes so much that one-language-only functionality is at best limiting your market and at worst dooming your code to obsolescence when the next big language comes around.

So as much as I instinctively like Rust, I think I'll be sticking with C.

kibwen12• 14 years ago

I'm not sure if this will alleviate all of your issues, but eventually the goal is to allow Rust programs to forgo the runtime entirely.

An old comment from pcwalton (sorry, I've lost the link):

"I'd like to see a 'runtime-less Rust' myself, because it'd be great if we could implement the Rust runtime in Rust. This might be useful for other things too, such as drivers or libraries to be embedded into other software. (The latter is obviously of interest to us at Mozilla.) Rust programs compiled in this mode would disable the task system, would be vulnerable to stack overflow (although we might be able to mitigate that with guard pages), and would require extra work to avoid leaks, but would be able to run without a runtime.

"If anyone is interested in this project, I'd be happy to talk more about it -- we have a ton of stuff on our plate at the moment, so we aren't working on it right now, but I'd be thrilled if anyone was interested and could help."

See also the remark by brson further down in this thread: http://news.ycombinator.com/item?id=4578044

pcwalton12• 14 years ago

"If write a library in Rust, how can I expose my types and algorithms to Ruby, Python, Lua, etc?"

The same way you expose them in C. Rust and C are compatible at the binary level.

"How will Rust Tasks play with Python threads?"

More or less the same way C setcontext()/swapcontext() workalikes play with Python threads. We probably want a runtime-less Rust to allow users who aren't using tasks at all to just omit the whole system, though. The language itself knows nothing about tasks; they're purely part of the runtime library.

"What if I use a Rust Pipe to send a Python value between tasks?"

Should work as you expect. In Servo we're already sending Objective-C values (which require special APIs to perform the memory management) from task to task over pipes.

"How do I keep Rust from doing a GC pass while I'm holding the Python GIL?"

By not using the GC. It's easy to tell when you aren't using the GC; you can just avoid @ types, and there is a warning you can turn on to enforce no GC use. This sort of thing is the reason why we support manual memory management.

"If you're only writing an application (ie. not a library) and never want to embed other languages into your application, then this might be ok. But I'm more interested in writing shared functionality that is useful across languages."

We're already successfully embedding a JavaScript engine into a pure Rust program for Servo. JavaScript can access Rust types and vice versa.

"Why should the whole stack of parsers, crypto, compression, etc. have to be written separately in each language?"

I agree completely that this is undesirable. That's why Rust doesn't do this. For your three examples, Rust and Servo link to C libraries: Hubbub for HTML parsing, NSS for crypto, and zlib for compression.

haberman4• 14 years ago

Thanks a lot for the info!

> We probably want a runtime-less Rust to allow users who aren't using tasks at all to just omit the whole system, though.

I'd be really interested in reading more about this if/when it is available. I'm also interested in whether you'd ever ship the tasks library standalone, such that you can interoperate with Rust tasks from C (obviously you'd have to follow certain rules to maintain the integrity/safety of the runtime).

> I agree completely that this is undesirable. That's why Rust doesn't do this. For your three examples, Rust and Servo link to C libraries: Hubbub for HTML parsing, NSS for crypto, and zlib for compression.

Understood, but I'm interested in the story for the guy who is writing those libraries.

pron• 14 years ago

> The language itself knows nothing about tasks; they're purely part of the runtime library.

How are they implemented? Do you provide access to low level concurrency constructs such as CAS, threads etc.?

gnuvince• 14 years ago

Perhaps the language Clay (http://claylabs.com/clay/) might fit your tastes better?

primitur2• 14 years ago

I'm a C die-hard as well.

Tell you what I'm doing lately, that makes me less and less interested in the new-school elite, and just generally enjoying a language 'enigma' moment: putting Lua in everything.

That is, I mean to say, Rust is neat and all but we can do it all in Lua, pretty well, too. Table types are fabulous, kids!

And being able to take any collection of C libraries, and glue them together into 'ones own runtime' with a common language framework/boundary, means a lot.

So, yes, of course.. Lua isn't fast, it has weaknesses, there is luaJit and so on: its not about Lua. Its about the fact that you can choose whatever languages are out there, get competent at their adept usage, and win.

I believe that Rust will be a systems programming language when there is a bootable Rust OS that boots to an editor, a shell, a means of interacting with devices, and a Rust compiler sitting there, waiting for input .. until then, it sure is fun to watch the new school language paradigms get all twisty and bent in the rush to school someone on how systems 'should be programmed, instead of the way they are now'. Research in this field is a terrifically interesting social cache.

Has anyone done a RustOS? Is there one? I know of a couple LuaOS projects, and it sure seems to me like what was done with Linux on Android could be done to Linux, again, with Lua .. Rust .. and so on. Could be very cute times ahead, in the distribution mecca .. GoboLinux, but instead 100% booted to Lua? Hmm .. bogglethink .

eevee11• 14 years ago

Is this intentionally snide? You appear to be implying that nobody should try to solve problems, because we already know how to work around them.

kombine• 14 years ago

The whole idea of modern systems languages like Rust or D is actually to avoid the need of using Python, Ruby etc. The language covers all your needs in a nice coherent package from top to bottom.

jeremyjh• 14 years ago

His use case is writing libraries that can be re-used broadly.

haberman4• 14 years ago

> The language covers all your needs

This is exactly the "one language" myopia that I was arguing against. Anyone who tries to sell me on a language or programming system that asks for complete buy-in and offers no interoperability story is immediately suspect in my book.

(FWIW, I don't think the Rust guys actually sell this line, so I'm arguing against you, not them).

No one will ever invent "the last language you'll ever need." One reason for this is that different languages excel at different things. For example, Rust is not as easy to sandbox as Python, Ruby, etc. It's also not as simple to write quick scripts in.

Another reason is that you'll never convince everyone in the world to use the same language. Even if you convinced them that they should use the same language (which is impossible), there are billions of lines of code in use that is written in different languages. If you can't interoperate with them, you are a rock, you are an island.

There's nothing "modern" about the idea that "we're going to make the last language you'll ever need."

EternalFury• 14 years ago

Another language that adopts a different syntax for the sake of adopting a different syntax. If you are going to ask me to adopt a different syntax, you'd better have a good reason for it, because I can do everything I need to do with the languages I already have.

bryanlarsen• 14 years ago

You can do more in assembly language than you can in any other language. That doesn't make it a good language to program in except in very special cases.

ww5204• 14 years ago

Rust looks very interesting. I downloaded it and tried it out on Windows but got "libgcc dll missing" error. They really need to statically link in the MingGW runtime to make it easier to run.

pcwalton12• 14 years ago

There is a bug on doing that, but keep in mind that bundling libgcc would only make Rust error out with a more informative error. Because Rust uses the system linker, you need MinGW installed to use Rust.

marshray• 14 years ago

Someone ought to mention the similarities between Rust and Scala. These are two really great languages, IMHO.

shmerl• 14 years ago

Rust indeed looks very promising. I hope it'll pick up usage beyond Mozilla internal projects.

BrandonM• 14 years ago

From the end of the last post in the series (http://winningraceconditions.blogspot.com/2012/09/rust-4-typ...):

    let arc = RWARC(some_data);
    for num_cpus().times {
        let arc2 = clone(&arc);
        do task::spawn |move arc2| {
            process_data(arc2); // might read, write, whatever
        }
    }
    let modified_data = unwrap(move arc); // blocks on all child tasks at once
    // do more of the algorithm, etc.

This is a nice fork/join pattern, allowing implementations with minimal copying and reasonable safety. If this is indicative of design decisions made by the creators of Rust, I think it looks pretty good.

philhippus• 14 years ago

>Stack-allocated data lets you often avoid dynamic allocation overhead and garbage collection (even closures can sometimes be entirely on the stack).

There's an entire website named after the results of over-using the stack. Smart pointers and move semantics in C++11 completely smoke GC and memory management everywhere else.

While I'm sure Rust is a nice language and I applaud its innovation,there's already a perfectly good wheel.

argv_empty• 14 years ago

Smart pointers and move semantics in C++11 completely smoke GC and memory management everywhere else.

Aside from having to enforce proper pointer usage at runtime, whereas Rust does it at compile time.

Why I think Rust is the "language of the future" for systems programming

Related Stories