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

#91

Post by rntz » Thu, Sep 27, 2012, 12:41 AM UTC

4ad wrote: post #87

mbrubeck wrote: post #33

Earlier quoted context omitted.

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

When Go was announced it had a spec, a significantly larger standard library than Rust, two compilers (and a parser in the standard library), and much, much better documentation. While the language had changed until the Go 1 release from a few months ago, it had changed less in two years than Rust changed in a few months. Go also introduced a tool that would automatically rewrite your old code to adapt to the new lan…

All that means is that Go was announced much later in the development process than Rust was. If Rust had been developed like Go, it wouldn't have been made public yet. But that's not the way Mozilla does things.

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

#92

Post by cmccabe » Thu, Sep 27, 2012, 12:54 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…

Rust has three different ways of allocating memory. And you can't pass things allocated one way to functions that expect something allocated the other way.

A Python replacement, this ain't. More like C++ on quaaludes.

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

#93

Post by pcwalton » Thu, Sep 27, 2012, 1:00 AM UTC

cmccabe wrote: post #92

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…

Rust has three different ways of allocating memory. And you can't pass things allocated one way to functions that expect something allocated the other way. A Python replacement, this ain't. More like C++ on quaaludes.

No, Rust has two ways of allocating memory (on the task heap or on the exchange heap), and most functions take borrowed pointers, which accept both kinds of memory.

(Edit, re below reply: It depends how you define "allocation"; it's either two or three. I wasn't considering the stack as allocation, but you're right that Rust takes the traditional stack/heap distinction and expands it to stack/exchange heap/task heap. We should update the tutorial to make it clear that borrowed pointers work for the stack as well as both heaps.)

I agree that the language is not designed to be a Python replacement, however. No language is suitable for every task.

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

#94

Post by bryanlarsen » Thu, Sep 27, 2012, 1:08 AM UTC

EternalFury wrote: post #84

Another language that adopts a different syntax for the sake of adopting a different syntax. If you are going to ask me to adopt a different syntax, you'd better have a good reason for it, because I can do everything I need to do with the languages I already have.

You can do more in assembly language than you can in any other language. That doesn't make it a good language to program in except in very special cases.

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

#95

Post by cmccabe » Thu, Sep 27, 2012, 1:15 AM UTC

megaman821 wrote: post #64

tptacek wrote: post #59

Earlier quoted context omitted.

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.

Go is not a conservative language. A conservative language would be something like D, which is mostly a clone of C++ with a few extra features tossed in.

Go is a highly opinionated language with at least three big new ideas:

* goroutines for concurrency ("Don't communicate by sharing memory; share memory by communicating")

* a new type system which is based on structural subtyping (some people have called this static duck typing).

* use of return codes rather than exceptions for routine error conditions ("We don't want to encourage the conflation of errors and exceptions that occur in languages such as Java." See https://plus.google.com/116810148281701144465/posts/iqAiKAwP... )

Just those three things are enough to make Go code look very from what came before. And I could go on-- things like the way go does namespaces and scoping are also very different.

It's a different philosophy that leads to much better code, in my opinion at least, not dozens of gee-whiz features, which seems to be what the languages of the 1990s gave us and are continuing to give us.

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

#96

Post by bzbarsky » Thu, Sep 27, 2012, 1:15 AM UTC

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…

Hedge fund trading code may not have "2030 and beyond" lifetime, but it's certainly something major companies are investing a good bit of money into. Also tends to be in OCaml...

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

#97

Post by cmccabe » Thu, Sep 27, 2012, 1:18 AM UTC

pcwalton wrote: post #93

cmccabe wrote: post #92

Earlier quoted context omitted.

Rust has three different ways of allocating memory. And you can't pass things allocated one way to functions that expect something allocated the other way. A Python replacement, this ain't. More like C++ on quaaludes.

No, Rust has two ways of allocating memory (on the task heap or on the exchange heap), and most functions take borrowed pointers, which accept both kinds of memory. (Edit, re below reply: It depends how you define "allocation"; it's either two or three. I wasn't considering the stack as allocation, but you're right that Rust takes the traditional stack/heap distinction and expands it to stack/exchange heap/task heap.…

from http://dl.rust-lang.org/doc/tutorial.html

"7.3 What to be aware of

Rust has three "realms" in which objects can be allocated: the stack, the local heap, and the exchange heap. These realms have corresponding pointer types: the borrowed pointer (&T), the shared box (@T), and the unique box (~T). These three sigils will appear repeatedly as we explore the language. Learning the appropriate role of each is key to using Rust effectively."

It's 3 different types, not 2.

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

#98

Post by cmccabe » Thu, Sep 27, 2012, 1:22 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…

Yes, truly the only thing holding C++ back has been lack of features. Have a link: http://yosefk.com/c++fqa/

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

#99

Post by ww520 » Thu, Sep 27, 2012, 1:22 AM UTC

kibwen wrote: post #76

ww520 wrote: post #70

Earlier quoted context omitted.

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

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

He never specifically said it's C++ nor Java. I think he's talking about C++. C++'s slow compile problem has to do with the repeated inclusion of header files for every source file, which can become a FileNum^2 recompilation problem. Though pre-compiled header files and refactoring into pre-built libraries should reduce the compile time. Java simply does not have the slow compile problem due to its simple package/class per dir/file, where a compiled class won't be recompiled again.

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

#100

Post by cmccabe » Thu, Sep 27, 2012, 1:29 AM UTC

scott_s wrote: post #38

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…

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 GC was possible, even for Java. Android and .NET showed us that even without pauseless GC, the performance of GC'ed languages was adequate to build attractive user interfaecs. A lot of Rust's design choices mean that it's not really suitable as a web development or scripting language, and those two communities have shown themselves the most receptive to new languages.

Mozilla has tried to rewrite their core product in a different language before. Look up "Javagator." It did not end well. But, who knows. Maybe this time really will be different.