Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 46

Thread: Mozilla Updates To Rust 0.9 Programming Language

  1. #21
    Join Date
    Oct 2013
    Location
    Canada
    Posts
    413

    Default

    After a bit of google...

    Converting C .h Files into D Modules
    http://dlang.org/htomodule.html

    Writing a kernel in D
    http://wiki.osdev.org/D_Bare_Bones

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

  2. #22
    Join Date
    Oct 2013
    Posts
    71

    Default

    Quote 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)..."

  3. #23
    Join Date
    Sep 2012
    Posts
    358

    Default

    Quote 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).
    http://en.wikipedia.org/wiki/Garbage...puter_science)

  4. #24
    Join Date
    Sep 2012
    Posts
    287

    Default

    Quote 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

    Quote 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)

  5. #25
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote 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.

  6. #26
    Join Date
    Oct 2011
    Posts
    225

    Default

    Quote 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.

  7. #27
    Join Date
    Oct 2013
    Posts
    71

    Default

    Quote 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.

  8. #28
    Join Date
    Oct 2012
    Location
    Washington State
    Posts
    488

    Default

    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++.

  9. #29

    Default

    Quote 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; 01-10-2014 at 03:18 PM. Reason: More accurate phrasing

  10. #30
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •