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

41–50 of 193 posts

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

#41

Post by shanemhansen »

pcwalton wrote: post #8
kibwen wrote: post #6

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

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

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

#42

Post by mburns »

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.

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

#43

Post by kibwen »

mappu wrote: post #27

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

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.

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

#44

Post by bblum »

jallmann wrote: post #19

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

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, 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.

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

#45

Post by bblum »

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.

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

#46

Post by _delirium »

scott_s wrote: post #38
james4k wrote: post #30

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

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/or generate code to implement their functionality internally, rather than linking the library implementation.

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

#47

Post by neilk »

kibwen wrote: post #17
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.

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 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.

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

#48

Post by cdavid »

eevee wrote: post #40
kibwen wrote: post #6

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

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

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

#49

Post by zxcdw »

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.

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.

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

#50

Post by kibwen »

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…

FWIW, Rust's arrays and structs are also laid out in memory exactly as C's are.
Post reply on HN