Because, faced with the fact that C++ makes an octopus by nailing extra legs onto a dog, D decided the right thing to do was to staple-gun them onto a cheetah instead.
D, at the end of the day, is C++ with cleaner syntax. Yes, you've gotten rid of headers and some of the syntactic ambiguities, but things that were mutable are still mutable, templates are still templates, hard-to-solve threading problems are just as hard to solve, etc. Indeed, I'd argue this is one of the reasons why C++ coders generally like D: it's the same damn thing with the most painful dumbth removed.
Rust, on the other hand, focuses on having different semantics from C++, in order to make certain problems much easier to solve. The big one is immutability, which makes code easier to reason about, and vastly simplifies multithreaded code compared to its D or C++ counterparts. But there are other major semantic differences, such as region pointers, the lack of nulls, and more, that really solve the semantic issues that crop up in C++ programs.
I know people who like D, and are highly productive in it, but Rust is solving a very different problem in a very different way.
`string` is immutable. You can use immutable everywhere if you like. C++ doesn't even have transitive const.
> templates are still templates
With constraints, unlike C++.
> hard-to-solve threading problems are just as hard to solve
Have you looked at D 2.0? Globals are thread-local by default, unlike C++. Implicit sharing is disallowed, unless immutable.
> region pointers
It's early days (perhaps I don't fully get region/borrowed pointers yet) but D's `scope` parameter keyword seems very similar. It prevents an argument escaping the function call.
> lack of nulls
This is the big one. Unfortunately D doesn't seem to have an answer on this. I understand Rust uses option/sum types for this, which seems like a great idea.
This is why I'm excited to pick up Rust. I feel like Go makes it very easy for me to get running and churn stuff out with a simple syntax but Rust seems to be bringing in more of the "new" in CS and I want to give that a shot. Rust has surplanted my interest in D and this comment is pretty much exactly why. When I look at D I see a lot of C/C++ type things that make me go "Wait, I thought this was D and not C++ improved".
D's garbage collection is global, and either off or on (and a lot of D libraries leak memory like crazy if it is off, so in practice it has to be on most of the time)
Rust's per task GC seems like it should allow more flexibility, and I'm hoping it would be usable in the High Frequency Trading arena, for example.
> D's garbage collection is global, and either off or on
That makes it sound like you can't use GC and manual memory management together; you can - std.container uses manual memory management internally for max efficiency.
Can Rust retarget GTK or QT ? Actually, the important question is whether it is meant to.
Will it ever be intended to replace application languages like Vala, Mono (used to write Tomboy, Banshee, etc.) or will it be restricted to system level stuff.
Yes, Rust is intended to play nicely with GTK and Qt. For one, browser engines need to interface to the platform-native toolkits.
Scripting support would be cool. To me, Rust isn't necessarily the best language to write small one-off scripts in; I personally prefer dynamically typed languages (or whole-program type-inferred languages) for that. But if you want to write scripts in Rust, I'd certainly review any pull requests to make it easier :)
I'm more interested in an alternative to write desktop apps in, rather than small one off scripts.
I'm interested in this from a vision point of view. What are going to be your first "written-using-Rust" apps ? Firefox is gargantuan, so it cant be your first. Ergo, the question about platform toolkit compatibility. If you build that one first, you will start spawning an ecosystem almost instantly... if you want.
Mono, Vala, etc. have nice apps that people love. I am wondering on how can you bridge the gap between javascript/Qtscript and Rust to make it easier to build apps in.
>What are going to be your first "written-using-Rust" apps ?
Rust compiler is written in rust, so that would be the first "written-using-Rust" app. Additionally afaik the work on rust-based web-browser (engine) has began, so that would be second (major) project for rust.
i love that they're thinking of syntax sugar right in the early stages. a lot of the "language semantics are all that matters" crowd scoff at sugar, but i think they underestimate how much syntax contributes to the pleasantness of using the language.
Interesting. I like many of Rust's language concepts (and I have contributed some small fixes to the Rust runtime), but (to my eyes :) the syntax is snowballing into a hybrid of C++ and APL.
What in particular do you not like? To me the proposed stuff on the roadmap fixes the problems I see (changing "::" to ".", camel case for type names, "alt" -> "match", => after pattern matches, #debug to debug!, removing argument modes -- no guarantees that we implement these of course, they need consensus), but I'm curious as to what your thoughts are.
I hadn't seen the roadmap changes. They address a lot issues I had, especially the argument modes.
I'm sure camel casing will be controversial, but it makes sense given that Rust's primary audience is Mozilla, where camel case is the enshrined naming convention for its C++, Java, and JavaScript code. Python's standard library is an ugly example of what happens when the language community can't settle on one convention.
Also, I wonder why 21st century languages still use "&&" and "||" operators. Python's "and" and "or" operators are easier to read (for English speakers) and type. They don't require shifting of distant keys. "and" has two home row characters. "or" has fewer keystrokes than "||". :)
Instead of angled_brackets<> they should probably try to go with D's style of templates[1], which uses an operater !, to signify its use.
Also, I personally believe that camel case for type names would be a net loss; the underscore separates the words nicely, and I think it's pretty clear from the syntax what is and is not a type name (in my extremely limited experience).
What I like about camelcase is that it confers the same kind of visual classification to types as to certain other things.
Back in the day, I used ObjectPascal, where we used camelcase for everything: function names, variables, types. Borland set an early precedent by prefixing many class types with the letter T, thus to visually distinguish them from other things: So you had TWindow, TButton, etc. This system makes sense when you see it in practice:
function GetParent(Window: TWindow): TWindow;
begin
...
While a bit crude, I feel the same kind of visual differentiation is needed for a language like Rust.
Ruby has some syntactic oddities I like precisely because they provide visual classification: "@" for instance variables and "@@" for class variables:
class User
@@max_name_length = 32
def initialize(name)
raise "Error" if name.length > @@max_name_length
@name = name
end
end
The current "old-style" Rust code quickly becomes a uniform sea of lowercase to me, as does Stroustrup-style C++. It gets worse due to a quirk of mine to name things verbosely. So instead of variables like "u" to represent a user, I spell out "user". With all lowercase it gets odd:
fn save(user: user) {
...
}
While Rust have types and variables living in separate namespaces, all-lowercase names introduces the possibility of ambiguity and possibly makes some things impossible in the future, I think; consider:
let foo = user.new();
It looks like a method call "new()" on an instance "user". But what if you could call methods on types? With the discussion about the "::" operator becoming ".", such a distinction would become impossible without introducing a new operator. With camelcase it becomes obvious what's what:
I heard that Rust was meant to capture the spirit of the language. It was meant not to have a lot of knew ideas (although, as it turns out, language design always leads to new ideas). We have a sort of informal rule to not include research that's less than 10 years old, so we can build off of ideas that have had a chance to prove themselves. We're bending that rule a bit now, of course. The idea was that Rust would codify and provide language support for patterns that have worked well in making large software like Firefox fast and safe.
TBH the name does make me think of rusty metal, as in dumped cars which are old and broken. Not sure that's the best mental image to create from the name of a new technology...
Two of the newest programming languages that I think have potential are Io and Rust. Io is a mash up of languages with speed similar to lua and has a list like syntax of lisp.
I wonder if anyone can explain why they have not tried to incorporate some of lisp's syntax as it is more efficient for linked lists I think. And I thought part of the reason for Rust's development was for very fast/efficient concurrency that is properly garbage collected.
Rust is being used to implement an experimental new browser engine with a focus on concurrency in order to better take advantage of highly-parallel and power-limited hardware. It's known as Servo,[1] and it's still strictly in research mode; there are no concrete plans to integrate anything into Firefox as of yet. Even if there were, Rust itself won't be at 1.0 until sometime next year, and it would be quite a while beyond that before Servo had any semblance of feature parity with Gecko.
(Note: not a Rust dev, I just hang out in the IRC channel)
Typestate's still there for the time being, but it may not be for much longer. The problem is that it's not being used anywhere in the compiler, so it's not getting exercised nor is it providing any constructive design feedback. Last year there was an attempt to begin using typestate throughout the compiler and standard library, but it proved so clunky to use in practice that nobody had any patience to deal with it. So now there are two camps among the developers: those who consider the (quite large) subsystem to be a useless maintenance albatross, and those who would still like the idea of typestate but who acknowledge that it's not usable in its current form. Rust's BDFL appears to be slowly migrating from the latter camp to the former, so typestate may not be around for much longer.
Either way, making the whole thing work would require more effort than anyone has time for at the moment. Of course, this doesn't mean that it can't be removed now and then reintroduced in some future version of Rust.
Actually, wait, I remember asking Graydon (the Rust lead) about this. I was saving this for the 0.3 release discussion, so now's the perfect time:
me: so what were the reasons that nobody ever used typestate? was it just too cumbersome?
graydon: combination of incomplete and wound up not often able to benefit from much code-path-distance between site of check and site of constraint-enforcement.
graydon: I'm still unconvinced that could not be overcome
graydon: but the result is that using it has effectively caused all callers to do checks just before they call, which isn't much of a win
me: graydon: was typestate the whole reason you started rust in the first place? I'd be really interested to read a retrospective :)
graydon: no, I started rust because I was sick of hacking in C++ and wanted something with a saner compilation model, grammar, safety properties, concurrency properties ...
graydon: I'd used lots of other languages and kept not being able to use them in an industrial setting, because they failed to be similar-enough to C++ in important ways, usually.
graydon: typestate was just a property that hermes had that I liked because it looked like a way to statically optimize DBC, which I like in languages that have it
graydon: (sather, eiffel, some of the C# derivatives)
graydon: I tend to program over-defensively when left to my own devices. make copies of every datum to be local. make everything const. run a lot of internal consistency self-checks. etc. etc.
graydon: (the one habit I hadn't picked up yet, which I'm still trying to, is adequate unit testing and fuzzing ... sigh)
me: graydon: so are you confident yet that even if someone was forcing you to write rust, you would't be sick of it? :)
graydon: my experiences writing rust so far have been pretty positive. it has a number of the parts I like in other languages. the grammar is simpler, the compilation model is better, it's AOT and static, it has algebraic types, clear integer types, is eager and reasonably fast, doesn't force OO style...
graydon: and crucially: doesn't need to allocate / GC like crazy, so can close that residual gap on inner loops without having to hit the FFI
graydon: there are still odd bits we need to whittle down
graydon: oh also the safe references are lovely. and getting better.
me: so what were the reasons that nobody ever used typestate? was it just too cumbersome?
graydon: combination of incomplete and wound up not often able to benefit from much code-path-distance between site of check and site of constraint-enforcement.
graydon: I'm still unconvinced that could not be overcome
graydon: but the result is that using it has effectively caused all callers to do checks just before they call, which isn't much of a win
me: graydon: was typestate the whole reason you started rust in the first place? I'd be really interested to read a retrospective :)
graydon: no, I started rust because I was sick of hacking in C++ and wanted something with a saner compilation model, grammar, safety properties, concurrency properties ...
graydon: I'd used lots of other languages and kept not being able to use them in an industrial setting, because they failed to be similar-enough to C++ in important ways, usually.
graydon: typestate was just a property that hermes had that I liked because it looked like a way to statically optimize DBC, which I like in languages that have it
graydon: (sather, eiffel, some of the C# derivatives)
graydon: I tend to program over-defensively when left to my own devices. make copies of every datum to be local. make everything const. run a lot of internal consistency self-checks. etc. etc.
graydon: (the one habit I hadn't picked up yet, which I'm still trying to, is adequate unit testing and fuzzing ... sigh)
me: graydon: so are you confident yet that even if someone was forcing you to write rust, you would't be sick of it? :)
graydon: my experiences writing rust so far have been pretty positive. it has a number of the parts I like in other languages. the grammar is simpler, the compilation model is better, it's AOT and static, it has algebraic types, clear integer types, is eager and reasonably fast, doesn't force OO style...
graydon: and crucially: doesn't need to allocate / GC like crazy, so can close that residual gap on inner loops without having to hit the FFI
graydon: there are still odd bits we need to whittle down
graydon: oh also the safe references are lovely. and getting better.
What problem does rust solve other languages (D, SML, OCaml, C++11, Objective C, vala, go etc.) did not -- apart from helping with the NIH syndrome? Does Mozilla actually use a language that still is a moving target with respect to its language specification for some substantial work (or what is the real-world status of that upcoming rendering engine which seems to be the reason why rust was called into life)?
They are working on a browser called "servo". It is still early in development.
Vs OCaml it has a threading model. Vs D memory safety, less kitchen sink. Vs C++ cleaner, better type system, memory safety. Vs Objective C memory safety, cleaner. Vs vala I don't know anything about vala. Vs go Here is their list of problems with Go from their website:
Shared mutable state.
Global GC.
Null pointers.
No RAII or destructors.
No type-parametric user code.
Ah, but I think it's important to distinguish between ideas that are new in research and ideas that are new in industry. God knows that pattern matching isn't a particularly new concept, but I sure hadn't heard of it before Rust; see also the popularization of list comprehensions due to Python via Haskell. So I think what the grandparent is implying is that even if Rust doesn't end up as a world-shattering language, it still has the opportunity to expose programmers to "new" ideas, even if, in academia's opinion, those ideas aren't so new at all. :)
Exactly, for example, now thanks to the FP concepts that have been added to .NET in the last versions, I am able to do cool FP stuff while coding boring enterprise applications in C#, without having to ask permission about it.
Or make use of F# for Windows scripting, using as excuse to the boss that it is part of Visual Studio.
Finally a programming language with decent syntax that does RAII, and understands the need to restrict garbage collection!
Thanks!