Announcement

Collapse
No announcement yet.

Mozilla Updates To Rust 0.9 Programming Language

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

  • #21
    After a bit of google...

    Converting C .h Files into D Modules


    Writing a kernel in D


    I'm afraid I don't know much more about it. I last read about it nearly half a year ago.

    Comment


    • #22
      Originally posted by mrugiero View Post
      You could obfuscate code in any language, AFAIK. IMO, we are at times relying too much in the compiler to "think" for us, when all it should be doing is translate programs.
      Yes, obfuscated code can probably be written in any language, but some languages are more adept at it than others. Reducing a language's predisposition toward obfuscation without reducing it's expressiveness would be an improvement, I think.

      I agree that the primary purpose of a compiler is to translate programs, but a good language should be good for thinking about programs, not just writing them. (I'm paraphrasing Paul Graham here.) This is why I never program in Java unless I have to -- I never have thoughts that start with "public static void main(String[] args)..."

      Comment


      • #23
        Originally posted by mrugiero View Post
        I don't know, I never heard that statement before. If that's so, then porting a kernel to D is less of an issue than I thought, but at the same time it means that D still takes that legacy cruft some say should be removed, and it's still liable to compile unsafe programs.
        D language depends on garbage collector which has disadvantages:
        Garbage collection consumes computing resources in deciding which memory to free, even though the programmer may have already known this information. The penalty for the convenience of not annotating object lifetime manually in the source code is overhead, which can lead to decreased or uneven performance. Interaction with memory hierarchy effects can make this overhead intolerable in circumstances that are hard to predict or to detect in routine testing.
        The moment when the garbage is actually collected can be unpredictable, resulting in stalls scattered throughout a session. Unpredictable stalls can be unacceptable in real-time environments, in transaction processing, or in interactive programs. Incremental, concurrent, and real-time garbage collectors address these problems, with varying trade-offs.
        Non-deterministic GC is incompatible with RAII based management of non GCed resources.As a result, the need for explicit manual resource management (release/close) for non-GCed resources becomes transitive to composition. That is: in a non-deterministic GC system, if a resource or a resource-like object requires manual resource management (release/close), and this object is used as 'part of' another object, then the composed object will also become a resource-like object that itself requires manual resource management (release/close).

        Comment


        • #24
          Originally posted by cmr~ View Post
          We're not a valid C++ replacement for certain uses of it. We lack templates, and templates are extremely powerful as an abstraction mechanism. Eigen or Boost could never exist for Rust, we simply don't have the expressive power. Of course, our type system makes up for it in other ways, but it rules us out in some categories of usage.
          Interesting. I have never cared to learn C++ as it seems like a just too complicated language without any real advantage for me (as in a web developer perspective). I just thought templates were about the same as generics. But good to be wrong, now I got interested in reading up on templates

          Originally posted by bison View Post
          Replacing "all C and C++" is right behind "world peace" in terms of scope. :-)
          Yes of course. I didn't really mean it in that sense
          But if I ain't completely out of direction here isn't C and C++ the only popular languages without memory safety?
          And the number of bugs that causes serious security problems because of this is massive...

          But then, other platforms have similar problems that are possible just by the stupidity of the language/languages (XSS)

          Comment


          • #25
            Originally posted by JS987 View Post
            D language depends on garbage collector which has disadvantages:

            http://en.wikipedia.org/wiki/Garbage...puter_science)
            Depens as in you can not turn it off? I know it allows you to do some manual memory management, but I have no idea if you can turn off completely the GC.

            Comment


            • #26
              Originally posted by mrugiero View Post
              Depens as in you can not turn it off? I know it allows you to do some manual memory management, but I have no idea if you can turn off completely the GC.
              AFAIK, you can, but then you loose out on many language features.

              Comment


              • #27
                Originally posted by Pajn View Post
                But if I ain't completely out of direction here isn't C and C++ the only popular languages without memory safety?
                Yes, probably, depending on how you define popular.

                C++ allows for reasonably safe memory management via smart pointers and destructors. C much less so. I've spent hours debugging some really weird problems that turned out to have been caused by trying to free the same block of memory twice.

                I think it might be possible to create a safer manual heap management scheme than what C has, but it would break compatibility with existing code, and would probably require cooperation from the OS. But there's currently very little interest in such an approach.

                Comment


                • #28
                  Rust will never replace C/C++. Get over it already. Make those languages meet your criteria through their standards specs.

                  One has a greater probability of bedding down Heidi Klum than replacing C/C++.

                  Comment


                  • #29
                    Originally posted by mrugiero View Post
                    I don't understand, didn't you just said it's memory safe, but still he got a triple fault? Are they unrelated? Or is just the port still uses some C and that was the origin of the fault?
                    As part of its support for interacting with foreign code (eg. talking to the BIOS or UEFI), Rust supports "unsafe" pointers, functions, and blocks.

                    (Think of it as similar to Java's explicit exception system. An unsafe pointer can only be manipulated via an unsafe function or block. An unsafe function can only be called by another unsafe function or from within an unsafe block. An unsafe block has no such restriction, so you use them to implement the boundary between safe and unsafe code.)

                    The triple fault would have occurred in a part of the code declared unsafe.
                    Last edited by ssokolow; 10 January 2014, 04:18 PM. Reason: More accurate phrasing

                    Comment


                    • #30
                      Originally posted by ssokolow View Post
                      As part of its support for interacting with foreign code (eg. talking to the BIOS or UEFI), Rust supports "unsafe" pointers, functions, and blocks.

                      (Think of it as similar to Java's explicit exception system. An unsafe pointer can only be manipulated via an unsafe function or block. An unsafe function can only be called by another unsafe function or from within an unsafe block. An unsafe block has no such restriction, so you use them to implement the boundary between safe and unsafe code.)

                      The triple fault would have occurred in a part of the code declared unsafe.
                      I can't think in terms of Java, as I don't know Java. I do think I understood your explanation, anyway.

                      Comment

                      Working...
                      X