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

21–30 of 193 posts

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

#21

Post by rokekr »

brson wrote: post #16
Calamitous wrote: post #11

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.

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…

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.

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

#22

Post by erichocean »

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.

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

#23

Post by Lewisham »

mtgx wrote: post #14
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.

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.

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.

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

#24

Post by stcredzero »

mtgx wrote: post #14
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.

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.

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.

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

#26

Post by nagnatron »

rokekr wrote: post #21
brson wrote: post #16

Earlier quoted context omitted.

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…

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.

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.

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

#27

Post by mappu »

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)

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

#28

Post by pjmlp »

rokekr wrote: post #21
brson wrote: post #16

Earlier quoted context omitted.

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…

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.

Ada is also in production for a few decades now.

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

#29

Post by zobzu »

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.

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

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

#30

Post by james4k »

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

Post reply on HN