Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Programming Software

Rust 1.0 Enters Beta 211

An anonymous reader writes: Rust is a systems programming language focused on safety and speed and aims, among other things, to offer memory safety without garbage collection and threads without data races. Over on the Rust blog, the Rust Core Team has announced the release of Rust 1.0 beta. They write, 'The beta release marks a very significant "state transition" in the move towards 1.0. In particular, with the beta release, all libraries and language features that are planned to be stable for 1.0 have been marked as stable. As such, the beta release represents an accurate preview of what Rust 1.0 will include.' The final Rust 1.0 release is scheduled for May 15th, 2015. A warning from the developers: "Rust is a work-in-progress and may do anything it likes up to and including eating your laundry." The FAQ is worth reading.
This discussion has been archived. No new comments can be posted.

Rust 1.0 Enters Beta

Comments Filter:
  • by umafuckit ( 2980809 ) on Saturday April 04, 2015 @05:34AM (#49403453)
    When Rust becomes a little more polished it will likely become very interesting.
    • by Anonymous Coward

      It's been in development for years. 1.0.0 means it is polished now, at least on the level of the language.

      • by Anonymous Coward

        Have you actually tried using Rust? I have, and I can tell you that it isn't "polished".

        Maybe it won't change as goddamn much as it typically has each day, but it's not a clean language like say Python or C# are.

        Its library API is something awful. You have to write stuff like:

        let path = Path::new(&app_path)
        println!("file name: {}", path.file_name().unwrap().to_str().unwrap());

        The memory management approach is also, to put it nicely, a royal pain in the ass to use. Maybe it can guarantee a higher level o

        • by gweihir ( 88907 )

          Rust is a very tedious and anal language to use, to the point of any safety gains being eliminated by much slower development time.

          Well, with that, it is likely far more efficient to have somebody that does understand both C and secure coding to do things in C. The thing is that Rust cannot eliminate all security problems anyways, and the remaining ones will be much more obscure. It also will introduce problems of its own, just as any language with tight control does, and for some of them, only a fix on the language side will help.

          All in all, I am not sure this is the right approach. It seems to be geared at letting less competent code

          • You are essentially blaming all security bugs ever on "incompetence". That's lazy management in the business world and it's stupid everywhere else. C has numerous and many traps. Building tools which make it impossible to make the "easy" mistakes is how we get to spend more time thinking about the actual hard ones.

            • by gweihir ( 88907 )

              No, I do not. What I am pointing out is that this language will have "management" assign even less competent people to do "secure code" than they do now, for a likely net loss in security.

              And besides, Rust does not prevent you from making all "easy" mistakes either, just some of them.

              There is this class of "tool fetishists" that think all problems with coding can be solved by just using the "right tools". You even hear that opinion form people that really should know better. Well, guess what, if that were p

              • by Jeremi ( 14640 )

                Well, guess what, if that were possible, we would have the right tools by now. The fact of the matter is that performance, security, maintainability, etc. cannot be enforced by tools.

                I take it you do all of your programming in assembly language, because there's nothing to be gained by using anything higher-level than that, because you totally know what you're doing at all times?

                (Or if not, you've tacitly admitted that there is a benefit to using a tool that enforces some level of safety; you're only quibbling about what that tool should be)

                • by gweihir ( 88907 )

                  You can stick your innuendo up you backside, where it properly belongs.

                  Tool selection is a matter of convenience. Hence I have currently standardized on Python glue-code with C-modules wherever performance is critical. (I would have standardized on Eiffel, but it is too far in a niche...) This has nothing to do with security. In order to make my code secure, I have to understand any and all of its external interfaces, how to protect them and then make sure in addition that all my assumptions on the internal

                  • "No silver bullet" was written almost 30 years ago, and you people are still searching for it?

                    That's because it was a through-and-through. I can write programs far grander in both scope and complexity than almost any programmer of 30 years ago. The reason is not because I am a super-awesome-uber-l33t programmer it's because modern tools are really very good.

                    I would argue that's the case for most programmers now.

                    If that's not a silver bullet, then I don't know what is.

                    • by gTsiros ( 205624 )

                      scope and complexity say absolutely nothing about the quality of code

                      why did you choose those two words instead of "[...] programs far better than almost [...]" ?

                    • by tricorn ( 199664 )

                      Your average desktop computer, compared to a system from 30 years ago, is over 7,000 times faster, has 3-6,000 times as much RAM and 1.5 million times as much persistent storage available, and can communicate over 4,000 times faster, and that's not even getting into graphics capabilities.

                      There's more code in the boot ROM than there was in the boot ROM plus OS plus several applications.

                      It's not that programming tools are so much better, or that programming techniques have advanced, it's that you can write pr

                    • scope and complexity say absolutely nothing about the quality of code

                      So? I can write programs that do more useful stuff than most programmers from 30 years ago. Doing useful stuff is the ultimate goal. And like I said, it's not because of me it's because there are excellent tools and techniques for managing the complexity of large problems.

                    • It's not that programming tools are so much better, or that programming techniques have advanced, it's that you can write programs with many fewer restraints.

                      It's a mix of both. It's 2015, so that makes 1985 30 years ago. The '85 era computer I have most experience with is the BBC Model B. For the day it had an excellent implementation of BASIC: proper named procedures and functions and even an integrated assembler.

                      It didn't however even have proper block-structuring like the later QBasic for things like IF

                    • by tricorn ( 199664 )

                      In the meantime, plenty of people were writing things in Pascal for the Mac. You had a resource compiler with resource files. You could write things in C, on a Unix system. You could build things with "make". Most of the software tools used to compile Linux and most of the current standard software was already in existence. There were source code control systems. There was X Windows. There was TeX. There was PostScript. There were a LOT of things that make up the majority of the software tools stil

                    • I think you have your timelines a bit wrong and/or a rosy view of the past. Firstly there's the question of what was widely available. The Mac 128 and unix systems were out of the reach of people like me back then, costing many thousands when thousands were worth a lot more. Unix was expensive and the compilers were outrageously expensive.

                      Price aside, things were very different. On unix, you had the frankly awful builtin tools which would do nice things like crash if you used a line over 100 chars long. Lot

                    • by tricorn ( 199664 )

                      I was programming in Pascal on a Lisa (dual boot to the Lisa command-line OS (Lisa Workshop) for development and MacOS for testing, occassionally booting to the Office environment). I bought it shortly before it came out as the MacXL, so had non-square pixels. I wasn't rich, and it wasn't any more expensive than a PC would have been with the same capacity.

                      The entire thing (Office 7/7, Workshop, MacWorks) plus system partitions for each was 10MB. System RAM was 1MB. I can compress and copy that whole syst

              • I think you're both right and wrong. Clearly, a safe tool, especially a tool made safe to the point of being unusable, is not a panacea. Yet kids with motorbikes have a lot more fatal accidents than kids with cars.

                The sad truth is you need both: tools with no bugs and safe-by default, and programmers who know how to use them. I agree that if I have to choose, the safe programmer is more important... but show me a project where you can guarantee all devs will be of the "safe" kind (let alone, be that one lon

          • by tgv ( 254536 )

            > the remaining ones will be much more obscure

            That is by itself not an argument. The same obscure errors can be present in code written in another language. Rust does not seem to induce code with subtle bugs.

        • by Anonymous Coward

          The Rust path library actually forces you to think about possible errors. I prefer that over libraries that simply pretend errors don't exist and end up crashing at runtime (or far worse) because of it. In this case, not all paths will have a filename and they definitely won't all be valid UTF-8 so those function calls return a Result (essentially Either for those familiar with Haskell or ML).

          Cross-platform path handling is hard and most libraries simply pretend errors don't exist.

      • Until we get to "Rust 2 Enterprise Edition", it's all just so much talk.
    • by Anonymous Coward

      It's kind of sad how many people completely missed the joke here.

  • by Andrew Wagner ( 3539183 ) on Saturday April 04, 2015 @05:47AM (#49403493)
    Now is a good time to play around with Rust and explore the language features! If you build against the beta release and don't add external package dependencies, your code will most likely continue to function for the duration of the 1.0 release cycle. However, now is probably a particularly ~bad time for new rust users to start a project and add a bunch of dependencies from Cargo/crates.io. Beta changed code dependencies on unstable features from warnings to errors, so a lot of common libraries in the ecosystem are broken at the moment, and will take a little while to get updated. Happy hacking!
  • Ada (Score:5, Interesting)

    by Elledan ( 582730 ) on Saturday April 04, 2015 @06:04AM (#49403523) Homepage
    Is there any reason why anyone would want to use Rust when they're already proficient in both C++ and Ada?

    You'd think that Ada is already covering most if not everything what Rust is trying to cover here, especially the memory safety and concurrency aspects.
    • by Anonymous Coward

      Well, its always good to have exploration so for me Rust is a good thing. Yea, it may not take the World by storm but may bring some new ideals to the table.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      C++ and Ada are geezer languages for unemployable old dinosaurs. Rust is hipster hotness, bitch. You know it or you don't get paid. Ever again.

      • by Anonymous Coward

        nsa and jcs hate memory safe languages. too few exploitable bugs. c++ will enjoy a long life because of this

      • C++ and Ada are geezer languages for unemployable old dinosaurs. Rust is hipster hotness, bitch. You know it or you don't get paid. Ever again.

        Are there actually Rust jobs already?

    • Simpler syntax, less code to write (less verbose)?

      • Re:Ada (Score:5, Insightful)

        by Celarent Darii ( 1561999 ) on Saturday April 04, 2015 @07:13AM (#49403665)

        No. Ada already has a very basic syntax, which if you look at the Ada example [wikipedia.org] is so much like Rust that really I fail to see any significant difference. Ada is also completely buzz-word compliant. It has also been used to make real projects, and even has a ANSI Standard since 1983. Rust can't even guarantee a feature set, nor even a stable keyword set.

        Wish them luck, but frankly it's a bit like reinventing the wheel. I guess it's what hipsters do when they skip CS 102 in order to 'find themselves' - try to 'reinvent' what they should have learned in college.

        • Re:Ada (Score:5, Insightful)

          by Electricity Likes Me ( 1098643 ) on Saturday April 04, 2015 @08:56AM (#49403921)

          Complaining about other people's open source projects seems to be what Slashdot posters do in order to make themselves feel important.

        • I think the most significant difference is that Rust is much closer to a functional language than to something like C.
          They just don't want to market it as a functional language because their targets are mostly C programmers, and most of those would never accept one.
          Look at the main features: (almost) everything is an expression, pattern matching, type inference, actor-based concurrency, higher-order functions and closures, that's the kind of things you mostly find in functional languages.

          Is Rust going to fi

          • by amorsen ( 7485 )

            It would be unusual if Rust was marketed as a functional language, because AFAIK no functional language exists without garbage collection today.

        • Re: (Score:3, Informative)

          Wow, Ada code looks nothing like Rust code to me. Ada looks like a mix of BASIC and python. I don't know Ada, but Rust supposedly makes stronger guarantees of memory correctness for parallel code. Rust just went beta yesterday; breaking changes up to now were to be expected. Once there are more people with real-world experience with both Ada and Rust, I'll be very interested in reading about their experiences. Maybe you haven't been following it closely, but Rust is not some one-developer toy scripting
        • Sorry, there is no real relation between Adas and Rusts syntax, no idea which idiots modded you to +5.

    • by HiThere ( 15173 )

      Well, unicode handling is a *bit* easier in Rust. Unfortunately the general character class seems to be available only as an experimental feature, and the library B+Tree doesn't persist to a file. So it's clearly got some drawbacks. (OTOH, C++'s handling of unicode is pathetic. Vala is better, but it seems dependent on the Gnome libraries, which means it's probably untrustworthy.)

      That said, handling variable length strings and heap allocation in Ada is really painful. (Yes, I know about unbounded-etc.

    • by roca ( 43122 )

      Rust offers manual memory management with automatic safety checking --- the language guarantees you don't leak memory, and you can't access an object after it's freed (assuming you don't opt into unsafe code). No other mainstream language, including Ada, offers that.

  • by Anonymous Coward on Saturday April 04, 2015 @06:05AM (#49403529)

    Is this Rust thing another web framework? Should I assert 5 years experience with Rust on my CV?

    • by gweihir ( 88907 )

      Not quite, but close enough methinks.

      (Yes, I do detect the irony, but it is reality that is ironic here...)

  • by Anonymous Coward

    This is a good feature now? Fragmented memory is desirable?

    • by BasilBrush ( 643681 ) on Saturday April 04, 2015 @07:50AM (#49403767)

      You must be a Java programmer. Garbage collection is generally a very bad idea for a systems language, because of the periodic stalls whilst it does the cleanup. Especially if it's shunting blocks around memory to defragment. It's one of the big reasons why Android underperforms iOS, why it's never been so smooth in operation. And the only thing a developer can do about it is switch to a different language or develop for a more powerful machine.

      Memory fragmentation can be a problem - but the success of C and C++ in most domains over the decades has shown it's just one more aspect a programmer has to deal with, it's not a showstopper. It's fixable, on the same machine, with the same language.

      • by gTsiros ( 205624 )

        "It's one of the big reasons why Android underperforms iOS, why it's never been so smooth in operation."

        no, there is only one reason: shitty coding.

      • by IamTheRealMike ( 537420 ) on Saturday April 04, 2015 @12:04PM (#49404721)

        You must be a Java programmer. Garbage collection is generally a very bad idea for a systems language, because of the periodic stalls whilst it does the cleanup

        Ah yes, the "systems language" debate. Oh how I love those.

        Here are a few things to ponder.

        The first is that your claim about Android underperforming iOS doesn't seem to have any merit. I have a Lollipop device here and it's as smooth as any iPhone I've ever used. Indeed I suspect by "smooth" you mean whether animations consistently hit 60fps and that has relatively little to do with garbage collection because most animations only last for a second or two, and you can easily delay GC until after it's finished. If you actually read about Project Butter and the work the Android team did to make things fast and smooth, it mostly involved deep changes to the graphics stack. The new GC in ART helps when doing things like scrolling down infinite lists, but otherwise, it's not a big deal. Bear in mind GC pauses on a modern Android device are in the realm of milliseconds - not fast enough to cause a frame skip unless you're really pushing up against the deadlines.

        Another thing to consider is that people love to try and define "systems language" to mean whatever language they happen to prefer at the time. For instance the Linux guys have claimed for years that C++ isn't a "systems language" because you can't use it to write a kernel. However, quite a few successful kernels have done just that: for instance parts of the MacOS kernel are written in C++, the osV kernel is mostly C++ and so on. Microsoft even wrote an entire OS with kernel and everything in garbage collected C#. I've come to believe that the term "systems language" is so vague as to be useless for describing programming languages.

        Final point. Rust claims to be superior for systems programming because it doesn't need a garbage collector. However, Mozilla is not in the business of writing kernels. They are in the business of writing web browsers. Web browsers absolutely can be garbage collected and due to the need to support Javascript, often are. At a time when Mozilla is dumping resources into designing an entirely new programming language and experimental layout engine that uses it (Servo), the Chrome guys are quietly getting on with migrating Blink (aka WebKit) to garbage collected C++. The project is called Oilpan, look it up. Apparently Google disagrees with Mozilla about the need for a non-GCd "systems language" for the kind of work they're doing.

        • The first is that your claim about Android underperforming iOS doesn't seem to have any merit. I have a Lollipop device here and it's as smooth as any iPhone I've ever used.

          I nearly went into this with my post, but decided it was better to make a simple clear point without dealing with the obvious avenues for counter-argument in advance.

          Android got smooth by throwing hardware at it. The reason for a while Androiders were bragging that their phones had more cores or higher clock speeds was that Android needed it.

          Then there was the NDK, whose justification was explicitly things for which Java and Garbage Collection were unsuitable.

          I don't know anyone who thinks C++ isn't a syste

          • Android got smooth by throwing hardware at it. The reason for a while Androiders were bragging that their phones had more cores or higher clock speeds was that Android needed it.

            I'm sorry, but this is the same argument that people made against Java in the 90's, when Java was a few orders of magnitude slower. But as time went on, the total percentage that the computational overhead took up dropped to less than 1% because the hardware got faster. Java's success shows that developer convenience is a very powerful thing.

            • But as time went on, the total percentage that the computational overhead took up dropped to less than 1% because the hardware got faster.

              Which is exactly the same thing as I said. Java's shortfalls were mitigated by hardware upgrades, not by actually fixing it. It can't be fixed. Whilst the GC stalls can be comped with for higher level software, it's a showstopper for lots of systems level programming.

        • Your final point about Servo and Oilpan is off. Servo has garbage collection in the same way that Chrome is growing garbage collection via Oilpan: for keeping track of objects in the DOM (in fact, Servo uses the SpiderMonkey GC for this, it's actually pretty neat. See https://blog.mozilla.org/resea... [mozilla.org] for details). Mozilla isn't afraid of garbage collection, they just happen to think that if you can get by without it then hey, why not?
          • No, WebKit already traces through C++ for the DOM GC. Oilpan is a project to make it use GC for *all* Blink objects including objects not exposed to the DOM at all. Read the design doc to learn more.

      • by HiThere ( 15173 )

        The proper way to handle that is to allow garbage collection to:
        1) run in a separate thread, and
        2) be disabled in sections of the program where timing is critical.

        If your application needs to, you can disable garbage collection right after the beginning, and never re-enable it. Then the compiler/linker can be smart enough to just remove it as unused code.

        Garbage collection allows many techniques to be handled with non-deterministic freeing of memory. This can be especially important when programs are runn

        • Everyone who is responded to me has done so as if I said that Garbage Collection is always bad. Of course it's not. Languages such as Python are great places for GC, as is Javascript, and Java, when it's used at the application level.

          It's just a very bad idea for systems programming.

          • by HiThere ( 15173 )

            But being bad for systems programming is not the same as being bad in a systems programming language. I will readily grant that there are applications in which it is desireable to avoid garbage collection. This just means that the language must be able to run well without it. And really, is easily casting integers to pointers and back important? That's the main they the language needs to avoid to make garbage collection reasonable. And switches, either program or compiler, to disable it are also fairly

      • You must be a Java programmer. Garbage collection is generally a very bad idea for a systems language, because of the periodic stalls whilst it does the cleanup

        Respectfully, you really need to research this if you believe that is the cause. Java is the enterprise systems language to beat today. And its Garbage collector does a fine job if you understand how it operates, just as with most other mature garbage collected runtimes.

        • You don't know what you are talking about. Enterprise systems are the very opposite of systems software. Systems languages are for writing kernels, drivers etc.

          • by kervin ( 64171 )

            Please read up on Utility Software [wikipedia.org], which has a very sizable list of examples written in Java. Personally, we have a list of utility software on the market written in Java.

            • I don't ned to read up on what I've been working with and occasionally on for 30 years.

              Utilities are part UI and part drivers for the various hardware or OD level tasks they do. The UI might be OK to be written in Java. The drivers (which are the systems software part) will rarely, if ever be Java.

      • You must be a Java programmer. Garbage collection is generally a very bad idea for a systems language, because of the periodic stalls whilst it does the cleanup.

        Why not garbage collection methods in the kernel with different strategies?

    • by gweihir ( 88907 )

      For some applications, it does not matter much. If you need high-performance, you need to do your own memory management anyways. In the space in-between, Rust will have a problem.

    • The end result is not going to "fragment" memory, it is about when and how memory management is done. Unfortunately for the sake of allowing programmers not to know what they are doing or what is going on they implemented garbage collection in object oriented languages like Java, which is generally fine in server applications that run in a VM.... but it has a cost to doing that. A better compromise (IMHO) is "Automatic Reference Counting" which is done at compile time and does not have to be programmed cl
      • by HiThere ( 15173 )

        I was counting automatic reference counting as a form of garbage collection. And it does have some tradeoffs, but, IIUC, the loops of links problem is subject ot automatic handling. What you *can't* allow is casting between pointers and non-pointers. To me this seems like a minor limitation, and one that should probably be implemented anyway. (With, of course, some escape hole around the prohibition for those that really need to and really, really, know what they're doing.)

        OTOH, be aware that Python use

        • There is a vast difference between an interpreted language such as Python and a low level compiled language when you are talking about "reference counting". With a language such as Python it is really still garbage collection.

          With a compiled language on the LLVM (high level transportable assembly language which in turn is turned into machine code) it is not actually a thread running garbage collection in the background it is the Clang/LLVM compiler inserting "free" memory calls used as it goes out of sc
          • by HiThere ( 15173 )

            Your description of the particular technique used by the LLVM doesn't mean that this is the only approach. And in my opinion the garbage collector, of whatever nature, including reference counting, should run in a separate thread. Whether it's reasonable for a battery powered device I don't know. Clearly it means extra processing, but it also can mean less disk activity. I suspect that Apple has put much more thought into this than I ever would, but I also suspect that they were considering making thing

  • by Anonymous Coward on Saturday April 04, 2015 @06:39AM (#49403593)

    Everything is written in JavaScript or soon will be. New language development is a waste of time that should be better spent making mobile apps for 3D printers.

  • by Anonymous Coward

    I couldn't find it in the online doc, then someone on stackoverflow informed me that "Rust Never Sleeps".

  • by indy_Muad'Dib ( 869913 ) on Saturday April 04, 2015 @11:30AM (#49404569) Homepage
    rust finally going into beta but then some naked smashed my head in with a rock and stole my bow.
  • I spent the last 45 minutes watching an introductory video on Rust and I believe it is a new exciting language that is badly needed. Yes there is a lot of language competitors out there, but most of those languages are higher level than C / C++. C / C++ have had very little competition in their end of the language spectrum. They are old, not very safe. Rust on the other hand is type/memory safe by default -- although you can run "unsafe" code within there by explicitly stating so and then the compiler

BLISS is ignorance.

Working...