Follow Slashdot stories on Twitter


Forgot your password?
Programming Technology

Rust 1.0 Released 149

TopSpin writes: Rust 1.0 has arrived, and release parties in Paris, LA and San Francisco are taking place today. From the Rust Programming Language blog: "The current Rust language is the result of a lot of iteration and experimentation. The process has worked out well for us: Rust today is both simpler and more powerful than we originally thought would be possible. But all that experimentation also made it difficult to maintain projects written in Rust, since the language and standard library were constantly changing. The 1.0 release marks the end of that churn. This release is the official beginning of our commitment to stability, and as such it offers a firm foundation for building applications and libraries. From this point forward, breaking changes are largely out of scope (some minor caveats apply, such as compiler bugs)." You can read about specific changes in the changelog.
This discussion has been archived. No new comments can be posted.

Rust 1.0 Released

Comments Filter:
  • by Anonymous Coward

    So why should I use Rust instead of the languages I'm currently using (Ada and Racket)?

    • by uncqual ( 836337 )

      Because it's shiny? Oh, wait, that can't be it.

  • From the headline, I thought it was Rust the game.... Then I thought, typical of /. to be way behind on a story as Rust the game hit 1.0 a while ago. If you haven't played Rust (the game) it is way more fun then Rust the language.
  • by HannethCom ( 585323 ) on Friday May 15, 2015 @03:28PM (#49700049)
    Rust is old and creaky. Now introducing Shiny! It is the programming language that gets rid of all cruft of Rust and adds a layer of NICKEL (Non-Intrusive Code Keying for Easy Learning) to make your programs shine forever. It is a high level language that anyone can learn to code in, but brings almost assembly level of performance.

    Get Started Coding Today! []
  • by Anonymous Coward

    Rust would have been useful 5 years ago. But now there is no reason to use it. Go, C++14, Ada 2012, OCaml, D, Scala, and even C# (now that core .NET code has been opened sourced and ported to non-Windows systems) offer everything Rust does, plus more. Somebody will probably claim that Rust "isn't competing with those languages", but in reality it is, and it's way behind them. Rust could have been a game changer, but like Perl 6 its developers just couldn't get a stable major release out on a reasonable sche

  • by __aaclcg7560 ( 824291 ) on Friday May 15, 2015 @03:57PM (#49700269)
    Job postings for Rust on Dice will require five years of experience for a programming language that came out six months ago.
    • Rust has been worked on internally at Mozilla since 2009, was publicly announced in 2010 and had it's earliest pre-release alphas in 2012. It's hardly only been out for 6 months.

      • That's what they said about Swift.
        • Great, for "them". What exactly is the relevance?

          • Whenever a new technology comes out, recruiters will require five years of experience. The only people who would remotely qualified for five years of experience are the people worked on the new technology. By the time everyone hears about it (I haven't heard of Rust until today), six months will have gone by.
            • No, people have been able to use Rust as an alpha-quality language for pet projects for going on 3 years now. Just because you only heard of it today doesn't mean the rest of us did.

        • To add, unlike Swift Rust has been publicly being developed on Github since 2010. So it doesn't matter what anyone "says" when there is a Public git record [] dating back to their 2010 public announcement about the language. Unless you think Github and the Rust developers faked their git history.

  • by euroq ( 1818100 ) on Friday May 15, 2015 @03:58PM (#49700277)

    They could have made the same simple concepts without going C++ style. This is obviously just aesthetics, but I don't think the language looks nice compared to lots of newer languages (Swift, Ruby, Kotlin, and even D).

    The :: scope operator is ugly and redundant.

    This match syntax is just ugly and hard to type:

        match header[0] {
                    1 => Ok(Version::Version1),
                    2 => Ok(Version::Version2),
                    _ => Err(ParseError::InvalidVersion)

    The following is ugly and is not obvious:

    use std::sync::{Arc, Mutex};
    use std::thread;
    use std::sync::mpsc;

    fn main() {
            let data = Arc::new(Mutex::new(0u32));

            let (tx, rx) = mpsc::channel();

            for _ in 0..10 {
                    let (data, tx) = (data.clone(), tx.clone());

                    thread::spawn(move || {
                            let mut data = data.lock().unwrap();
                            *data += 1;


            for _ in 0..10 {

    A simple printf function has to be a macro, because the techniques it uses are unsafe which is a main feature of the language.

    OK a lot of these gripes are trivial; I guess I'm getting at the fact that they went an academic route about how to deal with pointers and memory allocation safely, and then built everything around that. It was so academic and engineering-like and they didn't think or try very hard about the design and aesthetics.

    • Looking at the documentation.

      $ rustc --version

      This clearly looks like a rusted version of the C programming language. Move along, nothing to see.

    • by Etcetera ( 14711 )

      They could have made the same simple concepts without going C++ style. This is obviously just aesthetics, but I don't think the language looks nice compared to lots of newer languages (Swift, Ruby, Kotlin, and even D).

      The :: scope operator is ugly and redundant.

      This match syntax is just ugly and hard to type:

      Honestly, if you're going to throw syntax open to a full re-evaluation, I'd much prefer something like perl6. It may seem convoluted, but at least it's been designed by a linguist and has an internal coherence. It also provides enough of a hint as to what the programmer is intending that a (future) perl6 compiler should be able to optimize the heck out of it.

    • But on simple examples I like that macros are identified with a bang, like this : println!
      It's daunting that in a language you might encounter some name, but don't know if it's a real function, or a macro, or something that was overloaded.
      As for the :: operator I simply don't know what the fuck it means. dunno if it's ugly or not, but means that I would have to learn what it means, and why it's not just a ".".

    • by tgv ( 254536 )

      > A simple printf function has to be a macro

      I don't see anything wrong with that. Actually, it sounds quite sensible: it gets rid of some ugly variable arguments handling code, but still keeps the source readable. For the rest: Rust is an interesting idea, but doesn't look ideal. Apparently, it does not interface well with C++, only C, but mixing with C++ could be a good start. Rewrite some buggy code in Rust where it makes sense while keeping the rest in C++.

      • by euroq ( 1818100 )

        What I mean with that is that the language was designed with certain safety mechanisms involved. However, in order to do something as simple (maybe simple isn't the right word, but common) as the printf function, you have to break the standard safety mechanisms. Hence the printf function is a macro, and underneath the hood there is a whole lot of ugliness.

        Now, taking a step back further, I think that it's good that ugliness is hidden behind the scenes. My point is that, if one has to get ugly to do the thin

        • by tgv ( 254536 )

          I see. Printf is a bit of a weird function: perhaps they need a better macro syntax. Expanding at compile time is safe, so a good language for that might overcome (part of) these problems.

          > it will actually become common and necessary to "do ugly things" in order to get stuff done in real-world applications.

          Quite likely. But if that can be kept to a minimum, possibly shielded behind macros and the likes, and the rest of the code can achieve good performance, then we might have won something.

  • From what I can tell RUST was made mostly from the desire to remove the vulnerabilities that C and C++ allow; mostly in the pointer space. So instead of training better coders in C and C++, just make a language that removes those abilities all together.

    Personally, I prefer my programming language to be willing and powerful enough to do whatever I want it to do. That allows me to be more creative and squeeze the most potential out of the code as I want.

    Professionally, I would like to see Mozilla re-write F
    • by Thiez ( 1281866 ) on Friday May 15, 2015 @04:56PM (#49700795)
      You can do whatever you want with pointers (although the things that are UB in C will tend to be UB in Rust also), you just need to do so in an unsafe{ .. } block. The improvement over C/C++ is that you won't trigger UB by accident while using the safe subset of the language, and the vast majority of the time you will be able to do what you want in that subset.
      • Re: (Score:2, Insightful)

        The improvement over C/C++ is that you won't trigger UB by accident while using the safe subset of the language, and the vast majority of the time you will be able to do what you want in that subset.

        I can do the same thing in C++ using a safe subset of it as well without needing to learn a new language and waste man years porting software. No one doing modern C++ should be dealing with raw pointers outside of exceptional cases.

        • by Thiez ( 1281866 )
          Do those smart pointers also solve iterator invalidation? :)
          • Never claimed smart pointers solve all problems because that would be ridiculous. If you have cases that a smart pointer doesn't solve then clearly you would need to use the correct solution. But for the vast majority of cases that people use raw pointers for, they can be substituted with something safer and remove a whole host of potential bugs from their code.

        • by roca ( 43122 )

          There is no useful subset of C++ that is a) statically checkable and b) guarantees absence of dangling pointers and null dereferences.

    • by gweihir ( 88907 )

      Same here. And really, most pointer vulnerabilities go away when you code carefully, and finding the rest with things like Valgrind works well if you actually have thought about testing when you designed your code. And in really critical places, you can always do check-before-use and fail gracefully instead of insecure. Of course, all these things require that you know what you do. Things like Rust are an insult to those of us that do.

      • Plus, they have yet to even prove the fact that Rust is good at what they claim it's made for. C and C++ didn't win over programmers through hype. They won over programmers by being proven through real-world applications. It's easy to talk up a language, it's much harder to back that talk up with real-world results.

        • by gweihir ( 88907 )

          Indeed. And I have the impression that Rust is not nearly that good, and hence an intense marketing campaign is done.

      • by smaddox ( 928261 )

        "Assemblers are an insult to those of us that know what we're doing."
        "High level languages like Fortran and C are an insult to those of us that know what we're doing."
        "High level scripting languages like Bash are an insult to those of us that know what we're doing."
        "High level languages Java are an insult to those of us that know what we're doing."

        • by gweihir ( 88907 )

          Your point? That other people say things that _sound_ like what I said does not invalidate my point in the least.

    • The more the compiler can protect me from past-me, the better. And certainly from my coworkers.

      Look, I don't get how Rust deals with circular references at all (screw you, leak, I think). But the way to train better coders is to get them up on standards. Why you wouldn't want those standards enforced by the compiler I have no idea.

      I read the Rust documentation (what 1/2 or 1/4 or something of it there was). Okay ideas, but not terribly interesting. But if I could snap my fingers and code that didn't me

      • Why you wouldn't want those standards enforced by the compiler I have no idea.

        This reeks of strawman. GP never said or implied any such thing.

        • Why you wouldn't want those standards enforced by the compiler I have no idea.

          This reeks of strawman. GP never said or implied any such thing.

          It certainly is implied that he is against creating languages that enforce certain standards. Note, almost all standards include "Thou shall not"'s for some language features. You practically have to in C++. I mean, I don't know any (modern) standard that would let you pass and cast tons of void*'s around as the standard case.


          So instead of training better code

  • But when I see years of experience in a job posting it usually is like this:

    X years of experience in backend/functional programming/frontend/relational databases like (java/ruby/C#)/(clojure,erlang,scala)/(javascript,html,css)/(oracle,sql server,mysql). Bonus points if you have experience with Y technology.

    Which is sensible, even though rust might be only a couple of years old when you want a senior dev you want one that has been dealing with these kinds of problems for many years, even if most of those yea

  • So, is that like a Python or D commitment to stability, or a C/C++ level commitment to stability? Exactly how committed are they to preserving to preserving backwards compatibility through hell and high water? Because that's why people trust C/C++ - they know that the language committees are not going to suddenly "fix" the language by making billions of lines of code obsolete, simply because it was written fifteen years ago before a bunch of new shiny features have been added.

    I think widespread adoption i

    • by Thiez ( 1281866 ) on Friday May 15, 2015 @05:24PM (#49701049)
      > What will the performance penalties be to optimized C or C++ code? Some of the guarantees that the Rust type-system provides could theoretically allow better optimization than C/C++. For instance, when you have an immutable reference (&something)to a object of a type that does not have internal mutability (that means the vast majority), that object is guaranteed to be immutable for as long as your reference is alive (note that this guarantee is stronger than that offered by a const *). And when you have a mutable reference (&mut something) your pointer is guaranteed not to alias, so once again your object is immutable except for the changes that you choose to make. You could say that all &mut T references are T *restrict. In addition, references in Rust are guaranteed to be non-null. All this extra information offers opportunities for optimization. Note that (AFAIK) not all this information is being communicated to the LLVM back-end at this time. In short, I do not expect performance penalties.
      • Since this is compiled code, the predictions I've heard of "it will perform about as well as C++ if you're using it with the same level of protection as Rust gives" makes sense to me. The implication is that yes, it's going to be a bit slower in the general use case, but if you're writing highly threaded or parallel C/C++ code, then you'd have to manually implement that level of protection anyhow in those languages.

        We'll have to see if that actually pans out in practice or not. I remain slightly skeptical

      • In addition, references in Rust are guaranteed to be non-null.

        As they are in C++. They are also compile-time checked to make sure they have been initialized. It's one of the whole reasons that references exist in C++ and should be used in place of pointers whenever possible.

        • by roca ( 43122 )

          int* p = nullptr;
          int& p2 = *p; // Hello, null reference

          • by Thiez ( 1281866 )

            Not that hard in Rust either:

            let badref: &u32 = unsafe { std::mem::transmute(0 as *const u32)};

            But doing this trick is UB in both C++ and Rust, so it's not really fair to hold it against either language. Having said that, one advantage of Rust would be that it is impossible to create such a bad reference without using an unsafe block, while in C++ it seems much easier to do so by mistake.

            • by mandolin ( 7248 )

              Not disagreeing with you, but a nullptr-to-reference cast would at least crash immediately (unless you have a compiler that takes "undefined behavior" too literally). Here's another contrived example:

              const char *c = std::string("oops").c_str();

              I'm not a c++ expert but I'm pretty sure 'c' now points to freed memory. The real problem is that the code will usually work until a customer runs it. And solutions like valgrind aren't always optimal (consider code coverage and execution speed) or even necessarily

            • by roca ( 43122 )

              Your last sentence sums it up nicely. If you stick to the safe subset of Rust (which is almost the entire language, and enough to write almost all of a high-performance Web browser in, for example) then you can't trigger undefined behaviors, and references that claim to be non-null are guaranteed to really not be null. Escaping from that subset requires you to write the "unsafe" keyword.

              OTOH C++ has nothing like that. It's very very easy in practice for C++ code to accidentally trigger undefined behaviors t

        • by Thiez ( 1281866 )
          But C++ does not allow references to references, arrays of references, and pointers to references. Rust has all these things, while still being able to ensure that the references are valid.
        • As they are in C++.

          No they ain't. Null references are UB, not impossible.

    • by smaddox ( 928261 )

      C and C++ have evolved a ton over the years, and vendor-specific extensions are common (though less so now than in the beginning).

      Rust doesn't need to unseat C/C++, nor should that be its goal (and I don't think it is). It is simply a tool that you can choose to use or choose not to use. Once the remaining bugs are fleshed out, there's a good chance it will be valuable for projects requiring exceptional security.

      Note that it also interoperates fairly easily with C/C++, so you can implement some parts of a p

  • WTF (Score:3, Insightful)

    by Etcetera ( 14711 ) on Friday May 15, 2015 @04:32PM (#49700581) Homepage

    How to tell if you're out hipster-ing your trendy, Brogrammer self:

    Your next-big-thing programming language is having simultaneous release parties Paris, LA and San Francisco.

  • It looks interesting, but they need to work on their documentation. I wasn't able to find anything about reading and writing random access files. It had many things that appear easy to do in Rust which are difficult in various different languages, but I couldn't find a way in which it was notably better overall in any area.

    FWIW I was mainly comparing it against D and Python, with a few considerations of Ruby. I should have compared it against Ada, but it's been too long since I actually used it. I can't

If I had only known, I would have been a locksmith. -- Albert Einstein