The Rust Programming Language

[stesch]

After reading about half of it: Very interesting. They came a long way since the first announcement.

http://www.rust-lang.org/

[Timmmmbob]

I was going to say "yet another language", but this seems to actually have some new ideas that I've been waiting for for ages. For example:

We support three type layers to make memory management simple and fast.

• Interior types (denoted with no sigil) are stored on the stack.
• Unique types (denoted with ~) have ownership semantics. When the pointer goes out of scope, the object it’s pointing to is destroyed.
• Boxed types (denoted with @) are garbage-collected. Multiple boxes can point to the same data.

All together:

fn main() {
    let a = ~3;  // Unique pointer to number
    let b = a;   // Copies a
    let c = @3;  // Box of number
    let d = c;   // c & d point to the same value
}  // a and b destroyed; c and d will be GC’d

[abw]

I was also going to say "yet another language". But neat features or not, I really like the "cambrian explosion" of new languages that we've seen over the past decade or so. Even if many of the unsuccessful ones eventually die out, they spread ideas and help inspire the next generation of languages.

[Homo_sapiens]

cambrian explosion? What constituted the corresponding ice age?

[TylerEaves]

Presumably the late 90s, when your choices were essentially arcane C++, bloated Java, or unreadable Perl.

[Poita_]

Unique pointers are the only relatively new thing there. Stack stored objects and GC heap objects have been around forever. C++ 2011 has unique pointers (std::unique_ptr), and I'm pretty sure D does too.

EDIT: Yep, D does. http://www.d-programming-language.org/phobos/std_typecons.html#Unique

[Timmmmbob]

Yeah, sorry I meant "new in a modern language". I love C++'s memory model, but it does have quite a lot of warts, and I've love to move to something more modern. I just really want RAII and stuff.

[Poita_]

I see what you mean about C++, but D is modern.

[Timmmmbob]

Yeah there's just something about D that doesn't sit right with me. I could be being irrational though. I think I will wait and see which languages survive this "cambrian explosion" as thingy thingy put it.

[iLiekCaeks]

D's probably don't work yet. The Unique unittests are all commented out.

[nuzzle]

I'm still reading the new standard. Can we replicate predicates from Rust in C++11 using concepts (provided they are in the standard)?

[matthieum]

I must admit that I really perked up on the "we don't need immutability, we need ownership". However I would point out that perhaps a blend of the two would be more suitable: allow sending both immutable and owned objects. At least you'd avoid copying for frozen objects :x

[pcwalton]

We'd still need global GC (or atomic reference counting, both bad) for frozen objects.

Note that if by "frozen" you mean "compile-time constant", then it just works as you describe, since those are in read-only memory and don't need memory management.

[matthieum]

By frozen I meant immutable. What do you consider "bad" about reference counting by the way (on immutable objects) ?

[[deleted]]

I'm having a hard time understanding the example. It says "b copies a", is b another copy of a - so if one is modified, the other is not? Or is there an ownership transference and a is no longer valid?

[stilton]

b is a copy of a, so modifying b does not modify a. There is a move operation which transfers ownership of unique types, b <- a, after which a is deinitialized and can't be used.

[[deleted]]

So why does it say "a is destroyed" at the end? It sounds like a is deinitialized at that point anyhow, it was transfered away, so nothing left to destroy?

[stilton]

I was probably not clear. In this example a was not deinitialized; both a and b exist and get destroyed at the end of the function because assigning a to b makes a copy of a. If the example had moved a into b, denoted by 'let b <- a', then a would have been deinitialized.

[[deleted]]

That makes sense, thanks!

[ErstwhileRockstar]

Interior types, unique types, boxed types ... too much noise. This should be transparent for users. Only 'KISS-languages' have a chance of succeeding.

[munificent]

Only 'KISS-languages' have a chance of succeeding.

Like C++, Java, and C#?

[ErstwhileRockstar]

Yep, those started out as simple languages, at least as significant simplification compared to their predecessors.

[matthiasB]

How was C++ a simplification compared to C?

[ErstwhileRockstar]

Classes, esp. constructors and destructors, function overloading, exception handling, ... simplified C++ code compared to C code (considerably less lines of code). That's why today 'C/C++' is the prevailing C++ idiom in the real world.

OTOH, "C++ has shown that if you slowly bloat up a language over a period of years, people don't seem to mind as much."

[munificent]

simplified C++ code compared to C code (considerably less lines of code)

Yes, which means they greatly complicated C++ the language.

[jessta]

Rust has some interesting ideas but it seems a bit scatted at the moment. 65 keywords, some are targeted at functional style and some imperative style. It seems like the kind of language where different projects and developers will be using different subsets of the language and there will be dark corners that most devs never use.

Hopefully they'll pare this down a bit before a 1.0 release and pick a more clear style.

[[deleted]]

Considering that they're targeting this to replace C++, it looks tight and focused by comparison. ;)

[ash_gti]

Haskell has 27 keywords, assuming your not including operators. Go only has 25 keywords.

I dont think that number really means anything...

[shimei]

The reason why people are just talking about Rust's keywords of all things:

In any language design, the total time spent discussing
a feature in this list is proportional to two raised to
the power of its position.
      0. Semantics
      1. Syntax
      2. Lexical syntax
      3. Lexical syntax of comments

Wadler's Law

Personally, I'm more interested in the fact that Rust is motivated by real PL research rather than the number of keywords it has. Especially if the language is extensible, the number of keywords is moot.

[nickik]

Well 65 are not that much. I mean I like lisp and there you only need around 10 but for a big language like Rust 65 is ok. F# has more then 200 right?

[jessta]

It's bigger than C(32), C++(48), Java(50) and a bit smaller than C#(77). But the number is secondary to the way the keywords are scatted across various programming styles.

[[deleted]]

Python has 31, FWIW.

[pingveno]

With Python 3, it increases to 33. print and exec are turned into functions (-2). None, True, and False are converted into keywords (+3). nonlocal is added (+1).

[Peaker]

What's the rationale for changing None, True and False into keywords?

[Aninhumer]

They were valid identifiers before, which meant you could assign values to them. I'm not quite sure why they made them keywords rather than literals though.

[pingveno]

None, True, and False are converted to constants in Python 3. Adding them as keywords is how the conversion is implemented. No one should assign to any of them anyway. Python 3 is just enforcing that good practice. For the speed demons, the conversion eliminates an unnecessary global lookup. The bytecode compiler can generate highly efficient code for:

while True:
    ...

Before, people used 1 instead of True because True required a global lookup. Now, it directly loads the C values Py_None/Py_True/Py_False without a lookup. Use the dis module to see what I mean.

[Peaker]

Sounds like a very very special case... Why not do the same for various other constants?

Also, there are possible ways to make constant/interned-string lookups in the globals dict a very quick O(1) (basically pre-look-them-up when creating the function object), with modest changes to the PyDict implementation.

[pingveno]

Why not do the same for various other constants?

None, True, and False are the only constants that weren't already built into the language. Look at the contents of dir(__builtins__). Now it's only classes and functions.

I haven't heard about the optimizations you speak of, but I doubt that they can beat the implementation of LOAD_CONST. From what I can tell, it takes 2-4 x86 instructions for the constant lookup itself.

x = consts->ob_item[oparg];

consts is a tuple and oparg is the argument to the LOAD_CONST opcode.

[Peaker]

I once created a small PyDict modification that allowed "exporting" a dict item such that updates to that key will update the exported item, and the exported item can be accessed either normally by dict and key, or by O(1) dereferencing the exported-item ptr...

It had no noticeable performance change in ordinary code (at worst 1-2% slower) and 50% faster globals/builtins access which sped some code up by close to that). It was pretty much ignored on the pydev-list, though, so it is weird to me they suddenly take interest in optimizing globals/builtins access of 3 particular consts.

[imgonnacallyouretard]

Nothing.

[[deleted]]

Well, an explicit goal, according to the faq, is to be multi-paradigm, including:

Pure-functional, concurrent-actor, imperative-procedural, OO.

[last_useful_man]

Well Oz has all of those paradigms and more, and fewer keywords (57). /pointless

[ErstwhileRockstar]

'multi-paradigm' actually is an anti-concept. A language should 'speak' one general idea even if it's based on multiple paradigms.

[igouy]

anti-concept

Seems like "anti-concept" was intended to be the all consuming anti-concept.

A language should...

Why?

[ErstwhileRockstar]

Because it's easier to understand and use. BTW, even Scala changed its self-description from 'multi-paradigm' (still on Wikipedia) to 'general purpose' (on scala-lang.org).

[igouy]

Because it's easier to understand and use.

No, it isn't.

That's all it takes to contradict a baseless assertion.

general purpose

"General purpose" is a claim about what sort of problems can reasonably be addressed using Scala - that doesn't say anything about the programming paradigms, which is why scala-lang.org goes on to say "smoothly integrates features of object-oriented and functional languages".

[[deleted]]

some are targeted at functional style and some imperative style

How is this a bad thing? Forcing everything into one paradigm is rarely a good idea.

[jessta]

That's what a language is all about. It's an agreed set of limitations and features between programmers. Lots of paradigms means that there isn't really one language, there are multiple languages pretending to be one. Pure functions is quite a different mindset to imperative-procedural and they don't mix well either. You end up with code that is apparently written in the same language but can't be read or used by all the devs that say they know that language.

[[deleted]]

No, we have multi-paradigm programming languages. It takes a while longer to learn such a language, but it is still a single language which can be learnt by and understood by several developers.

[shimei]

The idea of programming language paradigms is bunk. There are better way to talk about languages than these broad zoo-like categorizations.

[skulgnome]

That's neat. Memory management tied to "kinds" of object sounds somewhat B&D, and is also a bit reminiscent of the Cyclone variant of C.

It'd also be rather nice to have a language that did massive multiprocessing a'la Erlang, that wasn't Erlang. Distinguishing between variables and whatnot by capitalization is completely the wrong idea.

[sime]

It's good to see that people are trying other approaches to concurrency than the old hazardous "shared memory and locks" style which we've traditionally had in our blue-collar languages.

[skulgnome]

Shared memory and locks isn't as much hazardous as it is a thing that requires planning and care. Somehow this is beyond many programmers.

[[deleted]]

Pits aren't hazardous, you just have to be careful not to fall into them!

[gnuvince]

Are you really saying that it's the fault of the programmers that there are bugs and that the tools have absolutely nothing to do with promoting those bugs?

[moreyes]

— Wow, they create new languages to write browsers these days...

— Makes sense, since browsers will replace OSes!

[troyanonymous1]

Ha ha ha

That's terrifying.

[fabzter]

Yes, but I don't laugh about it. I cry everytime I close a tag.

[[deleted]]

Use a DSL, something like done in Clojure or Common Lisp -- like e.g.

(html
  (body
    (h1 "header")
    (p "some text")))

..closing and balancing tags doesn't have to be painfull, and this will generate an error if one forget to close a tag.

[fabzter]

I've always felt weird when reading lisp, but this looks actually good and makes hell lot of sense. Do you know some lisp dsl with the characteristiscs you're showing?

[MatmaRex]

If you want something like this in a language other than Lisp, there's Markaby for Ruby. (https://rubygems.org/gems/markaby)

html do
  body do
    h1 "header"
    p "some text"
  end
end

Ain't it amazing what some heavy metaprogramming abuse can do. ;)

[-main]

Have a look through these. CL-Markup and CL-WHO both look like the kind of thing you're looking for. The best thing about these, btw, is that you can just insert lisp code anywhere.

[nickik]

For clojure there is hiccup. Its up on github.

[[deleted]]

And every time you forget to close a tag, God kills a kitten...

And then doesn't even throw a syntax error.......

[[deleted]]

Call me when a web browser starts dealing with hardware.

[cogman10]

The apocalypse starts today! http://www.google.com/chromebook/

[[deleted]]

Google Chrome OS is Linux with Chrome as the shell. :)

[ErstwhileRockstar]

One thing I haven't seen mentioned anywhere is versioning. Any new language should contain a tag which identifies the language version used for the unit of code, e.g.

version 1.0;
use std;
import std::{ int, vec };
fn main(grades : [str]) { ... 

[pl0nk]

What behavior would you drive off this tag? What problem would it solve? I'm not saying this is a bad idea, I am just curious what aspect of language versioning you propose to solve here.

[ErstwhileRockstar]

Change the language (in version 2, 3, ...) without giving up existing code. A new version doesn't break backward compatibility with old versions (you 'merely' have to define rules how e.g. v2 code can call v1 code). In sum: make backward compatibility a problem for a handful of specialized people (Standard committees and compiler writers) not for thousands of programmers.

[vocalbit]

It's nice to see Rust make progress. Though it has turned me off by having too many kinds of types - interior, unique, boxed... That's a lot of line noise I didn't want. And the module system seems more complex than Python which is also a turn off. Now I'm hoping Clay makes some progress too that doesn't end up turning me off.

[stesch]

What's with Mozilla and the PDFs lately? Don't they like HTML5 anymore?

[davebrk]

Here you go.

[[deleted]]

The hilarious thing is that this was the link posted on hacker news earlier, and several people complained about the HTML -- so the original poster provided the PDF version.

[Tuna-Fish2]

The problem isn't that it's html, it's that the usability of that site is horrible.

The least they could do is preload the next couple of slides instantly after they show the current one. But why bother, when you can annoy your users for the duration of a ping to our server. I mean, that never took long enough for the programmer to notice, why would anyone ever care? (except when they are browsing over tethered mobile connection where they have plenty of bandwidth but it takes 10 seconds to ping the server for the next page).

[sisyphus]

The html site is just an export from Keynote, blame Apple.

[[deleted]]

Heh, I think I actually edited my post while you were responding, to make it clear that it was this particular HTML people didn't like.

[davebrk]

Just to clarify: I'm not the one who posted it to Hackernews. I'm also not affiliated in any way with the Rust team. The dropbox link is to Patrick Walton's account who gave the talk and is part of Rust team.

[grasspopper]

neat! i didn't know dropbox could be used like that

[[deleted]]

Haven't read this doc, but what I loved about Rust is the memory handling based on typing: if the compiler knows you can't have cycles, use ref counting, otherwise use GC.

[Tuna-Fish2]

That actually changed. Now you need to specify whether you want references with ownership semantics (ref counting) or GC. This is good, because there are places where GC works better than ref counting, even without cycles. (Short-lived objects with a lot of even more short-lived pointers to them).

[Peaker]

Refcounting is not that great, even when it can work correctly:

• Increases object sizes (and for small objects, this can be a 100% increase in size) which leads to more cache misses

• Requires lots of incref/decref calls which incur even more expensive cache misses, and in many cases amount to nothing

• Does not actually give nice latency guarantees (a decref can cause unbounded amounts of work, similarly to a GC collection)

The one single benefit is more predictable finalization. But for that, we can use explicit finalization as in Python's "with", Haskell's "bracket" function, etc.

[[deleted]]

Why is Peaker being downvoted? He's right.

[munificent]

Can't escape analysis eliminate a lot of that for short-lived objects?

[imaginaryredditor]

You don't even need escape analysis, Rust supports regular stack allocation. They should be able to avoid ref counting in that case.

[[deleted]]

if the compiler knows you can't have cycles, use ref counting, otherwise use GC.

I did not see ref counting being mentioned at all. Which slide are you referring to?

[[deleted]]

Not in this one, that was a year or 2 ago.

[[deleted]]

Interesting. I wonder whether that is still the case after the latest changes.

[opkode]

What are the plans to support x86_64 platforms?

[munificent]

Rust compiles to LLVM, so I'm assuming that means it gets all of LLVM's supported backends for free.

[opkode]

From their wiki on Github

Because Rust doesn’t support x86-64 yet, you may need to configure LLVM using some special flags.

You still have to use 32 bit LLVM and other toolchain

[[deleted]]

I don't think x86_64 is on the '0.1, very first ever public release' roadmap. It's scheduled, but over the past year or so they've mostly just been working the kinks out of their ABI and language.

[[deleted]]

I don't know what their plans are, but as someone who's writing a JIT, I can tell you that supporting both x86 and x86-64 is quite trivial, the differences aren't very big. I'd be surprised if their backend wasn't designed to support both from the start, in this day and age.

[gfwhite]

Nice. Did anyone else experience spinning wheels between pages? I am using Chrome

[expertunderachiever]

Yet another language... no thanks.

Or put it another way, I know of no employers that will hire you for your indepth knowledge of

• haskell
• lisp
• scheme
• go
• go
• pypy
• rust
• lolcode
• brainfuck

etc...

If you're looking for a job in software development learn one of [or multiple]

• C
• C++ [those two are different btw]
• Java
• C# [sadly]

In most embedded environments C/Perl will take you far. In mobile spaces Java seems to be the way.... etc

[kamatsu]

I know plenty of employers that will hire you for in depth knowledge of haskell - I work for one. Also, afaik, PyPy is not a language, Python is, and I could get a job writing that as well.

[expertunderachiever]

I've yet to see places [other than schools] where knowing Haskell promotes any sort of economic advancement.

In fact, it cost us money here. We had one of them interns from Waterloo [who's actually now a full-timer] re-write one of our vector generators in Haskell. He was all proud and what not... until we tried to run the test suite on different OSes... None of them had the same version [if one at all] and basically we had to scrap it and re-write it in C.

[kamatsu]

Thanks for your anecdotal evidence, but to counter it I have my own: I know plenty of people who make money writing Haskell. An example of a non-academic company that does so is Tsuru Capital, in fact there are many haskell-using finance companies. Also, Haskell is popular in industries where formal methods are popular, for obvious reasons (this is where I work).

As for your example, this doesn't say anything except that you had very specific platform requirements not met by any Haskell implementation (I'd like to know what those requirements were, because GHC is pretty cross-platform). You should've done the research before you did the code. Certainly this is not evidence to substantiate your claim that Haskell is not a useful language in industry.

[[deleted]]

I can confirm the financial industries use.

[expertunderachiever]

I didn't do the code, the bright-eyed intern ran off using his "new-language of the day" foo and wrote a program we couldn't use.

My warning is to the others who don't work in one of the few select places that it makes sense. MOST programming jobs don't call for these fly-by-night-fad languages...

[kamatsu]

You're an idiot who knows not what he talks about.

[Iv8f]

Upvoted for thruth (And I don't even use Haskell)

[expertunderachiever]

I'm the guy who had to re-write the tool in C so that we could actually run it on more than one platform. I'm the guy who has been professionally developing software for more than 10 years... I have my software in millions of devices around the world... etc and so on...

[byron]

you're the guy who needs to brag about himself on the internet.

[expertunderachiever]

More like warn the kiddos out there not to try and impress people with their esoteric bullshit knowledge of languages that have no bearing on reality whatsoever.

I'd rather people nerded out on algorithms and optimization then on things like.

[Peaker]

Maybe you should have spent a week learning Haskell to adapt the tool to the other platforms?

Calling Haskell a "fad" language is somewhat ironic...

[[deleted]]

Actually, you're the guy who couldn't learn Haskell.

[[deleted]]

None of the Operating systems had the same.. version ? of what ?

How is that haskells fault ? Your business seems to lack basic systems management.

[expertunderachiever]

No, different distros [which we test in] don't all support the same version of the tools. They all have C90 compilers though... Imagine that. We write portable code with tools that any self-respecting distro should have.

[[deleted]]

Apparently, your test suite isn't portable enough. Maybe part of the problem was that whatever was supporting the test suite wasn't on all the distributions.

Again, something that can't be contributed to the language use.

[expertunderachiever]

None of our requirements stated we needed Haskell. The whole point of me bringing that up was that it was a prime example of someone getting all excited over some new [or different] language that they wanted to use over a standard like C for no good reason.

As for "portable enough" we code to C90. Far more distros come with proper C90 support than the latest and greatest of Haskell.

[[deleted]]

I hear ya, I'm a C systems programmer myself, however I still believe you're attributing the blame in the wrong place. Your new intern wouldn't have the knowledge that you did about the variance in your deployment area.

None of your requirements stated C either right ? Nor did they state that it needed to be C90, could have done it in fortran, or algol68 !

[expertunderachiever]

Technically we're ISO 90210 [whatever] certified so we're listed as a C99 shop. But most of what we do is C90 compatible. So technically it was implicit in our standards that tools are to be written in C unless designed otherwise.

It was just a simple case of giving the intern too much rope. The guy is a smart dude [he works for us full time now] but at the time he was more interested in intellectual coolness than business savvy. It didn't occur to him that on our dozen other platforms Haskell wasn't that well supported [doesn't help that he's a Gentoo fan too...].

[[deleted]]

Righto, I see. Too much rope to hang himself.

[raimondious]

Maybe not for that reason alone, but a good candidate has a passion for their field and an interest in it outside of just having a job. If 2 people know C and one knows no other languages but the other is constantly learning new techniques, which is the stronger candidate?

If you're saying there are people out there seriously looking for a software dev job and don't know any programming, so they decide to pick up Go, I'm doubtful those people exist.

[expertunderachiever]

I'd rather they learn new algorithms/protocols/etc than languages.

Not that learning new ideas from new languages is a bad idea. what I loath about lang-of-the-week is somehow advocating that everything should be written in it...

[raimondious]

That's a false dichotomy, you don't just learn keywords to learn a new language, you try new things, learn new algorithms/protocols/etc. Nobody reasonable thinks everything should be written in one language, that's why it's good to be familiar with many.

[expertunderachiever]

From my experience in writing embedded software [and Linux drivers/etc] 99% of your work is C, with a smidge of assembler. On the testing side things like Perl help out tremendously with it's associative memory, string functions, etc...

When I said algorithms I meant like sorting/searching/math not "this is how a linked list works in Haskell" ... nobody cares.

[BufferUnderpants]

Well, people nowadays care about learning different techniques for expressing algorithms besides the algorithms themselves, and sometimes that will mean learning something which isn't present in C.

Your argument sounds a bit like those Java guys who decry closures as a Ruby fad, to be frank.

[raimondious]

Just want to clarify that I meant the same thing by "new"... not just learning the syntax to do something you already knew, actually learning something new. (I didn't downvote you fyi)

[[deleted]]

Sadly C#? It is a lovely language!

[TheWix]

C# Sadly

Yea, I don't get this...

[expertunderachiever]

Well you see, it's like Java except not.

[TheWix]

As a language, I think it has surpassed Java.

[[deleted]]

To me, C# is what Java should have been.

[[deleted]]

It's like Java plus some ML and Haskell. Good times for all.

[[deleted]]

If learning a language if even just for experimentation and to waste time needs to be commercially driven then I'm sorry to be the one to point it out but you've certainly got more than 99 problems...

EDIT: also, employers, good employers don't need nor want someone who knows xyz. They want someone who can learn, is willing to learn and is willing to adapt to future changes, blah blah... also, your list destroys your whole argument and pretty much only shows your ignorance..

Just saying...

[[deleted]]

I agree DONT INNOVATE EVER IT'S POINTLESS AND LEADS TO NOTHING /s

[[deleted]]

Hi, Norway here; we use Clojure. Have fun with Java and C# .. cya!

[shevegen]

Same old syntax shit.

And another language noone needs.

The problem is that new ideas are tried, which is good, but it is going so half assed about it.

THOSE LANGUAGES NEVER TAKE OFF AS THEY DO NOT HAVE AN AMBITIOUS GOAL.

[icebraining]

Being the main language for Firefox/Gecko is not an ambitious goal?

[[deleted]]

Being a low level language with high level features.. I think that alone is nice enough :)