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

31–40 of 193 posts

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

#31

Post by kibwen »

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.

In nine months, Rust has gone from version 0.1 (its first public release) to version 0.4 (expected next week). Much of the work in that time has involved removing (!!!) features from the language and polishing what's left. Version 1.0 is anticipated in the first half of next year.

If you really feel the need to compare with Go, measure the time from Go's first public release (2009) to its first production release (2012).

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

#32

Post by nightski »

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.

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.

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

#33

Post by mbrubeck »

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.

Oh, come on. Rust started as an open-source project in 2010 (with the release of the preliminary design and OCaml compiler that Graydon had written as a hobby project). At that time, work started on the self-hosting compiler, leading to its initial 0.1 release eight months ago, and proceeding with releases every few months and steady progress toward the remaining goals on the 1.0 roadmap [1]. Just because Go was developed earlier doesn't mean that Rust isn't getting done. And it's not noticeably more complex than it was in the initial design; in some ways it's simpler.

(By contrast, Perl 6 has been in development for over a decade, with a half-dozen implementations in various stages of completion.)

[1] https://github.com/mozilla/rust/wiki/Note-development-roadma...

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

#34

Post by davidw »

nagnatron wrote: post #26
rokekr wrote: post #21

Earlier quoted context omitted.

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.

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

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

#35

Post by wmf »

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 know if this is a fair criticism. Rust has not been stuck in eternal development for many years like Perl 6. Rust is less mature than Go just because it started (in earnest) later and it's a little more ambitious. Go was immature not that long ago.

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

#36

Post by asdfs »

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.

The compiler is written in Rust, as is Mozilla's experimental browser engine called Servo.

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

#37

Post by kibwen »

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…

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.

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

#38

Post by scott_s »

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

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

#39

Post by bblum »

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…

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

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

#40

Post by eevee »

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

Post reply on HN