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

111–120 of 193 posts

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

#111

Post by scott_s »

cmccabe wrote: post #100
scott_s wrote: post #38

Earlier quoted context omitted.

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…

A lot of the productivity gain in higher-level languages comes from not having to manage memory. Having three different incompatible, differently allocated pointer types to fool around with slows you down. The creators of Rust are hoping that the speedup from not having to do global garbage collection in most scenarios will balance out the loss of productivity. Personally, I'm skeptical. Azul showed us that pauseless…

Some tasks - such as implementing kernels - are poorly suited for garbage collection. And while there do exist garbage collectors that can be used in hard real-time scenarios (http://queue.acm.org/detail.cfm?id=1217268), that's not the norm.

I think there will always be a place, at the lowest levels, for manual memory management. Providing abstractions to make that as safe and manageable as possible is a Good Thing.

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

#112

Post by jksmith »

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…

Simplicity is absolutely the most crucial aspect of a language used for successful commercial application in my space (15-30 mil annual). That's what I like about Go. Don't know much about Rust, but if it's being designed by a small group of engineers who think oop is still awesome, then successful commercial software developed in Rust will be just as costly to maintain as the 500k to 5 mil line codebases I run across today, written in currently available languages.

Speaking in general:

You get all this wonderful language functionality, and I promise you that you will write some shitty code at some point just to keep up with the daily pressures presented by a successful software package (clients screaming, salespeople breathing down your neck, etc), I don't care how good of an engineer you think you are. What's really funny is that, because everything has gotten so much more complicated (dev tools, business, cost of bugs going up, how to make money with software, whatever), the successful software I work on today is not making any more money than the successful software I worked on back in the late 80's running under DOS. Back then, the oop free tools and the target os were simple enough that we really could become SME's on our domains as well as on the dev tools we used to write code for those domains.

C# and java are definitely not the solution for new applications which are expected to generate revenue for the next 10 years. If Rust is just trying to be smarter at what these languages already do, I'm not interested. Something has got to come along which simplifies development, especially concurrency, and allows programmers of varying skill levels to write productive code in. Then after 5 mil loc, programmers coming and going on a project, an app doesn't end up looking like a fragile mess.

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

#114

Post by zaphar »

tedunangst wrote: post #86
kibwen wrote: post #76

Earlier quoted context omitted.

Rob Pike, on justifying the development of Go: "today's server programs comprise tens of millions of lines of code, are worked on by hundreds or even thousands of programmers, and are updated literally every day. To make matters worse, build times, even on large compilation clusters, have stretched to many minutes, even hours." http://splashcon.org/2012/program/404

99% sure that remark is in regard to C++. If it's about java, then it's just not true...

You've obviously never compiled java at google :-)

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

#115

Post by pcwalton »

jksmith wrote: post #112
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…

Simplicity is absolutely the most crucial aspect of a language used for successful commercial application in my space (15-30 mil annual). That's what I like about Go. Don't know much about Rust, but if it's being designed by a small group of engineers who think oop is still awesome, then successful commercial software developed in Rust will be just as costly to maintain as the 500k to 5 mil line codebases I run acros…

Rust is not particularly object-oriented; idiomatic Rust code leans more toward the functional style as opposed to the OO style.

The language is designed to make it harder to write buggy code at the cost of some amount of language complexity. Whether this is an acceptable tradeoff will depend on your particular situation.

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

#116

Post by zurn »

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…

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

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

#117

Post by [deleted] »

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…

[deleted]

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

#118

Post by zobzu »

eholk wrote: post #77
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.

It's interesting that you mention Singularity, as it turns out that Singularity has been a major influence on Rust. For example, the current communication is very similar to the channel contracts used in Singularity.

Well I'm a big fan of many concepts of Singularity. And I like rust. I guess that's no coincidence ;-)

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

#119

Post by zurn »

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…

> The elephant in the room is that go does have garbage collection, and that ain't free.

Since HN is Lisp country, it has to be said that having GC isn't an "elephant in the room" - though a slow GC implementation may be.

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

#120

Post by zxcdw »

sanderjd wrote: post #110
zxcdw wrote: post #49

Earlier quoted context omitted.

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…

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 weren't talking about systems programming and it's future). Consider C and C++ for example; in what language is the OS you are using written in? The compiler it's compiled with? The libraries you use? The web browser? The JavaScript interpreter? You get the point. The fundamental systems we use are built upon these two languages, and I think it's a big problem people would want to address(myself included), because these languages are nowhere near perfect. There just aren't better alternatives for that domain, considering:

1) existing codebase 2) libraries 3) tools 4) efficiency 5) portability 6) programmer availability, resources and education 7) language reliability and future proofness(e.g. backwards compatibility, vendor and thus platform independence).

These are real problems when it comes to building reliable abstractions(that's the whole essence of systems programming, isn't it?), and thus far C and C++ have been the only languages which have been able to provide all of those the best.

When it comes to the future of computing from a hardware level, things may(or may not) seem a bit better; for example utilizing GPUs for general computing, using low-power ARM/x86 cores for parallelism. There are foundations for these things in C(and now C++ too) and libraries to help programming these things. 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++? The alleviating thing here is that GPUs and ARM cores aren't CISC machines so compilers and thus software is highly responsible for the performance, so with a good compiler you can get away with using less efficient implementation language, and get gradual improvements too.

Post reply on HN