Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
posted by takyon on Friday May 15 2015, @10:30PM   Printer-friendly
from the already-rusty dept.

After many years of waiting, version 1.0 of the Rust programming language has finally been released. The Rust home page describes Rust as "a systems programming language that runs blazingly fast, prevents nearly all segfaults, and guarantees thread safety."

Thanks to the hard work of noted Rust core team members Yehuda Katz and Steve Klabnik, Rust is now poised to become a serious competitor to established systems programming languages like C and C++.

The announcement has brought much jubilation to the followers of Rust, who have been eagerly awaiting this milestone release for so long. With only 1,940 open issues and over 11,500 issues already closed, Rust is finally ready for users to build fantastically reliable software systems using it.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Interesting) by Anonymous Coward on Saturday May 16 2015, @05:19AM

    by Anonymous Coward on Saturday May 16 2015, @05:19AM (#183657)

    You gain modules and their related compile time improvements

    The module system is nowhere near as flexible as the options that C++ allows for, both file-based and in terms of namespaces and classes. Besides, all modern C++ compilers have supported precompiled headers for ages, which drastically improves compilation time.

    better option/union type support with pattern matching

    After using this in Haskell and Scala, it's useful, but not that useful. Much of this can be done using C++'s templates well enough.

    compiler enforced thread safety/no data races

    This is only as good as the language implementation is. Rust is a language with a single implementation with almost 2,000 open issues. If the implementation is so broken, how can I be sure that whatever the compiler is enforcing is being done correctly?

    more robust templates with better errors

    I don't think that's true. C++'s templates are quite robust and powerful already. Rust doesn't really improve on that. Modern C++ compilers, especially Clang, offer very comprehensible and useful template error messages these days. Even GCC is getting better.

    not needing header files

    Header files aren't a bad thing. They're quite powerful.

    simpler syntax

    Rust's syntax is very similar to C++'s. C++'s syntax is generally quite straightforward. Even C++'s semantics are quite easy, compared to stuff like Rust's ownership semantics.

    In closing, it has taken Rust years to get to this point, and there's not much to show for it. I don't think we'll see any miracles that suddenly allow it to become any better than it already is (or isn't).

    Starting Score:    0  points
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  

    Total Score:   1  
  • (Score: 1, Interesting) by Anonymous Coward on Saturday May 16 2015, @05:57AM

    by Anonymous Coward on Saturday May 16 2015, @05:57AM (#183669)

    Regarding your comment on thread safety: the threading/sync stuff is actually a library feature (they rewrote it to be such recently). Rust's owner ship semantics are enough to make that possible. Fixing the few remaining holes in the compiler soundness checks should be easier than fixing even one large C++ project, and it will fix all the rust projects.

    As for templates: personally I like that that templates only validate once: you can't have a compile error in a particular instantiantion, and its clear what types are legal to paramaterize it with.

    If you like header files and get along well with precompiled headers, stick with your c++. I'm just happy I can call your code from rust :)

    C++ is a great language if you are a badass, but I'm much rather hire devs to write me rust than C++ where there is so much less shit they can get wrong. I could trust interns to write secure multithreaded code thats performant (Don't do that in most languages). Its also far harder to break when refactoring (The completeness guarantees on match are one such example).

    • (Score: 0) by Anonymous Coward on Saturday May 16 2015, @01:03PM

      by Anonymous Coward on Saturday May 16 2015, @01:03PM (#183741)

      Rust's owner ship semantics are enough to make that possible.

      Rust's ownership semantics will leave you scratching your head, and then once you finally understand how it's supposed to work, you'll still end up fighting the compiler.

  • (Score: 4, Insightful) by maxwell demon on Saturday May 16 2015, @07:22AM

    by maxwell demon (1608) on Saturday May 16 2015, @07:22AM (#183680) Journal

    C++'s syntax is generally quite straightforward.

    I disagree with this. It shows on many places that the C syntax on which it builds simply wasn't made for it, and some added syntax also is not exactly helpful.

    Consider the following code, and think about why you need the bolded keywords:

    template<typename T, typename U> typename T::value_type f(T t, U u)
    {
          T foo(U()); // C++'s most vexing parse; do you see what's wrong?
          return foo.template frobnicate<int>(u);
    }

    Don't get me wrong, C++ is the best language I know. But its syntax is not its strong point.

    --
    The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 2) by tonyPick on Saturday May 16 2015, @08:01AM

      by tonyPick (1237) on Saturday May 16 2015, @08:01AM (#183687) Homepage Journal

      Templates can lead to some really odd cases: See also this blog post [reverberate.org].

      Responding to the GP point: C++ syntax can be straightforward provided you only use a subset of the features; however nobody can agree on what that subset is, and as soon as you use someone else's code/library then the complexity explodes. The C++ standards approach of "throw another feature into the mix" isn't helping any.