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

61–70 of 193 posts

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

#61

Post by pcwalton »

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

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

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

#62

Post by kibwen »

eevee wrote: post #57
cdavid wrote: post #48

Earlier quoted context omitted.

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.

"I haven't actually tried this"

Please remedy this immediately. I'll even provide a highly-imaginative name: "Prusty".

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

#63

Post by davidw »

mbrubeck wrote: post #53
davidw wrote: post #34

Earlier quoted context omitted.

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

Fair enough. Like I said, it was just an impression; a vague feeling, so I'll be curious to see what they come up with when it comes out.

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

#64

Post by megaman821 »

tptacek wrote: post #59
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?

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

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

#65

Post by brson »

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

This is not quite possible yet, but will be at some point.

Rust does currently depend on a language runtime which expects to control the execution of all Rust code (in particular managing the task scheduler), and the runtime does not have an embedding story yet. Even with an embeddable runtime though, the process would be more involved than loading a library through `dlopen` and executing a function.

As part of the effort to rewrite the remaining bits of C++ runtime code in Rust (almost all of Rust is written in Rust), there are further plans to make Rust code runnable without an underlying runtime and without split stacks. After that it will be feasible to write code in Rust and just call it like any C function.

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

#66

Post by tbrownaw »

zxcdw wrote: post #49
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…

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.

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

#68

Post by cpeterso »

kibwen wrote: post #4
adambratt wrote: post #2

Good article! Sorry to be nitpicky but the font size/line-height makes it really hard to read. Perhaps make both a bit bigger for optimal reading?

I just found this Firefox add-on today and I'm completely in love: https://addons.mozilla.org/en-US/firefox/addon/clearly/ Here's what appears to be the Chrome version: https://chrome.google.com/webstore/detail/iooicodkiihhpojmme... Makes it ridiculously easier to read basically everything on the web.

I like the Readability add-on and bookmarklet:

http://www.readability.com/apps

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

#69

Post by haberman »

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.

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

#70

Post by ww520 »

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.

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