Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

winningraceconditions.blogspot.com

Post reply on HN
Print view View original

51–60 of 193 posts

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

#51

Post by scott_s »

_delirium wrote: post #46
scott_s wrote: post #38

Earlier quoted context omitted.

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…

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…

You can, but the difficulty, I think, is that this clean separation of pointer types exists along with naked pointers, including void*. That is, C++11 still carries the legacy of C's free-for-all, so the kinds of guarantees that one could get from a C++ compiler - even with baked in knowledge of unique_ptr, shared_ptr and weak_ptr - are going to be limited.

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

#52

Post by bblum »

bblum wrote: post #45
erichocean wrote: post #22

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.

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.

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.

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

#53

Post by mbrubeck »

davidw wrote: post #34
nagnatron wrote: post #26

Earlier quoted context omitted.

I don't think it's like that. I think they're just developing it through usage. And it's not like it's been ten years yet.

> I don't think it's like that. I think they're just developing it through usage. What's shipping with it? I have a bit of the same impression that the other poster has, that it's always in development without something stable. I hope that gets dispelled sooner or later, because, for better or worse, fuzzy marketing type things like that matter.

Your impression is completely accurate; the language is in development and is not ready to use yet. It shouldn't be used in any shipping products. There's nothing to "dispel" here until the 1.0 syntax is is finalized; fortunately that should happen in months rather than years.

From a pure marketing perspective, sure, maybe it would be better to finish more of the design and implementation before talking about it publicly. But Mozilla's pretty committed to working in the open, and that has its own benefits. For example, significant parts of the Rust implementation were created by contributors who were not paid Mozilla staff, including a Google employee (in her spare time).

(Disclosure: I'm a Mozilla employee but not part of the Rust team; I've contributed a little bit to the Rust compiler in my free time.)

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

#54

Post by wmf »

mburns wrote: post #42
zobzu wrote: post #25

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.

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

What would that be used for?

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

#55

Post by kibwen »

neilk wrote: post #47
kibwen wrote: post #17

Earlier quoted context omitted.

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.

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…

"No executive asks for a new programming language."

Not that I think you're wrong, but I think the histories of Javascript and Ada stand as exceptions. :)

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

#57

Post by eevee »

cdavid wrote: post #48
eevee wrote: post #40

Earlier quoted context omitted.

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…

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

Ha, I was just thinking about how Rust bindings to Python might look.

I haven't actually tried this, but since Rust libraries just compile to .so's and it's possible to declare a Rust function with a C signature, I bet it'd be a simple exercise to write a CPython-compatible extension module.

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

#58

Post by tptacek »

wonderzombie wrote: post #18
zheng wrote: post #7

Earlier quoted context omitted.

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

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 recent…

Go has full closures and first-class functions, and their use is as idiomatic in Go as it is in Javascript; for instance, they're the mechanism by which you implement filtering in the "http" package.

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

#59

Post by tptacek »

megaman821 wrote: post #9

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.

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?

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

#60

Post by pcwalton »

shanemhansen wrote: post #41
pcwalton wrote: post #8

Earlier quoted context omitted.

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 an…

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 memor…

There is a lot more to zero-cost abstraction than memory layout. If you do manual memory management in Go, then you get no safety. It is also difficult to use the standard library with manual memory management. Furthermore, interfaces in Go are not zero-cost; you incur virtual dispatch whenever you use them.

The article is about doing safe manual memory management. That's something that's unique to Rust.

Post reply on HN