Why I think Rust is the "language of the future" for systems programming • Hacker News Board

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

#121

Post by pcwalton » Thu, Sep 27, 2012, 5:59 AM UTC

zurn wrote: post #116

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…

> programming in which abstractions must be zero-cost and control over the machine is crucial How well does Rust do in this zero (or low) cost department? In C++ STL there's the same goal, but it compiles to code very far from what you would write in assembly without abstractions. Eg. how are code compactness and data layout optimizations?

Not sure what you mean here. Rust tends to be pretty dependent on inlining optimizations, just as C++ is. As for code compactness, the way we do task failure leads to significant code bloat at the moment (though that's on track to be fixed, and the code is off to the side and not executed unless you actually fail). As for memory layout, the rules follow C; struct fields are laid out in the order you specify them in the code, and so on.

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

#122

Post by grey-area » Thu, Sep 27, 2012, 6:01 AM UTC

zxcdw wrote: post #85

tbrownaw wrote: post #66

Earlier quoted context omitted.

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.

...both of which are domain specific languages, or developed as such. I really think C++ is going to gnaw "market share" from C in any low-level domains and fight back Go and other competitors in high-level systems programming domains thanks to it's recent C++11 standard and upcoming standard library extensions which being the transition of making it much more on-par with other modern languages. Bjarne Stroustrup(the…

There are plenty of companies who have spent millions on developing their websites, written in a variety of the languages you list as 'toy' languages, or even PHP. Whether they would have been better to use other languages is impossible to say of course, but these languages are being used for significant projects. The use of the pejorative 'toy' is not very useful, and likely to evoke emotional reactions.

Go was inspired by a talk on the features of C++11 [1] - in despair at the addition of yet more features; the origins of the language and the philosophy behind it might make interesting reading if you use C++, because it was done directly in reaction to the (as they saw it) baroque edifice of C++.

Though I agree that people should not judge languages by popularity, novelty, or coolness (though it seems many people do), that doesn't mean you shouldn't be open to looking at new languages, if only to inform how you use your favourite one. Go for example has been inspired by the languages you deride, or their precursors (Python, Ruby etc), and in fact has taken much from them in syntax and in the popularity of closures etc.

I do agree with your other point though that this is an excellent area for Google to focus on, and something which will benefit a lot of domains which currently don't use scripting languages (systems programming, many large server systems, desktop apps, mobile apps).

[1] http://commandcenter.blogspot.co.uk/2012/06/less-is-exponent...

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

#123

Post by reinhardt » Thu, Sep 27, 2012, 6:43 AM UTC

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…

Would be interesting to read a comparison with D. And no, "obscure" is not a meaningful description when comparing it to a language still at v0.3.

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

#124

Post by zxcdw » Thu, Sep 27, 2012, 6:50 AM UTC

grey-area wrote: post #122

zxcdw wrote: post #85

Earlier quoted context omitted.

...both of which are domain specific languages, or developed as such. I really think C++ is going to gnaw "market share" from C in any low-level domains and fight back Go and other competitors in high-level systems programming domains thanks to it's recent C++11 standard and upcoming standard library extensions which being the transition of making it much more on-par with other modern languages. Bjarne Stroustrup(the…

There are plenty of companies who have spent millions on developing their websites, written in a variety of the languages you list as 'toy' languages, or even PHP. Whether they would have been better to use other languages is impossible to say of course, but these languages are being used for significant projects. The use of the pejorative 'toy' is not very useful, and likely to evoke emotional reactions. Go was insp…

I'm aware of what and why Go came to be, and I can easily relate to the reasons(I've read the blog post). I am by no means saying C or C++ as languages are perfect, nothing is. However, as I mentioned in my another reply to sanderdj, there's huge investment in effort for the abstractions the two languages build. It's very hard to tackle the problem of existing codebase for example, as that requires building stuff from ground up(that happens later on), or the fact that there are far more competent C or C++ programmers than there are Go or Rust programmers(and this isn't likely to change for the next 10-15 years or so, I'd bet), or the fact that there exists practically no libraries for these languages(ports are relatively fast though, few years max.), portability is a major concern too, tools too as well as language standard and educational resources(books, uni grade education, best practices over years, ...) won't exist for years...

So while I think that C and C++ will phase out eventually even in the domain of systems programming, I really don't see Go or Rust doing that for the foreseeable future, if ever. It would be really great to build trustworthy(non-leaky, efficient and secure) abstractions on top of languages like Rust and Go, but how reliable would it be? When would it be feasible? Who takes the first steps? When will the mainstream follow? Are these languages going to be relevant after 20 years?

Oh, and I'm not deriding other languages in their specific domains(I'm a Ruby fan, not so much into Python), but rather the fact that I've been under the impression that many people think that soon C and C++ will phase out and become obsolete(or that they have already done so), we go higher in abstractions, Python and Haskell are the future and computers are so fast that nobody has to care about optimizing their code. Then reality and post-PC era strikes back, battery life and software power-efficiency play higher role than ever...

My experience with Go and especially Rust is quite limited, but it would be really great if I could do my stuff(right now games and path tracing rendering, render times from 12 hours upwards) in either them instead of C++. I really like the ideas behind the languages and they fit my core domain just as well as C and C++ do. Though the thing is, there are no tools. No libraries. No books. Nothing. There's simply no way to jump over, even if the possible performance penalty would be tolerable. And this isn't likely to be changing much for the better for upcoming years, if even then. Perhaps when the languages get an actual standard... It's sad in a way even, but can't escape the facts which make them not viable for many domains.

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

#125

Post by pcwalton » Thu, Sep 27, 2012, 6:53 AM UTC

zxcdw wrote: post #120

sanderjd wrote: post #110

Earlier quoted context omitted.

You seem to be using a definition of "declarative" that I'm unfamiliar with. The functional languages you target in the second to last paragraph are very different from the more imperative languages in the final paragraph, and I wouldn't consider either group to be "declarative". I'm left wondering what concepts you're attempting to criticize. Having said all that, yes, I believe major commercial projects are started…

Functional languages are declarative. The point is that there are two kinds of languages; languages which people bitch about and languages which nobody uses. Sure, I can mention tons of commercial projects which are started in those languages, and which use them at least partly(for example Python for scripting interface). However, I really doubt none of the languages provide a solid ground to build upon(even if we we…

"How many years will it take to get a reliable Go or Rust support for programming a vendor-independent GPU? What's the overhead compared to say C or C++?"

We're already using Rust for OpenGL ES 2.0-based graphics programming.

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

#126

Post by pcwalton » Thu, Sep 27, 2012, 6:55 AM UTC

ww520 wrote: post #102

Rust looks very interesting. I downloaded it and tried it out on Windows but got "libgcc dll missing" error. They really need to statically link in the MingGW runtime to make it easier to run.

There is a bug on doing that, but keep in mind that bundling libgcc would only make Rust error out with a more informative error. Because Rust uses the system linker, you need MinGW installed to use Rust.

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

#127

Post by phaemon » Thu, Sep 27, 2012, 7:11 AM UTC

eevee wrote: post #81

kibwen wrote: post #62

Earlier quoted context omitted.

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

Apparently it won't work yet! Tragic. In the meantime, I can deliberate on whether or not to call it FOXDIE.

Surely "Pyrite"?

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

#128

Post by zxcdw » Thu, Sep 27, 2012, 7:16 AM UTC

pcwalton wrote: post #125

zxcdw wrote: post #120

Earlier quoted context omitted.

Functional languages are declarative. The point is that there are two kinds of languages; languages which people bitch about and languages which nobody uses. Sure, I can mention tons of commercial projects which are started in those languages, and which use them at least partly(for example Python for scripting interface). However, I really doubt none of the languages provide a solid ground to build upon(even if we we…

"How many years will it take to get a reliable Go or Rust support for programming a vendor-independent GPU? What's the overhead compared to say C or C++?" We're already using Rust for OpenGL ES 2.0-based graphics programming.

I didn't expect that, I am almost surprised! Though, I was more after using Rust or Go for general purpose GPU computing via OpenCL for example. There seems to be some form of project for binding, but I certainly would not put my money on some random person doing the bindings. Very experimental and unreliable stuff.

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

#129

Post by malkia » Thu, Sep 27, 2012, 7:22 AM UTC

kibwen wrote: post #62

eevee wrote: post #57

Earlier quoted context omitted.

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

Prusty comes closes to "Prusti" which is the bulgarian word for "fingers", and "prust" meaning "finger", but also "soil"

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

#130

Post by djhworld » Thu, Sep 27, 2012, 7:31 AM UTC

zheng wrote: post #7

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

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

Go has first class functions yes, but without the support for generics/parametric polymorphism, you can't write "higher order functions" for polymorphic functional constructs like map/filter/reduce etc.