Announcement

Collapse
No announcement yet.

Rust Language 0.10 Released With Big Improvements

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by cmr~ View Post
    That's not a very good comparison I don't think. Scala has HUGE amounts of features which interact in many strange, surprising ways. I don't think there's any existing project to compare Rust to, really. It's basically the first in its space. Maybe Ada.
    I mean in the functional features, the match syntax, arrow syntax.
    As I understand it, Rust is low level functional language and it seemed to me like Scala is to java.

    Whats the best prior knowledge to learn Rust? Experience with C/C++ or a functional language like Erlang/Haskell?
    Last edited by andrei_me; 04 April 2014, 08:49 AM.

    Comment


    • #22
      Originally posted by andrei_me View Post
      I mean in the functional features, the match syntax, arrow syntax.
      As I understand it, Rust is low level functional language and it seemed to me like Scala is to java.

      Whats the best prior knowledge to learn Rust? Experience with C/C++ or a functional language like Erlang/Haskell?
      Rust is not a low-level functional language. Rust is a systems language that has some features inspired from functional languages.

      C/C++ knowledge is going to be more useful, the hard parts are memory management and how it ensures memory safety. The rest really is mostly sugar for concepts you'll already be familiar with.

      Comment


      • #23
        Originally posted by cmr~ View Post
        Rust is not a low-level functional language. Rust is a systems language that has some features inspired from functional languages.

        C/C++ knowledge is going to be more useful, the hard parts are memory management and how it ensures memory safety. The rest really is mostly sugar for concepts you'll already be familiar with.
        Good to know, thanks for the reply

        Comment


        • #24
          Originally posted by Calinou View Post
          Isn't Rust higher level than C(++)? If so, how is that possible? Do you have benchmarks to prove that?
          Obviously cmr~ knows Rust way, way, way way better than I do, but to add to what he said - my understanding is that the entire reason Mozilla developers created the language was for an equivalent or better performance C++ replacement that made it easier to deal with multi-threading and easier to prevent buffer overruns and other common security errors.

          Originally posted by cmr~ View Post
          That's not a very good comparison I don't think. Scala has HUGE amounts of features which interact in many strange, surprising ways. I don't think there's any existing project to compare Rust to, really. It's basically the first in its space. Maybe Ada.
          Scala also has warts from the fact that it's built to interoperate with Java and run on the Java Virtual Machine. To fit that metaphor, Rust would need to be some kind of layer on top of C++. It is not, it's a separate language in the same application space and as far as I know only interfaces with C++ through C.

          You could probably use Rust and Google Go in many similar applications, but Go has automatic garbage collection so for a lot of tasks you would need to call from Go into C while a Rust developer could use Rust the entire time.

          The D programming language has automatic garbage collection by default but you can use malloc and free without calling out into C code. So I would imagine it and Rust occupy the same space. Thoughts? I'm curious why the Rust team did not adapt D - though there were big improvements from D 1.0 to D 2.0, maybe Rust was started before D 2.0 was introduced.

          Comment


          • #25
            Originally posted by Michael_S View Post
            Obviously cmr~ knows Rust way, way, way way better than I do, but to add to what he said - my understanding is that the entire reason Mozilla developers created the language was for an equivalent or better performance C++ replacement that made it easier to deal with multi-threading and easier to prevent buffer overruns and other common security errors.



            Scala also has warts from the fact that it's built to interoperate with Java and run on the Java Virtual Machine. To fit that metaphor, Rust would need to be some kind of layer on top of C++. It is not, it's a separate language in the same application space and as far as I know only interfaces with C++ through C.

            You could probably use Rust and Google Go in many similar applications, but Go has automatic garbage collection so for a lot of tasks you would need to call from Go into C while a Rust developer could use Rust the entire time.

            The D programming language has automatic garbage collection by default but you can use malloc and free without calling out into C code. So I would imagine it and Rust occupy the same space. Thoughts? I'm curious why the Rust team did not adapt D - though there were big improvements from D 1.0 to D 2.0, maybe Rust was started before D 2.0 was introduced.
            Rust started as a much, much different language than it is today. It was more of a low-level ML with typestate (http://pcwalton.github.io/blog/2012/...state-is-dead/) and a region system (http://cyclone.thelanguage.org/wiki/Papers/). Over time it has simplified and converged somewhat with one might expect of a traditional language. What Rust has that D doesn't is guaranteed memory safety without GC. We also have significantly less complexity language-wise than D. I'm not well versed enough in D to offer much more knowledge than that.

            Comment


            • #26
              good language but

              I appreciate the memory safety model very much I have a few thoughts.
              The syntax is a little too concise to be easily readable and maintained. if it was perceived by people like a functional C++ with syntax like unreadable perl it would be a blocker for more people to adopt it.

              Particularly the owned/managed/shared pointers are denoted in a way not so obvious and can be confusing and hard to maintain. I would rather to see keyword is used to define them instead of using puntuations like ~. I'd prefer to something like "owned *opObj". Then when this pointer is used, people are always clear this pointer is an owned one.

              Same feeling about the namespaces. They are too concise to be meaningful enough. In a language that is supposed to support large projects, readability is very important to me.

              Comment


              • #27
                Originally posted by goTouch View Post
                I appreciate the memory safety model very much I have a few thoughts.
                The syntax is a little too concise to be easily readable and maintained. if it was perceived by people like a functional C++ with syntax like unreadable perl it would be a blocker for more people to adopt it.

                Particularly the owned/managed/shared pointers are denoted in a way not so obvious and can be confusing and hard to maintain. I would rather to see keyword is used to define them instead of using puntuations like ~. I'd prefer to something like "owned *opObj". Then when this pointer is used, people are always clear this pointer is an owned one.

                Same feeling about the namespaces. They are too concise to be meaningful enough. In a language that is supposed to support large projects, readability is very important to me.
                Unless you've actually maintained a codebase in Rust, I find such comments unfounded. Which namespaces are too concise? Also note that managed/shared pointers are gone from the language. Using ~ doesn't make it less clear that the pointer is an owning pointer, since it's the only use of that symbol in the language. Once you've learned what it means, there's no confusion. ~ being short is a goal. It shouldn't take a lot of effort to simply allocate a value.

                They might take a minute to learn (if you've used malloc/free or new/delete before), but I don't think that in any way hinders their usage.

                Comment


                • #28
                  Originally posted by goTouch View Post
                  I appreciate the memory safety model very much I have a few thoughts.
                  The syntax is a little too concise to be easily readable and maintained. if it was perceived by people like a functional C++ with syntax like unreadable perl it would be a blocker for more people to adopt it.

                  Particularly the owned/managed/shared pointers are denoted in a way not so obvious and can be confusing and hard to maintain. I would rather to see keyword is used to define them instead of using puntuations like ~. I'd prefer to something like "owned *opObj". Then when this pointer is used, people are always clear this pointer is an owned one.
                  I'd argue the opposite; pointers are used so often that you want a concise syntax for them. ~ is for owned pointers, and & is for borrowed - once you've got that down the rest is pretty easy (although arrays of pointers can get confusing).

                  Same feeling about the namespaces. They are too concise to be meaningful enough. In a language that is supposed to support large projects, readability is very important to me.
                  The standard libraries use a concise namespace because they're frequently used. The alternative would be something like Java, where you need to reference java.io.BufferedWriter for something as common as text I/O.
                  At any rate, Rust supports nested modules, so there's no reason you can't have a type called Foo::Bar::Baz.

                  Originally posted by cmr~ View Post
                  Also note that managed/shared pointers are gone from the language.
                  Honestly, I would have preferred that they had been left in. If you have managed pointers then you can choose to completely ignore memory safety and use it as a high level language. (There aren't many languages which are designed to enable both imperative and functional coding from the ground up.)

                  Comment


                  • #29
                    Originally posted by rdnetto View Post

                    Honestly, I would have preferred that they had been left in. If you have managed pointers then you can choose to completely ignore memory safety and use it as a high level language. (There aren't many languages which are designed to enable both imperative and functional coding from the ground up.)
                    Well, with them gone, we have a more powerful language. Smart pointers can now be expressed entirely in the standard library, without needing a new built-in type for everything you might want. With overloadable + automatic dereferencing, you can use `Rc<T>` just like `~T` or `&T`. It's not like we're getting rid of managed pointers entirely, forever. There's the `Gc<T>` type for it. In the past, `@T` was just an inefficient refcounting "garbage collector" with no cycle collection except at task completion. (And by inefficient I really mean it -- it imposed a 32 byte overhead on the types you used it with, and did a refcount bump *every single time it was used*, rather than `Rc<T>`, which you need to explicitly clone to bump the refcount.) `Gc<T>` will have a real garbage collector. It's not done yet, but it's in scope for 1.0 (see spreadsheet at http://bit.ly/1dM8ii2).

                    Comment


                    • #30
                      Originally posted by cmr~ View Post
                      Well, with them gone, we have a more powerful language. Smart pointers can now be expressed entirely in the standard library, without needing a new built-in type for everything you might want. With overloadable + automatic dereferencing, you can use `Rc<T>` just like `~T` or `&T`. It's not like we're getting rid of managed pointers entirely, forever. There's the `Gc<T>` type for it. In the past, `@T` was just an inefficient refcounting "garbage collector" with no cycle collection except at task completion. (And by inefficient I really mean it -- it imposed a 32 byte overhead on the types you used it with, and did a refcount bump *every single time it was used*, rather than `Rc<T>`, which you need to explicitly clone to bump the refcount.) `Gc<T>` will have a real garbage collector. It's not done yet, but it's in scope for 1.0 (see spreadsheet at http://bit.ly/1dM8ii2).
                      True, but Gc<T> is much more clunky than @T - there's no reason they couldn't have kept it and made it syntactic sugar for Gc<T>.
                      Rust is a really nice language, but the need to worry about borrowed vs. owned pointers makes it unusable as a high level language for me. Admittedly, it's not intended to be a high level language, but there's no reason it couldn't have catered to both domains.

                      Comment

                      Working...
                      X