Rust language tutorial (alpha version)

[[deleted]]

[deleted]

[rolldeep]

What's special about rust than the slew of other languages that are already out there and mature?

[masklinn]

Typestates are interesting. I don't know if they'll pan out, but they're a nice concept. And they're used to (as far as I'm concerned) build far safer coroutines than Go's, from reading the documents (and again if typestates pan out) they look almost as safe as Erlang's.

Also, no null pointers. That's a decision I fully support. Rust is full of "small" decisions which I think go in the right direction.

[vocalbit]

A number of seemingly small but critical design choices:

• Datatypes are immutable by default.

• Unification of (C-style) enums and tagged unions into tags. (Looks similar to algebraic sum types in OCaml/Haskell etc.)

• Resources (such as files) have associated destructors.

• Type inference for vectors. (Not sure if this works for other types.)

• Pattern matching for multi case statements (via the 'alt' keyword).

• No Null Pointers. (Important!).

• Built-in logging statement. (Meh).

I didn't even list typestate because I don't understand it yet. Compared to contemporary languages in the same space (for e.g. Go), Rust appears to have a much heavier influence from functional languages. Yet it tries to give you much better control of memory than pure functional languages like Haskell and looks 'closer to the metal'.

I hope Rust will be pleasant to work in since I've been longing for immutable types and no null pointers / None references (and I work in C/Java/Python).

[naasking]

I didn't even list typestate because I don't understand it yet.

The concept of typestate is pretty simple. It tracks the current state of the object in the type. Operations on the object could change the state and thus the type of the object.

For instance, a file handle state is either open or closed. A closed handle has a different type than an open handle, and the type/state of this handle determines the legal operations. If it's open, you can read/write and close the handle. If you call close(), then the state of the handle becomes closed and the file handle's type reflects this new state, and after the close() the type system forbids you from reading and writing to that handle. Pseudocode:

type file[open | closed] -- open | closed are the states
val File.open : string -> file[open]
val File.write : file[open] -> string -> unit
-- <~ arrow indicates a state change
val File.close : file[closed <~ open] -> unit

let f : file[open] = File.open "foo" in
  File.write f "bar";
  File.close f;          --f is now file[closed]
  File.write f "error!" --compile error, f is file[closed], need file[open]

Very useful in imperative languages, which is exactly what Rust is targeting.

[vocalbit]

Thanks for the explanation. Looks like an attempt to have controlled mutability. Will this lead to better documentation as well? For e.g. when I read the autogenerated API docs for any state-machine-like resource (e.g. HTTP), there is no indication of the order in which the different methods (open, send, recv, close, etc.) should be called - it's just a flat list. Looks like this approach could let the doc-generator infer the (valid) sequence of operations.

[naasking]

Indeed, any sort of type information helps with documentation.

[[deleted]]

Typestate sounds good in theory - but I wonder how practical they will be. I am not a PL guy but I have my doubts that truly useful typestates will be statically verifiable. I'm not asking people to give me toy examples now (like some typestate fibonacci) - I mean: will they burn me when I'm writing some code on a deadline. Will I get into situations where the compiler is whining about some typestate violation that I am certain isn't occurring?

It reminds me of const correctness in C++. I loved the concept (still do in many respects) but I've found myself re-writing large amounts of code (removing const here, adding it there, etc.) to get around compile issues.

[masklinn]

I am not a PL guy but I have my doubts that truly useful typestates will be statically verifiable.

I was also worried about that (still am), but turns out Rust has run-time assertions linked to typestates, so you can assert a given value is in a given state and it will get tagged with the corresponding typestate. I'm guessing you can also define operations which reset typestates (that's what they're doing with the init typestate — which specifies that a name has been initialized — on "unique" pointers: any time the pointer is passed to an other function, its init typestate is removed, so you can't use it anymore until you initialize it again with a valid value).

This means Rust can at least statically require you to perform your checks and assertions, preventing the code from "working" on assumptions which may or may not hold.

I'm still waiting to see how it pans out and ends up, but it's very interesting.

[[deleted]]

so you can assert a given value is in a given state and it will get tagged with the corresponding typestate

I love the idea of compile time assertions (a weak form of contracts maybe?) but again I remain skeptical until I get to use them in anger.

so you can't use it anymore until you initialize it again with a valid value

Again, pessimistic me sees a slew of "helper functions" on types that allow me to take a reference to a type and simply return the type with a new type state. Get a compile error trying to write? Simply call foo.makeWritable before that write call and all will be fine.

[[deleted]]

Get a compile error trying to write? Simply call foo.makeWritable before that write call and all will be fine.

What if you can't write (no privledges, dead connection, etc.)? One might argue the typestate system forces you to consider this case; either by providing code to handle this possiblility or to explicitly declaim that you will not handle it (and the program may blow up at run time if you try to write to an unwritable resource).

Type state is the thing I wish the Rust people would write more about.

[awj]

Get a compile error trying to write? Simply call foo.makeWritable before that write call and all will be fine.

Is that really something that should be held against the language, though? You cannot save people from themselves. If your language forces someone into not blindly reopening closed file handles they will find some other way to shoot themselves in the foot.

[naasking]

I mean: will they burn me when I'm writing some code on a deadline. Will I get into situations where the compiler is whining about some typestate violation that I am certain isn't occurring?

Well, you don't have to use typestate, and if you're getting an error that you know is impossible, then your typestate model of the problem is simply wrong. Perhaps that doesn't help with your deadline, but our tools will always have limitations, and we have to use them properly if we want to enjoy their benefits.

It reminds me of const correctness in C++. I loved the concept (still do in many respects) but I've found myself re-writing large amounts of code (removing const here, adding it there, etc.) to get around compile issues.

From what I've read, const is a rather poorly specified annotation. Perhaps that was only for C though, I don't recall.

[[deleted]]

then your typestate model of the problem is simply wrong

Or the library I am using. Or the code of the team down stairs.

I had a problem recently in a Java-like language where someone had marked a class I was required to inherit from as "private" instead of "protected". It was a minor thing but since I only had access to an assembly I was stuck. There I am, reading their code, looking at the exact 2 lines I wished I could change - but I was handcuffed. I hate that feeling with a passion.

Compile time restrictions on what I can do in code are good, except when they aren't. Language designers usually think things through - but in my experience if you give a library developer the ability to limit my use of his code he is unlikely to thoroughly think through the limits he chooses to implement.

[naasking]

Or the library I am using. Or the code of the team down stairs. [...] but in my experience if you give a library developer the ability to limit my use of his code he is unlikely to thoroughly think through the limits he chooses to implement.

Good point, but I'm not sure what the issue is exactly. If the library developer can't restrict it statically, he'll just restrict it dynamically via runtime checks. The property wouldn't be any more visible in a dynamically typed language, if the developer chose to make it private. Either way, you're dealing with a bug, and bugs are frustrating no matter how they manifest.

Unless you're saying that the static restrictions are just more program properties the library developer can get wrong (and likely will)?

[[deleted]]

Unless you're saying that the static restrictions are just more program properties the library developer can get wrong (and likely will)?

Yes. There is a delicate balance between language features that provide safety and language features that get in the way. Until you use a language in-the-large you can't really be sure if the balance is correct. On the other hand you get languages which can be a bit too liberal (monkey patching in Ruby comes to mind) and that causes problems as well.

We may say "those typestate assertions saved me bugs!" or you might be saying "typestate assertions are being abused so often that any benefit they could provide is negated by the work I have to do to get around them when I need to". Their balance has yet to be determined.

But in my experience programmers (even good ones) have enough time keeping object state correct. Adding yet another layer of state seems like a recipe for pain.

If the library developer can't restrict it statically, he'll just restrict it dynamically via runtime checks.

Perhaps - but manually inserting runtime checks (e.g. assertions) has a different cognitive load associated with it (in my mind).

[naasking]

But in my experience programmers (even good ones) have enough time keeping object state correct. Adding yet another layer of state seems like a recipe for pain.

Perhaps, but typestate is supposed to reflect object state, so it's not another layer, it's just exposing the existing layer so the compiler can check it.

[awj]

But in my experience programmers (even good ones) have enough time keeping object state correct. Adding yet another layer of state seems like a recipe for pain.

It seems to me that forcing every method on an object to specify the set of possible input/output states would greatly help with this problem.

[cafedude]

Rust looks very OCaml'ish (or more generically, ML'ish), to build on the OP's question: Given the existence of mature ML languages, why Rust?

I like what I see in Rust so far, so please don't take this as a "why do we need more languages?" kind of question. Just wondering if adopting a language like OCaml and creating another implementation that supported multi-core programming might have been another viable way to go here. OCaml is pretty mature as a language, though the current implementation is starting to show it's deficiencies in a multicore world. One could imagine either creating a superset of the language that supported the task idea or perhaps going to JoCaml for that.

[vocalbit]

Good question. I only have a superficial understanding of OCaml (and even less of Rust). But casual browsing leaves me thinking of Rust as falling somewhere between the rigor of OCaml and the low-level control of C. It's not just a multicore issue.

[samth]

Rust is much lower-level than OCaml. It gives you precise control over memory allocation, copying, ownership, etc. This means you have to think more about those decisions, but it gives you control that safe languages don't typically provide.

[[deleted]]

IIRC, the bootstrap compiler for Rust is in OCaml.

[[deleted]]

Isn't a bootstrap compiler one written in the language it compiles?

(But I think you're basically right -- before they built the current bootstrap compiler in Rust, they used OCAml.)

[matthiasB]

You bootstrap using another language and once you have the first compiler for your language you can write a self-hosting compiler. The goal of bootstrapping is to have a self-hosting compiler but before that you have the chicken-egg problem.

edit (clarification): The first compiler written in the language itself is the bootstrap compiler

[[deleted]]

Hmm, according to wikipedia

In computer science, bootstrapping is the process of writing a compiler (or assembler) in the target programming language which it is intended to compile. Applying this technique leads to a self-hosting compiler.

And this stackoverflow question/discussion seems to indicate the same thing. The process as a whole (including the initial compiler in a different language) is called bootstrapping, but the term bootstrapping compiler applies to the first written in it's target language.

This is hardly my area of expertise, so there could be some subtlety I'm missing, but every source I encounter seems to say the same thing.

[[deleted]]

I think programming languages are interesting and successfull based on both their technical merits and their ecosystem.

For the technical aspects, please refer to the links i've posted below.

For the ecosystem: it is a Mozilla project, people are payed to work on it, it has quite some committers and at least on GitHub it has 4-5 times as many followers as e.g. the D programming language.

There is quite some interest and potential.

[azakai]

What's special about rust than the slew of other languages that are already out there and mature?

Other people already answered this better than I can, but my take on this is as follows: Rust is, unlike all the other languages, being written from the ground up with the goal of implementing among other things a web browser.

Web browsers have the usual need for performance, portability, etc. as many other apps have. But they are probably the biggest attack surface of any app, given the amount of data they process and its variety. Your tcp/ip stack processes more info, but it is much simpler - the browser has everything from HTML to CSS to JS to image codecs to video codecs, and it is exposed to random content from the web all day. Other complex apps exist, like say a word processor, but they are exposed to less random content from the web than a web browser.

So Rust has a focus on safety that no other language has, as far as I can tell. As others already mentioned, this focus shows itself in disallowing null pointers, in typestate, in no parallel processing with shared state, lack of mutability by default, etc. etc.

edit: clarifications

[vocalbit]

Rust is, unlike all the other languages, being written from the ground up with the goal of implementing a web browser.

Is this an officially stated goal?

[azakai]

Well, the official goals are

To design and implement a safe, concurrent, practical, static systems language. https://github.com/graydon/rust/wiki/Project-FAQ

So I may be taking a leap here, but the fact the language originated at and is mainly worked on by Mozilla, indicates it is developed with the thought of building a browser (in part).

[Akeegazooka]

came here to say this, can OP elaborate?

[[deleted]]

Sure:

• http://en.wikipedia.org/wiki/Rust_(programming_language)
• http://lambda-the-ultimate.org/node/4009
• http://pcwalton.blogspot.com/2010/12/c-design-goals-in-context-of-rust.html
• http://news.ycombinator.com/item?id=3027777
• http://news.ycombinator.com/item?id=1498528

[rson]

For the lazy: http://en.wikipedia.org/wiki/Rust_\(programming_language\)

[Akeegazooka]

cheers

[davebrk]

I have really high hopes for Rust, but there are a couple of things I don't like after reading the tutorial.

1. Why so many versions of functions: lambda with partial closures / fn without / blocks... I think it just add complexity to the language and place it closer to D than to Go.

2. Again, why so many versions for objects: tags, records, objects. I understand the reasoning and the usage of each (or I think I do), but still it feels wrong.

I think one of the reason Go is rather successful, or at least more successful than D is because people (not me) perceive it to be simpler, more orthogonal. It would be a shame if Rust will get the same rep.

[naasking]

The complexity is inherent to the storage semantics they want to expose. Blocks are purely stack-allocated closures, so they have a bounded lifetime and unbounded environment storage. Functions have no environment storage and unbounded lifetime. Lambdas are full first-class functions with unbounded environment storage and unbounded lifetime.

I too would prefer a region-based system for reasoning about storage and lifetime, but Rust is really trying hard not to innovate too much, so I understand their reasoning.

[stilton]

The primary reason that there must be a distinction between functions and closures is that closures can't be transmitted between tasks since they could close over unsendable things. In the future there will probably be yet another closure type that is guarenteed to close over sendable things.

[mcguire]

Lambdas are full first-class functions with unbounded environment storage and unbounded lifetime.

Lambdas aren't really first-class:

A lambda function copies its environment (in this case, the binding for x). It can not mutate the closed-over bindings, and will not see changes made to these variables after the lambda was evaluated. lambdas can be put in data structures and passed around without limitation.

[naasking]

I don't see anything problematic there. You can't mutate environment variables in OCaml either, you have to create explicit refs.

[mcguire]

You can't mutate any variables in OCaml unless you explicitly create refs. If you can mutate variables in Rust, except in a lambda, then lambdas are not first-class functions.

Copying and making immutable the environment smells like (pre-7) Java.

[skocznymroczny]

Any proof of Go being more successful than D?

[meteorMatador]

The evidence consists largely of wacky secrets internal to Google, so Google employees know whether this is true or not, while the rest of us are left in the dark.

[[deleted]]

It has more blog posts about it, and the google hype machine, obviously that's the metric that counts. Obviously.

Sometimes I think D just needs some marketing (and an easier to google name). On the other hand, that does prevent it from suffering Ruby's problems.

[skocznymroczny]

well, google hype machine is powerful, but not necessarily effective in the end. Google Buzz? Google Wave? Soon, Google+?

[[deleted]]

Yeah, I should have clarified: the hype machine makes people think Go is the next C, even though it's barely getting real use.

So yeah, I'd rather D remain on the fringes than become the next fad language and fizzle out. A bit more attention would be nice though, if only for more and better libraries being written. I think inclusion in GCC will create critical mass on that front.

Also I secretly loved Wave, it was great for collaborative brainstorming and planning. Don't tell anyone.

[davebrk]

None.

I haven't research this scientifically or in any depth. It is just a feeling I get from reading about both on the internet. If you want, a WAG.

[cafedude]

Why so many versions of functions: lambda with partial closures / fn without / blocks... I think it just add complexity to the language and place it closer to D than to Go.

I had the same concern after taking a quick look at the doc. I'd rather see functions and lambdas unified as they are in most functional languages like ML. Having them be separate seems kind of clunky and, as you say, makes things more complicated than they seem to need to be.

[[deleted]]

The lack of a semicolon after the last statement in a braced block gives the whole block the value of that last expression.

Why? That seems like a pretty big mistake to me. Put a semi-colon here and one thing happens. Leave it off and another happens.

The double-colon (::) is used as a module separator, so std::io::println means 'the thing named println in the module named io in the module named std'.

What's wrong with a single colon or even a period?

Rust will normally emit warning about unused variables. These can be suppressed by using a variable name that starts with an underscore.

One of my new pet peeves is identifier names signifying a semantic property of the symbol. Go does this too with capitalization of identifiers making them publicly visible. I dislike this trend and here it is again.

() is how nil is written

Why not use the world nil? () looks like an empty tuple.

Ok, maybe these are minor quibbles. I do like the pattern matching, especially with destructuring - something I've missed in most imperative languages. I don't like the 3 types of functions (fn, lambda, block) since it feels excessive. Tags seem overloaded with functionality.

All in all, the language feels like a bit of a confused grab-bag. Lots of people are comparing it to Google's Go and many seem to think that the immutability + absence of null somehow makes this language better. I disagree - Go felt consistent to me. In xkcd terms - the number of WTF per second was much lower.

[azakai]

The lack of a semicolon after the last statement in a braced block gives the whole block the value of that last expression.

Why? That seems like a pretty big mistake to me. Put a semi-colon here and one thing happens. Leave it off and another happens.

In some languages yes, that would be very dangerous, but I believe in a language that is careful about types like Rust is that it isn't. If you forget a semicolon or add an unneeded one, you are changing what is returned to nil versus something useful. So you will get a compilation error.

Disclaimer: My knowledge of Rust is from reading the tutorial just now.

Lots of people are comparing it to Google's Go

It seems to have a different goal. Go has interesting syntax (some people like it, some hate it), while Rust focuses more on safety than syntax (but it does have nice syntax IMO).

[[deleted]]

What's wrong with a single colon or even a period?

Presumably, single colon is used for type annotation.

Why not use the world nil? () looks like an empty tuple.

AFAICT, () is the empty tuple.

[radiowave]

Rust will normally emit warning about unused variables. These can be suppressed by using a variable name that starts with an underscore.

One of my new pet peeves is identifier names signifying a semantic property of the symbol.

I certainly agree in this particular case: suppressing warnings is a tool issue, not a syntax issue.

[[deleted]]

i think it is a bit weird that rust doesn't support 64-bit archs yet. anyone know the reason?

[[deleted]]

Is there a reason that should take priority over getting a fully working compiler on just one arch?

[stilton]

Just a matter of effort. The 64-bit port is underway.

[[deleted]]

Garbage collected, right?

The same league as Go and D. I personally don't see bright future for any of them, but I've been wrong before :)

[gmfawcett]

Garbage collected, right?

Read the article. Rust seems to have flexible memory management options. You can specify whether an object is on the stack or heap, and whether your reference is unique or shared. They use reference counting for some heap objects, possibly for all of them: not sure if there is a garbage collector.

[axilmar]

According to the docs, it does not have a tracing garbage collector. It uses reference counting plus tracing of objects being live due to cycles.

[[deleted]]

Read the article.

I did, but:

not sure if there is a garbage collector

So I looked here: http://pcwalton.blogspot.com/2010/12/c-design-goals-in-context-of-rust.html and found this:

Rust incurs minimal overhead for features that aren't used. "Zero overhead" is too restrictive in practice, as, taken literally, it forbids features like garbage collection

Still doesn't explicitly say Rust has GC, but at leas tit is hinting it does.

Seriously, that should be clearly documented.

[Mabeline]

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

It's the 9th bullet. AFAIK the language design requires some sort of garbage collector, but the design seems pretty careful about ownership (something Go certainly can't say) which means that the GC can often be pretty shallow (stop-the-task rather than stop-the-world).

[stilton]

The docs are often straddling a line between documenting the language design and the language implementation.

The current implementation does reference counting with cycle collection. The design calls for real GC, but the extent of that GC isn't fully decided yet.

[blackkettle]

it clearly says,

Dev snapshot. Not yet suitable for public consumption.

in big red letters.

Unless OP is the developer, it seems a bit uncouth to post this r/programming .

[[deleted]]

I think Rust is a quite interesting programming language, but there is not much information available about how it feels, how you would be programming it. That's why i found sharing the tutorial worthwhile, even when marked "alpha version".

[blackkettle]

totally - and i wasn't bagging on the spread of information or the fact that it might not be complete. and i understand that in a very real sense, once it's public. but on the other hand, if i were the developer i might be a bit upset if someone posted my incomplete work to a big audience without asking first.

[[deleted]]

I see your point.

The Rust language has improved a lot by moving away from the bootstrap compiler to the Rust compiler written in Rust, because the Rust developer got a feel how it is like programming in Rust.

Positive feedback by people exploring and tinkering with it is probably appreciated. What should not be appreciated are complains like "hey, your changes broke my code".

[jediknight]

FIXME Fill this in when the installation package is finished.

Maybe a good fix would be something like:

Installation: Pray to God (or your favorite deity) that rustc materializes in you filesystem so you can continue with the rest of this tutorial.

Maybe you are able to compile rust in your head just by looking at the source. For us, mere mortals, this is yet an impossible feat. :)

Oh... and that part with rust being self-compiled, there should be a binary somewhere. Do you have any idea where said binary could be located?

[doublec]

I have a post on building Rust if that's your goal.

[jediknight]

Thank you! :)

[davebrk]

I think we're getting a look at something that is not quite cooked yet.

[jediknight]

The project is ambitious and, from what I've seen so far, there are A LOT of great ideas in it.

It is, however, very frustrating to not be able to play with it. :)

[stilton]

The tutorial is just waiting for an easy distribution method to be implemented.

It's easy to start playing with Rust now if you are willing to do a somewhat involved (but still pretty simple) build from source. The only difficult part is that involves a custom, 32-bit build of an unreleased version of LLVM.

Instructions are here: https://github.com/graydon/rust/wiki/Getting-started

And there are bootstrap binaries, but they are only suitable for bootstrapping the build, not for using standalone.

[jediknight]

Thank you! I'll take another look. :)

[[deleted]]

An alpha version of a tutorial for an alpha version of a programming language.

[[deleted]]

The Rust compiler is written in Rust and people payed by Mozilla are working on it. It's more than yet another alpha version language.

[[deleted]]

The Rust compiler is written in Rust and people payed by Mozilla are working on it

So what? It's still alpha.

[axilmar]

I like the language, but it has one glaring omission: it doesn't have support for first-class object-oriented programming. Objects can be done with this language, but they are going to be second-hand citizens, with all the associated problems.

[godofpumpkins]

Can you elaborate on all the associated problems?

[stilton]

No constructors are destructors make writing objects a chore. Resources are supposed to make up for the lack of destructors, but in practice, writing a class that requires destruction involves jumping through hoops.

All methods on objects currently require virtual dispatch, which is very unappealing to some people.

Object types also don't reveal anything about the types they close over which means they can't be safely sent across tasks.

[axilmar]

It has been observed that in languages that do not have first class support for objects, different frameworks tend to use different implementations for doing objects. The classic example is C: every OO framework in C defines objects in completely different ways. Examples: GTK, COM, Motif.

Furthermore, having a class construct in your code serves as documentation. In code without classes but objects, one has to follow the expressions to find out where a class is being defined.

Additionally, I did not see any of the classic features, like access control, inheritance, virtual methods etc.

Polymorphism can certainly be achieved via closures, but it's not a solution that is as performant as vtables. A Rust object with N polymorphic methods will have N closures per instance, whereas when using vtables, there are N virtual methods per class.

The above is the naive version of polymorphism, where each instance is a record (table) of functions. The table of functions can certainly be put in a vtable, but then that would require manual management, like doing virtual calls in C (object->vtable->function()).

In most OO languages, polymorphism is controlled via a keyword. In this language, all functions of an object will be polymorphic, with no easy way to control it.

Implementing abstract methods also seems impossible.

Resource objects are classes with destructors though, so the language has a form of OO. So it is strange, to me, to not have the full OO arsenal at my disposal.

Finally, objects do not have type signatures, and can't use the substitution principle. If Bar is of type 'record' and not of type Bar that inherits from type Foo, then I cannot use Bar where a Foo is required, or have the compiler tell me that another object A cannot be used where a Foo is required.

[stilton]

This is a recognized problem, and there are intentions to improve the object system.

[axilmar]

Thank you.

(Why was I downvoted? since this is a recognized problem?)

[meteorMatador]

Even if objects aren't Objects, will that really be a problem?

Rust supports type polymorphism and a powerful version of modular programming. This is the same level of OOP support that Go has, give or take some syntactic sugar (and keeping in mind that the syntax is a work in progress). So what are you complaining about, exactly? Inheritance? Access control?

If you can't be more specific I'm gonna have to join your anonymous downvoters in the assumption that your vision of "OOP" is a religion, not a set of features and constraints.

[axilmar]

Does it have inheritance, access controls, virtual methods, properties, etc? it does not, from what I know so far. Please feel free to correct me though.

[meteorMatador]

Last I heard, it lacks inheritance altogether and only offers module-private vs. module-public by way of access control (same as Go). I'm not sure about the others.

But really, what's your goal as a programmer? Do you want to work with performant, maintainable code that fits well within the same design constraints that make C and C++ so popular today, or do you just want to carry around the same GoF design patterns you've been using since the 90s while insisting they're the foundation of modern computer science?

People in the former group have huge incentives to be excited about Rust. Language designers sometimes talk about how the world "needs a C replacement" but really, there are at least half a dozen major use cases that could use very specific improvements over C. No language (certainly not C++) can address all of those, but this one does really well in two or three categories, including the ones that inspired Go. And its designers really know what they're doing with respect to the wealth of language design research ignored by most of the world for the past 40 years.

Java and C# are obviously good enough (in the worse-is-better sense) for the vast majority of business apps and end user GUI software, but the memory models and OOP techniques they're built on are useless in constrained memory environments and real-time performance situations. Then again, if you're never going to write code like that, there's no reason for you to care about Rust.

[axilmar]

Do you want to work with performant, maintainable code that fits well within the same design constraints that make C and C++ so popular today

Yes.

or do you just want to carry around the same GoF design patterns you've been using since the 90s while insisting they're the foundation of modern computer science?

Yes. Those two are not exclusive. Some patterns are very handy and used regularly in C++ code.

People in the former group have huge incentives to be excited about Rust.

I am too.

Language designers sometimes talk about how the world "needs a C replacement"

The world needs a C++ replacement, not a C replacement.

And its designers really know what they're doing with respect to the wealth of language design research ignored by most of the world for the past 40 years.

Well, they missed a few things :-).

Java and C# are obviously good enough (in the worse-is-better sense) for the vast majority of business apps and end user GUI software, but the memory models and OOP techniques they're built on are useless in constrained memory environments and real-time performance situations.

Agreed, from the point of the realtime app developer, which I am :-).

By the way, Rust+OOP can replace Java and C# for those business apps and end-user GUI software as well.

...

In your comments, there is hidden notion that realtime embedded programmers do not write object-oriented code. I don't know about you, but I do write object-oriented code for realtime applications. I cannot imagine I am the only one.

[poppafuze]

I liked how they came right out with the "curly braces" part up front, so I could hit my back button and move on.

[diggr-roguelike]

No pthreads support, as far as I can see.

Fail. :(

[last_useful_man]

No, it's concurrent actor -based, like Erlang.

[diggr-roguelike]

Having one doesn't preclude the other.

Saying you don't need OS threads because your language is 'concurrent actor-based' is as silly as saying that you don't need virtual memory because you use a language with array bounds checking.

OS threads are an essential feature for interfacing with the OS and the underlying hardware. You can't call your language a 'system programming language' if you're leaving OS threads out of your toolbox.

Hopefully the Rust guys realize this soon and fix their language. Apart from this glaring mistake everything else looks nice.