11 ms·

Rust 0.11.0 Released

207 points by veeti 12y ago

AYBABTME 12y ago
I'm mostly doing Go nowadays but keeping an eye on Rust, which I think would make a good match in my toolbox for areas where Go lacks. Wondering if there's a roadmap/ETA for v1.0?
- TheHydroImpulse 12y ago
  They're shooting for around the end of this year.
- sp332 12y ago
  I found this roadmap https://docs.google.com/spreadsheet/ccc?key=0AlWBWplsaTZvdGdSdEVzZW1BeDA5dm0zM2FFeW0ySEE&usp=drive_web#gid=0 https://docs.google.com/spreadsheet/ccc?key=0AlWBWplsaTZvdGd...
  - steveklabnik 12y ago
    That Google doc has not been updated in a while. Also https://github.com/rust-lang/rust/issues?direction=desc&milestone=20&page=1&sort=updated&state=open https://github.com/rust-lang/rust/issues?direction=desc&mile... and https://github.com/rust-lang/rust/issues?direction=desc&labels=P-backcompat-lang&milestone=20&page=1&sort=updated&state=open https://github.com/rust-lang/rust/issues?direction=desc&labe... , which are the most interesting open questions regarding backwards compatibility.
kbd 12y ago
I love all the "X has been removed from the language" bits that occur in every Rust release.
adwhit 12y ago
I think Rust has been bad for me. I'm interviewing for my first technical role at the moment and all I keep talking about is how much I love Rust and look at these cool things I made in Rust and I want to program in Rust all the time. I mainly receive bemused looks. "We use Java."
- pjmlp 12y ago
  If you are applying to the enterprise that won't change in foreseeable future. Worse, Java really means Java and not any alternative language for the JVM.
  - shmerl 12y ago
    > If you are applying to the enterprise that won't change in foreseeable future. That depends. Not all are bought on the Java hype from the past but it surely is still widespread.
    - pjmlp 12y ago
      The remaining ones are on .NET. At least on my little spot in the World.
    - kibwen 12y ago
      > Not all are bought on the Java hype It's true, my venerable enterprise company prefers RPG-IV and PHP. :)
- ossreality 12y ago
  Run, run away. I still have to use the tools my team uses, but at least I work with people who are interested in something better.
- Mr_P 12y ago
  You could try looking for positions doing C++ development, and specifically with companies which have embraced the new C++11 features. Rust is extremely close in style to idiomatic modern C++, but with greater static safety guarantees.
  - humanrebar 12y ago
    Runtime polymorphism is very different in Rust, and sum types are prolific in the standard library, so I'm not sure how "extremely close" it is to C++11. But there are many similarities in other areas, such as memory safety through references with ownership semantics.
lvillani 12y ago
I'm eagerly awaiting Rust 1.0 to play with it. These days I'm dabbling with Go and while the toolchain is fantastic and the standard library is fairly comprehensive, I find the language itself to be "meh". Rust-the-language looks much more promising but I'm holding my breath waiting until it stabilises before I consider it for my next project. I read elsewhere that they are striving for a near-final release at the end of the year so I won't have to wait long, after all :) Keep it up!
- tbirdz 12y ago
  In the mean time you might want to check out Nimrod or D. These are some other languages in a similar space - compiling to native binaries, but with the amenities of modern languages.
  - egeozcan 12y ago
    These are the exact two languages I want to see prosper. Most important reason is that I want to keep believing that a (bunch of) genius(es) inventing their perfect language that can be practically and widely used without a big company backing is still a thing Secondly because these languages have so many great ideas with high quality implementations.
    - jsmthrowaway 12y ago
      The other side of that is that D has had a long time to percolate and hasn't found the success of Go, and soon Rust. So, we come back to the common startup ailment, which is having an awesome product but it just inexplicably doesn't get traction, while the inferior (depending on perspective) product does. I know there are pockets of D throughout the industry. I know it's catching on at Facebook (and, because I know Facebook folks, I know what an uphill battle those folks are having too). I just don't hear about D nearly as much as I'd expect to over a decade in. Nothing against D, mind.
      - lvillani 12y ago
        In my opinion the fact that there were two competing standard libraries (Tango and Phobos) certainly brought confusion and needlessly fragmented the community. IIRC, at the beginning the whole thing was not being developed in the open and the compiler was proprietary (although the front-end became open source at one point). Those two things (especially the former) pretty much killed it for me. D finally matured at a time where I was already more interested and invested in the Lisp/ML family of languages, thus I ended up never considering it for a project.
mbell 12y ago
I keep seeing a lot of 'Rust vs Go' discussions, including in this thread. To me they seem to be targeted at different use cases. i.e. Rust is a C level replacement for low level direct memory access coding while Go is a garbage collected Java replacement for infrastructure level programming. I'm curious to hear what similar use cases people are using as a basis for directly comparing them.
- kibwen 12y ago
  I have been trying to discourage Go vs. Rust comparisons since time immemorial, given their wildly different purposes and audiences. The eagerness to compare the two seems to stem primarily from 1) both market themselves as "systems" languages (though the vagueness of that term makes this a tenuous connection), 2) both have a focus on concurrency (though in the year 2014, if your language doesn't have a great concurrency story, you've already lost), and 3) the tech crowd seems to adore the imagined narrative of Google vs. Mozilla (though both languages are somewhat disconnected from their backing companies). As a Rust follower, I would really love to see more comparisons to C++, Erlang, and Ada.
  - jsmthrowaway 12y ago
    None of those reasons apply to me, and I think you're overlooking a simple one: As an SRE, I compare them because I'm looking for the next language to adopt as my primary systems/infrastructure language. I have enough issues with C++11 and Python in large systems that I'm looking for an expressive language in which I can work fast and build robust systems. Go and Rust are the finalists for that, with Python keeping the scripting side. Go just happened to finish first. And, I think they both target the same use cases, they just adopted a different mind set on the way there. Most outsiders to Google don't realize this, but Go expresses volumes about the way that Google works internally. And, as with Protocol Buffers, the really awesome stuff in the technology was held back; any Googler will tell you that Go inside the veil is a vastly different experience because of the language-agnostic systems that Google has built internally. At the end of the day, I want a language to write the various tools and systems I need in my SRE life. I've had a hodgepodge until now, and Go is appealing because I can centralize on one (with one toolchain). Rust is becoming more palatable every day.
eklavya 12y ago
There might be some reasons to have <> instead of [] for specifying Type arguments (I think [] are a lot easier to read). I can't fathom the reasoning behind choosing "::" instead of a ".".
- steveklabnik 12y ago
  I'm not sure what you're saying here, do you mean like in 'std::gc::Gc<T>' ? Using :: to indicate a submodule has tons and tons of precedent. The only prominent example I can think of is PHP, and there was a ton of outrage when it didn't use ::.
  - eklavya 12y ago
    Something has precedent doesn't mean you ought to do it. kibwen explains the reason above.
    - steveklabnik 12y ago
      While this is true, that doesn't mean precedent is irrelevant. While what kiwiben said is true, https://github.com/rust-lang/rfcs/pull/148#issuecomment-47718999 https://github.com/rust-lang/rfcs/pull/148#issuecomment-4771...
  - kibwen 12y ago
    Language design error: syntax error, expected T_PAAMAYIM_NEKUDOTAYIM
  - dbaupp 12y ago
    I maybe be remembering some of these wrong, but I think these don't use :: (mostly . instead): Java, C#, Haskell, Clojure.
    - mercurial 12y ago
      I don't know about Clojure, but . in Java is ambiguous in the grammar, since it's also used for method calls. And . is function composition in Haskell. I can understand why Rust would want a different sigil.
Symmetry 12y ago
Man, last time I checked in on Rust one of the things that I didn't like was that the rules for what was public or private by default were complicated for no good reason. Now (maybe .11, maybe a previous change) everything is private by default which is nice and simple. I did and continue to really like the way they handle encapsulation at the module rather than object level.
kibwen 12y ago
Aside from the removal of the ~ and @ sigils (an enormously impressive effort, btw), I'm actually much more excited for the next Rust release. 0.11 contains at least a few long-awaited and hugely-important features which are only half-implemented. Specifically, both DST and by-value closures should be ready for use by the time 0.12 rolls around. We also have some very exciting RFCs in the pipe, such as https://github.com/rust-lang/rfcs/pull/141 https://github.com/rust-lang/rfcs/pull/141 , which would make it possible to remove 90% of the lifetime parameters from our function signatures. Also, with Steve Klabnik now working full-time on documentation and Yehuda Katz's team working on our package manager, our ecosystem will soon be much more potent. Great job, Rust developers! As ever, the challenge is to keep it up. :)
- haberman 12y ago
  > DST This appears to be "dynamically-sized types", for people who aren't in the know: http://blog.babelmonkeys.de/2014/03/18/dst.html http://blog.babelmonkeys.de/2014/03/18/dst.html
- grayrest 12y ago
  > at least a few long-awaited and hugely-important features which are only half-implemented I look forward to a Rust release that doesn't have these. :) I've been tracking the language since the 0.5 (ish) timeframe and the language is a lot more ergonomic than it used to be but the frequent major shifts in how day to day Rust code is written make it tough to follow for a casual observer like myself (I follow /r/rust and write toy code every point release). Salute to the Rust devs and for those of you that work at relating the language to the rest of us. The language looks better every release.
  - DAddYE 12y ago
    I agree with you, but AFAIK this is the first time we are part of a real "open development" of a programming language backed by a big company. It's very rare see clever coders change their mind when someone suggest a different approach. I'm glad this is happening and I wish more could follow.
- 12y ago
Dewie 12y ago
So there has been what seems to be a lot of attention on high level performant languages lately; Rust, Go, Nimrod, D. Languages that can provide performance in the ballpark of C, or at least faster than a lot of other high level languages. High level languages that still keep an eye on what can be implemented efficiently. But I wonder; if these newer 'systems' (which we can define to be very performant, though not necessarily C-level performant) languages are so interesting, why don't any of the older systems languages come up? Like Free Pascal or Ada (I think this language is a 'systems' language in this sense?). Are these languages viable today, if you already can afford to use relatively new languages with all that that entails of lacking libraries etc.? Or are they dead ends? It seems weird to me that when talking about these languages, there seems to just be C/++ and these newer languages, while the older performant languages seem to not come up. Is this because they aren't suitable for most people, or because people don't know about them/forgot about them? I don't know myself, since they seldom seem to come up in discussions on forums like this.
- cmrx64 12y ago
  One of Rust's goals is being as fast or faster than C. Not ballpark, but actually competing. Personally I'm a big fan of Pascal, and I look to Ada sometimes for inspiration (it brought a lot to the table!), but it's quite clear historically that these languages petered off and simply won't get enough momentum to become popular again.
  - Dewie 12y ago
    > One of Rust's goals is being as fast or faster than C. Not ballpark, but actually competing. I was talking about them in aggregate, and not all of them seem to have that goal.
    - cmrx64 12y ago
      And I think that that is one of the things that sets Rust apart.
- chipsy 12y ago
  I think the key is in whether these languages get the backing of a Big Institution. Tech people are simultaneously sensitive and oblivious to the political nature of what technologies interest them: For example, all the coverage of Swift is because Apple is backing it. All the coverage of Go is because it has some famous people behind it plus the tacit support of Google. All the coverage of Rust is because it's backed by Mozilla. But when asked directly about their interest most coders will proclaim that it's simply because the technology in these things is better, even though there were plenty of languages that had similar features and implementation quality beforehand. Nobody - especially not people caught within the politics of their own company - has the time or depth of experience to be completely confident about what they would need from a new language and why, so social signalling and appeal to authority tends to rule the day: "No one ever got fired for buying IBM." And so, intentionally or no, people come out of the woodwork to position themselves as early adopters of the "next IBM." That said, in the long run I think the APIs and tooling experience matters. Free Pascal basically hangs on because Delphi did so well as a third-party environment, even though it was always marginalized on Windows for not being a Microsoft-anointed language. But the Delphi experience was related to the era of the Windows desktop application, and when the market's interest moved away from that the magic was kind of lost. Ada likewise has hung on because it has that gov/mil influence behind it - and its ecosystem is still mostly centered around commercial development environments.
jamesfisher 12y ago
I love that when I read the changelogs for Rust releases, most changes are "Feature X has been removed from the language". These guys are serious about avoiding featuritis.
- pekk 12y ago
  Agreed, though it would be better not to have added the features to begin with.
  - kibwen 12y ago
    If a feature gets added, it is to evaluate its usefulness. Some features make the cut, some don't. Even the ones that don't pan out are useful in that they establish precedent for people who ask for that feature later on; we need only tell them "we tried that, it didn't work out, and here are all of our notes and discussions documenting our reasons why".
    - pekk 12y ago
      If a feature gets released, it is for people to use it. A judicious hand with features saves a lot of trouble down the line. If you are adding too many features you get a big pile of features like C++. I don't see how it is worth arguing that people developing something like a programming language need to very carefully weigh these decisions instead of throwing everything at the wall to see if it sticks. The main reason to load up on features is that you are anxious your audience won't like you unless you do, but it is a wrong idea about design.
      - kibwen 12y ago
        You completely misjudge the Rust developers. Features are carefully weighed before implementation. Developer time is not infinite. But ultimately some decisions can only be made with experience, and sometimes (thanks to the domino-effect nature of language design) previous decisions need to be reevaluated as entirely separate parts of the language change. If this were C++, we would have left all those features in rather than taking the trouble to purge them.
magg 12y ago
i would really like to use rust for a project. but i don't know what i can do with it. any ideas? or which project can i join to work with rust?
- steveklabnik 12y ago
  > i don't what i can do with it. any ideas? Well, like any turing-complete language, technically anything, though Rust tends to be lower-level than most. What kinds of programming do you like to do?
  - magg 12y ago
    I've used Ruby and Python and PHP for web related projects. I've used C for low level programming, Linux modules and SCADA programming running on QNX. So I guess I like pretty high level and low level programming
    - steveklabnik 12y ago
      Well, there are a number of web frameworks being worked on, maybe checking them out and helping out would be a good idea? https://github.com/iron/iron https://github.com/iron/iron was on HN asking for help the other day.
- rmc 12y ago
  Work through project euler?
parley 12y ago
A really important (I think) point with regards to all the comparisons to Go and other similar languages that pop up in every Rust post: Many seem to think that only Rust is suitable for kernelspace but are questioning whether Go or Rust is more suitable in userspace. A Go library will work in a Go process (due to the need for (shared) GC in the runtime, among other things), whereas a Rust library that avoids GC (which is idiomatic Rust) will (I think!) be able to expose an interface akin to a C library (similar calling conventions, internal data type layout like C, etc), making it usable from practically any language with C-FFI. Personally, this is one of the things I look forward to the most. We can create drop-in replacements for C libraries, creating a safer (but just as fast) world one library at a time. And if so desired, all the functionality will be available to anything that can interface with C. Even Go. Your Go libs are stuck in Go's universe. Your Rust libs can be made available to anything that can bind to C. Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom. Rust can eat the cake from the very bottom (bare metal/kernelspace and up), but just like Go, the sky's the limit - and for many reasons, like e.g. even better constraints on shared data than Go has, I personally believe it will go even "higher". My two cents. And as always: More knowledgeable Rust people, if I'm wrong, please correct me.
- steveklabnik 12y ago
  > (I think!) You are correct. The third production deployment of Rust is a Ruby gem written in Rust.
- pcwalton 12y ago
  Brad Fitzpatrick has suggested in one of his talks that Go is interested in being embeddable as well, so I'm excited to see that. I have no doubt they'll do an awesome job. It's really designed to be a first-class citizen from the ground up in Rust, though. Having no GC, precise control over stack vs. heap allocations, support for native calling conventions, a pluggable runtime, and a very fast FFI helps with that.
  - enneff 12y ago
    Now that "embedded" is being redefined to include ARM processors, we have already seen Go in such contexts. This is a great talk: https://www.youtube.com/watch?v=a4BQRUpQoe8 https://www.youtube.com/watch?v=a4BQRUpQoe8 We'll never see Go on 16-bit architectures or smaller, though.

207 points by veeti 12y ago

I'm mostly doing Go nowadays but keeping an eye on Rust, which I think would make a good match in my toolbox for areas where Go lacks. Wondering if there's a roadmap/ETA for v1.0?

TheHydroImpulse 12y ago
They're shooting for around the end of this year.
sp332 12y ago
I found this roadmap https://docs.google.com/spreadsheet/ccc?key=0AlWBWplsaTZvdGdSdEVzZW1BeDA5dm0zM2FFeW0ySEE&usp=drive_web#gid=0 https://docs.google.com/spreadsheet/ccc?key=0AlWBWplsaTZvdGd...
- steveklabnik 12y ago
  That Google doc has not been updated in a while. Also https://github.com/rust-lang/rust/issues?direction=desc&milestone=20&page=1&sort=updated&state=open https://github.com/rust-lang/rust/issues?direction=desc&mile... and https://github.com/rust-lang/rust/issues?direction=desc&labels=P-backcompat-lang&milestone=20&page=1&sort=updated&state=open https://github.com/rust-lang/rust/issues?direction=desc&labe... , which are the most interesting open questions regarding backwards compatibility.

kbd 12y ago

I love all the "X has been removed from the language" bits that occur in every Rust release.

adwhit 12y ago

I think Rust has been bad for me. I'm interviewing for my first technical role at the moment and all I keep talking about is how much I love Rust and look at these cool things I made in Rust and I want to program in Rust all the time. I mainly receive bemused looks. "We use Java."

pjmlp 12y ago
If you are applying to the enterprise that won't change in foreseeable future. Worse, Java really means Java and not any alternative language for the JVM.
- shmerl 12y ago
  > If you are applying to the enterprise that won't change in foreseeable future. That depends. Not all are bought on the Java hype from the past but it surely is still widespread.
  - pjmlp 12y ago
    The remaining ones are on .NET. At least on my little spot in the World.
  - kibwen 12y ago
    > Not all are bought on the Java hype It's true, my venerable enterprise company prefers RPG-IV and PHP. :)
ossreality 12y ago
Run, run away. I still have to use the tools my team uses, but at least I work with people who are interested in something better.
Mr_P 12y ago
You could try looking for positions doing C++ development, and specifically with companies which have embraced the new C++11 features. Rust is extremely close in style to idiomatic modern C++, but with greater static safety guarantees.
- humanrebar 12y ago
  Runtime polymorphism is very different in Rust, and sum types are prolific in the standard library, so I'm not sure how "extremely close" it is to C++11. But there are many similarities in other areas, such as memory safety through references with ownership semantics.

lvillani 12y ago

I'm eagerly awaiting Rust 1.0 to play with it. These days I'm dabbling with Go and while the toolchain is fantastic and the standard library is fairly comprehensive, I find the language itself to be "meh". Rust-the-language looks much more promising but I'm holding my breath waiting until it stabilises before I consider it for my next project. I read elsewhere that they are striving for a near-final release at the end of the year so I won't have to wait long, after all :) Keep it up!

tbirdz 12y ago
In the mean time you might want to check out Nimrod or D. These are some other languages in a similar space - compiling to native binaries, but with the amenities of modern languages.
- egeozcan 12y ago
  These are the exact two languages I want to see prosper. Most important reason is that I want to keep believing that a (bunch of) genius(es) inventing their perfect language that can be practically and widely used without a big company backing is still a thing Secondly because these languages have so many great ideas with high quality implementations.
  - jsmthrowaway 12y ago
    The other side of that is that D has had a long time to percolate and hasn't found the success of Go, and soon Rust. So, we come back to the common startup ailment, which is having an awesome product but it just inexplicably doesn't get traction, while the inferior (depending on perspective) product does. I know there are pockets of D throughout the industry. I know it's catching on at Facebook (and, because I know Facebook folks, I know what an uphill battle those folks are having too). I just don't hear about D nearly as much as I'd expect to over a decade in. Nothing against D, mind.
    - lvillani 12y ago
      In my opinion the fact that there were two competing standard libraries (Tango and Phobos) certainly brought confusion and needlessly fragmented the community. IIRC, at the beginning the whole thing was not being developed in the open and the compiler was proprietary (although the front-end became open source at one point). Those two things (especially the former) pretty much killed it for me. D finally matured at a time where I was already more interested and invested in the Lisp/ML family of languages, thus I ended up never considering it for a project.

mbell 12y ago

I keep seeing a lot of 'Rust vs Go' discussions, including in this thread. To me they seem to be targeted at different use cases. i.e. Rust is a C level replacement for low level direct memory access coding while Go is a garbage collected Java replacement for infrastructure level programming. I'm curious to hear what similar use cases people are using as a basis for directly comparing them.

kibwen 12y ago
I have been trying to discourage Go vs. Rust comparisons since time immemorial, given their wildly different purposes and audiences. The eagerness to compare the two seems to stem primarily from 1) both market themselves as "systems" languages (though the vagueness of that term makes this a tenuous connection), 2) both have a focus on concurrency (though in the year 2014, if your language doesn't have a great concurrency story, you've already lost), and 3) the tech crowd seems to adore the imagined narrative of Google vs. Mozilla (though both languages are somewhat disconnected from their backing companies). As a Rust follower, I would really love to see more comparisons to C++, Erlang, and Ada.
- jsmthrowaway 12y ago
  None of those reasons apply to me, and I think you're overlooking a simple one: As an SRE, I compare them because I'm looking for the next language to adopt as my primary systems/infrastructure language. I have enough issues with C++11 and Python in large systems that I'm looking for an expressive language in which I can work fast and build robust systems. Go and Rust are the finalists for that, with Python keeping the scripting side. Go just happened to finish first. And, I think they both target the same use cases, they just adopted a different mind set on the way there. Most outsiders to Google don't realize this, but Go expresses volumes about the way that Google works internally. And, as with Protocol Buffers, the really awesome stuff in the technology was held back; any Googler will tell you that Go inside the veil is a vastly different experience because of the language-agnostic systems that Google has built internally. At the end of the day, I want a language to write the various tools and systems I need in my SRE life. I've had a hodgepodge until now, and Go is appealing because I can centralize on one (with one toolchain). Rust is becoming more palatable every day.

eklavya 12y ago

There might be some reasons to have <> instead of [] for specifying Type arguments (I think [] are a lot easier to read). I can't fathom the reasoning behind choosing "::" instead of a ".".

steveklabnik 12y ago
I'm not sure what you're saying here, do you mean like in 'std::gc::Gc<T>' ? Using :: to indicate a submodule has tons and tons of precedent. The only prominent example I can think of is PHP, and there was a ton of outrage when it didn't use ::.
- eklavya 12y ago
  Something has precedent doesn't mean you ought to do it. kibwen explains the reason above.
  - steveklabnik 12y ago
    While this is true, that doesn't mean precedent is irrelevant. While what kiwiben said is true, https://github.com/rust-lang/rfcs/pull/148#issuecomment-47718999 https://github.com/rust-lang/rfcs/pull/148#issuecomment-4771...
- kibwen 12y ago
  Language design error: syntax error, expected T_PAAMAYIM_NEKUDOTAYIM
- dbaupp 12y ago
  I maybe be remembering some of these wrong, but I think these don't use :: (mostly . instead): Java, C#, Haskell, Clojure.
  - mercurial 12y ago
    I don't know about Clojure, but . in Java is ambiguous in the grammar, since it's also used for method calls. And . is function composition in Haskell. I can understand why Rust would want a different sigil.

Symmetry 12y ago

Man, last time I checked in on Rust one of the things that I didn't like was that the rules for what was public or private by default were complicated for no good reason. Now (maybe .11, maybe a previous change) everything is private by default which is nice and simple. I did and continue to really like the way they handle encapsulation at the module rather than object level.

kibwen 12y ago

Aside from the removal of the ~ and @ sigils (an enormously impressive effort, btw), I'm actually much more excited for the next Rust release. 0.11 contains at least a few long-awaited and hugely-important features which are only half-implemented. Specifically, both DST and by-value closures should be ready for use by the time 0.12 rolls around. We also have some very exciting RFCs in the pipe, such as https://github.com/rust-lang/rfcs/pull/141 https://github.com/rust-lang/rfcs/pull/141 , which would make it possible to remove 90% of the lifetime parameters from our function signatures. Also, with Steve Klabnik now working full-time on documentation and Yehuda Katz's team working on our package manager, our ecosystem will soon be much more potent. Great job, Rust developers! As ever, the challenge is to keep it up. :)

haberman 12y ago
> DST This appears to be "dynamically-sized types", for people who aren't in the know: http://blog.babelmonkeys.de/2014/03/18/dst.html http://blog.babelmonkeys.de/2014/03/18/dst.html
grayrest 12y ago
> at least a few long-awaited and hugely-important features which are only half-implemented I look forward to a Rust release that doesn't have these. :) I've been tracking the language since the 0.5 (ish) timeframe and the language is a lot more ergonomic than it used to be but the frequent major shifts in how day to day Rust code is written make it tough to follow for a casual observer like myself (I follow /r/rust and write toy code every point release). Salute to the Rust devs and for those of you that work at relating the language to the rest of us. The language looks better every release.
- DAddYE 12y ago
  I agree with you, but AFAIK this is the first time we are part of a real "open development" of a programming language backed by a big company. It's very rare see clever coders change their mind when someone suggest a different approach. I'm glad this is happening and I wish more could follow.
12y ago

Dewie 12y ago

So there has been what seems to be a lot of attention on high level performant languages lately; Rust, Go, Nimrod, D. Languages that can provide performance in the ballpark of C, or at least faster than a lot of other high level languages. High level languages that still keep an eye on what can be implemented efficiently. But I wonder; if these newer 'systems' (which we can define to be very performant, though not necessarily C-level performant) languages are so interesting, why don't any of the older systems languages come up? Like Free Pascal or Ada (I think this language is a 'systems' language in this sense?). Are these languages viable today, if you already can afford to use relatively new languages with all that that entails of lacking libraries etc.? Or are they dead ends? It seems weird to me that when talking about these languages, there seems to just be C/++ and these newer languages, while the older performant languages seem to not come up. Is this because they aren't suitable for most people, or because people don't know about them/forgot about them? I don't know myself, since they seldom seem to come up in discussions on forums like this.

cmrx64 12y ago
One of Rust's goals is being as fast or faster than C. Not ballpark, but actually competing. Personally I'm a big fan of Pascal, and I look to Ada sometimes for inspiration (it brought a lot to the table!), but it's quite clear historically that these languages petered off and simply won't get enough momentum to become popular again.
- Dewie 12y ago
  > One of Rust's goals is being as fast or faster than C. Not ballpark, but actually competing. I was talking about them in aggregate, and not all of them seem to have that goal.
  - cmrx64 12y ago
    And I think that that is one of the things that sets Rust apart.
chipsy 12y ago
I think the key is in whether these languages get the backing of a Big Institution. Tech people are simultaneously sensitive and oblivious to the political nature of what technologies interest them: For example, all the coverage of Swift is because Apple is backing it. All the coverage of Go is because it has some famous people behind it plus the tacit support of Google. All the coverage of Rust is because it's backed by Mozilla. But when asked directly about their interest most coders will proclaim that it's simply because the technology in these things is better, even though there were plenty of languages that had similar features and implementation quality beforehand. Nobody - especially not people caught within the politics of their own company - has the time or depth of experience to be completely confident about what they would need from a new language and why, so social signalling and appeal to authority tends to rule the day: "No one ever got fired for buying IBM." And so, intentionally or no, people come out of the woodwork to position themselves as early adopters of the "next IBM." That said, in the long run I think the APIs and tooling experience matters. Free Pascal basically hangs on because Delphi did so well as a third-party environment, even though it was always marginalized on Windows for not being a Microsoft-anointed language. But the Delphi experience was related to the era of the Windows desktop application, and when the market's interest moved away from that the magic was kind of lost. Ada likewise has hung on because it has that gov/mil influence behind it - and its ecosystem is still mostly centered around commercial development environments.

jamesfisher 12y ago

I love that when I read the changelogs for Rust releases, most changes are "Feature X has been removed from the language". These guys are serious about avoiding featuritis.

pekk 12y ago
Agreed, though it would be better not to have added the features to begin with.
- kibwen 12y ago
  If a feature gets added, it is to evaluate its usefulness. Some features make the cut, some don't. Even the ones that don't pan out are useful in that they establish precedent for people who ask for that feature later on; we need only tell them "we tried that, it didn't work out, and here are all of our notes and discussions documenting our reasons why".
  - pekk 12y ago
    If a feature gets released, it is for people to use it. A judicious hand with features saves a lot of trouble down the line. If you are adding too many features you get a big pile of features like C++. I don't see how it is worth arguing that people developing something like a programming language need to very carefully weigh these decisions instead of throwing everything at the wall to see if it sticks. The main reason to load up on features is that you are anxious your audience won't like you unless you do, but it is a wrong idea about design.
    - kibwen 12y ago
      You completely misjudge the Rust developers. Features are carefully weighed before implementation. Developer time is not infinite. But ultimately some decisions can only be made with experience, and sometimes (thanks to the domino-effect nature of language design) previous decisions need to be reevaluated as entirely separate parts of the language change. If this were C++, we would have left all those features in rather than taking the trouble to purge them.

magg 12y ago

i would really like to use rust for a project. but i don't know what i can do with it. any ideas? or which project can i join to work with rust?

steveklabnik 12y ago
> i don't what i can do with it. any ideas? Well, like any turing-complete language, technically anything, though Rust tends to be lower-level than most. What kinds of programming do you like to do?
- magg 12y ago
  I've used Ruby and Python and PHP for web related projects. I've used C for low level programming, Linux modules and SCADA programming running on QNX. So I guess I like pretty high level and low level programming
  - steveklabnik 12y ago
    Well, there are a number of web frameworks being worked on, maybe checking them out and helping out would be a good idea? https://github.com/iron/iron https://github.com/iron/iron was on HN asking for help the other day.
rmc 12y ago
Work through project euler?

parley 12y ago

A really important (I think) point with regards to all the comparisons to Go and other similar languages that pop up in every Rust post: Many seem to think that only Rust is suitable for kernelspace but are questioning whether Go or Rust is more suitable in userspace. A Go library will work in a Go process (due to the need for (shared) GC in the runtime, among other things), whereas a Rust library that avoids GC (which is idiomatic Rust) will (I think!) be able to expose an interface akin to a C library (similar calling conventions, internal data type layout like C, etc), making it usable from practically any language with C-FFI. Personally, this is one of the things I look forward to the most. We can create drop-in replacements for C libraries, creating a safer (but just as fast) world one library at a time. And if so desired, all the functionality will be available to anything that can interface with C. Even Go. Your Go libs are stuck in Go's universe. Your Rust libs can be made available to anything that can bind to C. Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom. Rust can eat the cake from the very bottom (bare metal/kernelspace and up), but just like Go, the sky's the limit - and for many reasons, like e.g. even better constraints on shared data than Go has, I personally believe it will go even "higher". My two cents. And as always: More knowledgeable Rust people, if I'm wrong, please correct me.

steveklabnik 12y ago
> (I think!) You are correct. The third production deployment of Rust is a Ruby gem written in Rust.
pcwalton 12y ago
Brad Fitzpatrick has suggested in one of his talks that Go is interested in being embeddable as well, so I'm excited to see that. I have no doubt they'll do an awesome job. It's really designed to be a first-class citizen from the ground up in Rust, though. Having no GC, precise control over stack vs. heap allocations, support for native calling conventions, a pluggable runtime, and a very fast FFI helps with that.
- enneff 12y ago
  Now that "embedded" is being redefined to include ARM processors, we have already seen Go in such contexts. This is a great talk: https://www.youtube.com/watch?v=a4BQRUpQoe8 https://www.youtube.com/watch?v=a4BQRUpQoe8 We'll never see Go on 16-bit architectures or smaller, though.